'lsblk' (i en terminal) är en bra kommando att se vilka partitioner de finns och om de är monterade någonstans, liknande
sda 8:0 0 7.3T 0 disk
├─sda1 8:1 0 4G 0 part
└─md0 9:0 0 4G 0 raid1 /
sdb 8:16 0 7.3T 0 disk
├─sdb1 8:17 0 4G 0 part
└─md0 9:0 0 4G 0 raid1 /
sdc 8:32 0 7.3T 0 disk
├─sdc1 8:33 0 4G 0 part
└─md0 9:0 0 4G 0 raid1 /
sdd 8:48 0 7.3T 0 disk
├─sdd1 8:49 0 4G 0 part
└─md0 9:0 0 4G 0 raid1 /
logisk enheter md indikerar att de sitter i någon md-RAID och visas det något efter som "/", visar att de är monterade som root-filsystem (läs systemdisk)
annars får du läsa lite på 'mdadm' som är linux-systemens vanligaste hanterade RAID-hanterare
Om du gör 'dmesg | less' och bläddrar ned ända från början (relativt nystartas system - det är en cirkelbuffe så har det skrivits mycket så är början borta) så kan du se när mdadm börja koppla ihop diskarna och skapa virtuella volymer.
När det gäller ecryptfs måste man hålla tungan rätt i munnen då samma filer finns i två upplagor länkade mot varandra - en uppsättning är det krypterade versionen ofta i en subdirektory liknande ~.Private (där orginal-krypterade filerna finns) och en ~.ecryptfs (som har nycklarna och annan för virtuella filsystemet viktig metadata) och den avkrypterade versionen som du ser i samma directory --- pilla inte i dessa två nämnda subdirektorys... Den delen med kryptering kommer heller inte att synas under 'lsblk'
Det kan också ställa till med din rsync-backup att du kan få en dubbel upplaga av dessa filer, den krypterade versionen och den avkrypterade versionen och det tar oväntat dubbel plats på din lagringsdisk...
har systemet läsfel på filerna (vilket är troligt med tanke på att du får IO-fel ) så får du med rätt flaggor till rsync bestämma hur det skall hantera situationen - kan inte allt utantill
---
Om aktuella disken inte är monterad så kan du köra ddrescue - men är det systemdisken som du kör kommandona ifrån så är det inte bra - i de flesta fallen så är det uppstart separat sticka som gäller och att man ser till att disken alla partitioner som det skall kopieras ifrån ej är monterade innan man kör ddrescue.... (dvs. ddrescue /dev/sda /media/diskimage_sda /media/sda_loggfil) /dev/sda är disken man vill göra diskimage och disken du skall kopiera till får du förstås montera under /media
Även om man innan med rsync tar med alla filer som går i en session innan, så kommer man missa alla filer som har läsfel - dessa kommer troligen att saknas och är det många filer så är det svår att upptäcka att filer saknas och hur många.
Med diskräddning med ddrescue med upprepande läsningar på de dåliga sektorerna så kan det lyckas ibland och det räcker med en enda gång för att det skall uppdateras i disk-imagen - redan lästa sektorer försöker man inte läsa igen. - observera loggfilen som man skriver efter sökvägarna är jätteviktig, det gör också att du kan avbryta din räddningsförsök - göra det andra du skall och sedan återuppta till en senare tillfälle och den fortsätter där du var och inte börja från början
Kör man distrubitioner avset för diskräddning mm. som liknade systemrescuecd så är inga filer monterad per default utöver USB-stickan själv, och det gäller även disken du vill lagra filer till och måste monteras manuellt. -
'lsblk' används för att veta vilka diskar och Partitioner som finns och skall alltid köras innan varje session och kontrolleras då diskarna kan hoppa runt när man gör reboot eller stoppa in ytterligare disk (oftast bara tillägg i listan) Att det hoppar runt beror på att PCI-bussarna numrerar enheterna i den ordningen som de blir klara vid boot och det är inte alltid lika ordning.
Är du inte Linux-van så är det lämplig att öva på 'ofarliga' diskar först så att du inser hur det fungerar
Är diskarna i någon RAID-konstellation så måste du få med samtliga diskar image i raid-setet i din ddrescue-räddning
med losetup -f -P disk-image så får de under /dev/ ett antal loop-filer där var och motsvarar en partition på den imagen du gjorde losetup på. Den förstår automatiskt MBR/GPT i början på diskimagen för att hitta de ingående partitionerna.
Med detta behöver man inte köra tillbaka diskimagena igen till fysisk disk för att sedan sätta ihop ingående RAID-volymer och rädda filerna....
