Jak postupovat při záchraně dat: Porovnání verzí

Z Wikiknih
Smazaný obsah Přidaný obsah
Woodcraft (diskuse | příspěvky)
Woodcraft (diskuse | příspěvky)
Řádek 230: Řádek 230:
=Oprava poškozeného souborového systému=
=Oprava poškozeného souborového systému=


Po zjištění jaký souborový systém neznámý disk obsahuje, je dobré provést jeho kontrolu. Hovorově se tato kontrola souborového systému nazývá ''čekování''. Tento slangový výraz vychází z anglického výrazu ''check'' - ověřit, ze kterého vycházejí i názvy pro utility, kterými se tato kontrola provádí. Obvykle je totiž v systému najdete pod názvem který začíná '''fsck''' ( z angl. '''''f'''ile'''s'''ystem '''c'''ec'''k''''' - ověření souborového systému). Narazíte-li tedy na aplikaci, která má v názvu '''fsck''' půjde vždy s největší pravděpodobností o utilitu, která slouží ke kontrole a opravě souborového systému.
{{Výpis|1={{Linux:root}}[[Linux:mount|mount]] -t vfat /dev/sdb /mnt -o offset=32256}}

Jelikož pojmenování těchto utilit není zcela jednotné, jsou u Debianu v adresáři <code>/sbin</code> skripty, které sjednocují volání těchto kontrolních utilit podle následujícího vzoru:
{{Výpis|1=fsck.&lt;typ_souborového systému&gt;}}
Díky tomu tak nemusíte přemítat jak se pro onen souborový systém, který potřebujete ověřit vlastně tato utilita jmenuje.

V drtivé většině případů postačí pouhá kontrola, během níž ověřovací utilita sama opraví drobné chybky, které se mohly vyskytnout kupř. při nekorektním vypnutí stroje.

{{Pozor|Pozor! Aby bylo možné provést kontrolu souborového systému, nesmí být diskový oddíl připojen pro zápis. Maximálně může být připojen v režimu "Pouze pro čtení".
Nelze-li tedy jinak, je třeba provést před kontrolou kořenového souborového systému tzv. '''remount''' do ''readonly'' režimu (tj. jen pro čtení). Systém je třeba najet do jednouživatelského režimu (''single user mode'') a pak provést následujícím příkazem <code>remount</code>
{{Výpis|1={{Linux:root}}[[Linux:mount|mount]] -r -o remount /}}
Není-li stroj v jednouživatelském režimu a nějaký démon již s diskem pracuje, pak se vám '''remount''' nepodaří!

;Co si počít v případě že selže pokus o remount?: V takovém případě se pokuste zjistit, který proces pracuje s diskem a pak buď službu která jej spouští korektně zastavit, nebo jej ''odstřelit'' a pokusit se o '''remount''' znovu.

}}

Verze z 5. 5. 2009, 16:02

Stává se, že se vám do rukou dostane neznámý disk o jehož obsahu nemáte ani tušení a přitom z něj máte zachránit co se dá. Někdy také "zdědíte" stroj, který instaloval kdysi dávno někdo před vámi a vy máte zdokumentovat kde má co nainstalované. V takovém případě se vám mohou hodit následující postupy.

Připojení neznámého disku

root@stroj:~# tail -f /var/log/messages

Ukázka výpisu...

Apr 22 17:44:15 stroj X: Libgcrypt warning: missing initialization - please fix the application
Apr 22 17:47:42 stroj kernel: [  264.117586] usb 1-7: new high speed USB device using ehci_hcd and address 4
Apr 22 17:47:42 stroj kernel: [  264.243891] usb 1-7: New USB device found, idVendor=152d, idProduct=2338
Apr 22 17:47:42 stroj kernel: [  264.243905] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=5
Apr 22 17:47:42 stroj kernel: [  264.243914] usb 1-7: Product: USB to ATA/ATAPI Bridge
Apr 22 17:47:42 stroj kernel: [  264.243921] usb 1-7: Manufacturer: JMicron
Apr 22 17:47:42 stroj kernel: [  264.243927] usb 1-7: SerialNumber: 222293F04658
Apr 22 17:47:42 stroj kernel: [  264.244503] usb 1-7: configuration #1 chosen from 1 choice
Apr 22 17:47:42 stroj kernel: [  264.344488] Initializing USB Mass Storage driver...
Apr 22 17:47:42 stroj kernel: [  264.348033] scsi4 : SCSI emulation for USB Mass Storage devices
Apr 22 17:47:42 stroj kernel: [  264.350151] usbcore: registered new interface driver usb-storage
Apr 22 17:47:42 stroj kernel: [  264.350166] USB Mass Storage support registered.
Apr 22 17:47:47 stroj kernel: [  269.351427] scsi 4:0:0:0: Direct-Access     ST325031 0NS                   PQ: 0 ANSI: 2 CCS
Apr 22 17:47:47 stroj kernel: [  269.354109] sd 4:0:0:0: [sdb] 488397168 512-byte hardware sectors: (250 GB/232 GiB)
Apr 22 17:47:47 stroj kernel: [  269.354982] sd 4:0:0:0: [sdb] Write Protect is off
Apr 22 17:47:47 stroj kernel: [  269.355989] sd 4:0:0:0: [sdb] 488397168 512-byte hardware sectors: (250 GB/232 GiB)
Apr 22 17:47:47 stroj kernel: [  269.356846] sd 4:0:0:0: [sdb] Write Protect is off
Apr 22 17:47:47 stroj kernel: [  269.356876]  sdb: sdb1 sdb2 sdb3
Apr 22 17:47:47 stroj kernel: [  269.416988] sd 4:0:0:0: [sdb] Attached SCSI disk

root@stroj:~# sfdisk -d /dev/sdb
# tabulka rozdělení disku pro /dev/sdb
unit: sectors

/dev/sdb1 : start=       63, size=   240912, Id=fd, bootable
/dev/sdb2 : start=   240975, size= 58605120, Id=fd
/dev/sdb3 : start= 58846095, size=429545970, Id=83
/dev/sdb4 : start=        0, size=        0, Id= 0

nebo

root@stroj:~# fdisk -l /dev/sdb

Disk /dev/sdb: 250,0 GB, 250 059 350 016 bajtů
hlav: 255, sektorů na stopu: 63, cylindrů: 30 401
Jednotky = cylindry po 16065 * 512 = 8 225 280 bajtech
Identifikátor disku: 0x00000000

Zařízení Zavádět   Začátek       Konec    Bloky    Id  Systém
/dev/sdb1   *           1          15      120456   fd  Linux RAID samorozpoznatelný
/dev/sdb2              16        3663    29302560   fd  Linux RAID samorozpoznatelný
/dev/sdb3            3664       30401   214772985   83  Linux

Z výpisu je zřejmé, že je disk rozdělen na tři diskové oddíly, z toho první dva byly součástí linuxového softwarového raidu. Třetí diskový oddíl je běžného typu, tudíž na něm mohl být nejspíš nějaký souborový systém.

Reaktivace softwarového raidu

Zkusíme tedy nejdřív zjistit, jak je to s oddíly, které byly určeny pro raid

root@stroj:~# mdadm --examine --scan /dev/sdb1 /dev/sdb2
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=21c6ea2f:416ebb32:c0b47c07:a2972704
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=5084e71d:71fac395:2f70a1ed:2d127230

Jak vidno, tyto oddíly patří do raid1 (mirror), tudíž z nich je možné kompletně obnovit původní raidová pole. Neúplná raidová pole obnovíme velice snadno, neboť předchozí výpis odpovídá syntaxi v souboru mdadm.conf

Můžeme tedy tento výpis rovnou přidat do našeho konfiguračního souboru.

root@stroj:~# mdadm --examine --scan /dev/sdb1 /dev/sdb2 >> /etc/mdadm/mdadm.conf

Šablona:Pozn

Poté co máme upraven soubor /etc/mdadm/mdadm.conf můžeme provést reaktivaci nově přidaných polí..

root@stroj:~# mdadm -A -s
mdadm: /dev/md1 has been started with 1 drive (out of 2).
mdadm: /dev/md0 has been started with 1 drive (out of 2).

Výpisem souboru /proc/mdstat

root@stroj:~# cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active (auto-read-only) raid1 sdb1[0]
      120384 blocks [2/1] [U_]
      
md1 : active (auto-read-only) raid1 sdb2[0]
      29302464 blocks [2/1] [U_]
      
unused devices: <none>

Se můžete přesvědčit o úspěšnosti reaktivace.

Zjišťování použitého souborového systému

Nyní je je třeba zjistit, jak to na těchto diskových polích vypadá. Je nad nimi ještě další vrstva, nebo přímo souborový systém?

Abyste zabránili nechtěnému poškození, je vhodné si vyexportovat počátečních oblast disku do dočasného souboru a dále pracovat s ním.

root@stroj:~# dd if=/dev/md0 bs=512 count=255 of=/tmp/md0-raw-start
255+0 vstoupivších záznamů
255+0 vystoupivších záznamů
130 560 bajtů (131 kB) zkopírováno, 0,0396919 s, 3,3 MB/s

Na vyexportovaný soubor lze pak pustit utilitu file

root@stroj:~# file -s /tmp/md0-raw-start
/tmp/md0-raw-start: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=7509beb3-fa4b-434a-bce1-54f99449b7ba

Ta prozradí nejenom typ souborového systému, ale také UUID diskového oddílu. Když se zkusíme jen tak pro zajímavost podívat na začátek třetího diskového oddílu, tak se dozvíme, že byl součástí LVM svazku

root@stroj:~# file -s /tmp/sdb3-raw-start
/tmp/sdb3-raw-start: LVM2 (Linux Logical Volume Manager) , UUID: ghmk6itpklbAExbzBofefSyYQAQ73HD

Obnova LVM svazku

a když jsme se do vyexportovaného souboru podívali editorem, nalezli jsme v něm následující zajímavou část:

vg01 {
id = "NE4164-p0aA-WD5n-Hpqm-2P3m-Ukf7-8Ilyeg"
seqno = 9
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0

physical_volumes {

pv0 {
id = "hYaUgw-3vF4-3qoz-d3Yu-rZ5l-KXv6-6UAyjt"
device = "/dev/md2"

status = ["ALLOCATABLE"]
flags = []
dev_size = 1953519872
pe_start = 384
pe_count = 238466
}

pv1 {
id = "ghmk6i-tpkl-bAEx-bzBo-fefS-yYQA-Q73HDU"
device = "/dev/sdc3"

status = ["ALLOCATABLE"]
flags = []
dev_size = 429545970
pe_start = 384
pe_count = 52434
}
}

logical_volumes {

data {
id = "tWtk63-DVNI-UCT4-JBpM-raPt-k7lD-1j6SFs"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1

segment1 {
start_extent = 0
extent_count = 102400

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 0
]
}
}
}
}
# Generated by LVM2 version 2.02.44 (2009-01-26): Thu Apr  9 16:52:36 2009

Z těchto údajů lze zjistit nejenom na kterém stroji a kdy byl LVM svazek vytvořen, ale také (podle UUID) zjistit zda byl diskový oddíl součástí LVM svazku i v okamžiku odpojení. Pak lze, přinejmenším část uložených dat obnovit. U výše uvedeného příkladu lze již zběžným pohledem odhalit, že diskový oddíl byl před vytažením disku ze svazku odstraněn, tudíž s největší pravděpodobností již neobsahuje žádná data.

Jak se dostat na diskové oddíly

Systém by si měl většinou při připojení externích disků poradit a pro příslušné diskové oddíly vytvořit příslušná zařízení. Někdy - zvláště pokud je prostor na disku nějakým způsobem poškozen, nebo pokud jde o pouhý obraz disku vytvořený přes fdisk si je třeba poradit jinak. Při mountu použít tzv. offset . Offsetem se udává jak kolik .. se má při mountu přeskočit. Zjistit jakou velikost offsetu musíte použít můžete takto:

root@stroj:~# fdisk -l /dev/sdb

Disk /dev/sdb: 250,0 GB, 250 059 350 016 bajtů
hlav: 255, sektorů na stopu: 63, cylindrů: 30 401
Jednotky = cylindry po 16065 * 512 = 8 225 280 bajtech
Identifikátor disku: 0x5b6ac646

Zařízení Zavádět   Začátek       Konec    Bloky    Id  Systém
/dev/sdb1               1       30401   244196001    c  W95 FAT32 (LBA)
root@stroj:~# sfdisk -d /dev/sdb
# tabulka rozdělení disku pro /dev/sdb
unit: sectors

/dev/sdb1 : start=       63, size=488392002, Id= c
/dev/sdb2 : start=        0, size=        0, Id= 0
/dev/sdb3 : start=        0, size=        0, Id= 0
/dev/sdb4 : start=        0, size=        0, Id= 0


root@stroj:~# dd if=/dev/sdb bs=512 count=255 skip=63 of=/tmp/sdbs-raw-start
255+0 vstoupivších záznamů
255+0 vystoupivších záznamů
130 560 bajtů (131 kB) zkopírováno, 0,0207372 s, 6,3 MB/s
root@stroj:~# file -s /tmp/sdbs-raw-start
/tmp/sdbs-raw-start: x86 boot sector, Microsoft Windows 98 Bootloader, code offset 0x5a, OEM-ID "MSWIN4.1", sectors/cluster 64, Media descriptor 0xf8, heads 255, hidden sectors 63, sectors 488392002 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 59611, reserved3 0x800000, serial number 0x4b1a02bd, label: "WD Passport"
root@stroj:~# echo $((63*512))
32256
root@stroj:~# mount -t vfat /dev/sdb /mnt -o offset=32256

Oprava poškozeného souborového systému

Po zjištění jaký souborový systém neznámý disk obsahuje, je dobré provést jeho kontrolu. Hovorově se tato kontrola souborového systému nazývá čekování. Tento slangový výraz vychází z anglického výrazu check - ověřit, ze kterého vycházejí i názvy pro utility, kterými se tato kontrola provádí. Obvykle je totiž v systému najdete pod názvem který začíná fsck ( z angl. filesystem ceck - ověření souborového systému). Narazíte-li tedy na aplikaci, která má v názvu fsck půjde vždy s největší pravděpodobností o utilitu, která slouží ke kontrole a opravě souborového systému.

Jelikož pojmenování těchto utilit není zcela jednotné, jsou u Debianu v adresáři /sbin skripty, které sjednocují volání těchto kontrolních utilit podle následujícího vzoru:

fsck.<typ_souborového systému>

Díky tomu tak nemusíte přemítat jak se pro onen souborový systém, který potřebujete ověřit vlastně tato utilita jmenuje.

V drtivé většině případů postačí pouhá kontrola, během níž ověřovací utilita sama opraví drobné chybky, které se mohly vyskytnout kupř. při nekorektním vypnutí stroje.

Šablona:Pozor