====== Prověření nového rotačního HDD před zálohováním dat ====== //Vytvořeno: **12.3.2019**// > **Poznámka k aktuálnosti:** Tento článek vychází z praktické zkušenosti z roku 2019 a nemusí odpovídat dnešním verzím nástrojů ani běžné praxi. > > **Důležité:** Tento postup je určený pro klasické rotační HDD. Na SSD a NVMe disky se destruktivní testy typu ''badblocks -w'' nebo přepis celého zařízení náhodnými daty běžně nehodí. [[https://www.smartmontools.org/|smartmontools]] a [[https://man7.org/linux/man-pages/man8/badblocks.8.html|badblocks]] umožňují před nasazením nového rotačního disku udělat základní kontrolu stavu, dlouhé self-testy a případně i destruktivní zápisový test. Tady je dobový praktický postup, který jsem používal před tím, než jsem na nový HDD začal přesouvat zálohy. ===== Proč disk nejdřív testovat ===== Po koupi nového disku dává smysl nejdřív odložit kopírování dat a disk důkladně prověřit. V mém případě šlo o disk připojený k [[https://www.armbian.com/cubieboard-2/|Cubie Board 2]] s [[https://www.armbian.com/|Armbianem]], kde měl sloužit pro zálohy. Předchozí 2TB disk mi odešel i s daty do křemíkového nebe — technicky vzato jsem přišel o data stará asi měsíc. Byl to druhý disk, který mi odešel do dvou let. Po pročtení mnoha příspěvků a [[https://www.root.cz/zpravicky/bac-kblaze-vydal-statistiky-poruchovosti-disku-za-rok-2018-pocet-zavad-klesa/|statistik Backblaze]] jsem si potvrdil, že neexistuje spolehlivý disk jako takový — jediný způsob, jak snížit riziko, je záloha záloh. Jako nový disk jsem zvolil Seagate IronWolf 3,5" 4TB. Dalším krokem bylo plánování softwarového RAIDu, ale tento postup je o přípravě nově koupeného disku před prvním použitím. Po předchozí zkušenosti s odcházejícími disky jsem chtěl nový kus několik dní testovat ještě před tím, než na něj něco důležitého uložím. ===== S.M.A.R.T. testy ===== První krok byl S.M.A.R.T. self-test. Po koupi je rozumné začít třeba conveyance testem, který může odhalit poškození při přepravě: smartctl --test=conveyance /dev/sda Průběh a výsledky testů lze kontrolovat takto: smartctl -l selftest /dev/sda Pak následoval krátký a dlouhý test. Zkrácený test běžel pár minut, dlouhý test trval nějakou tu hodinku: smartctl --test=short /dev/sda smartctl --test=long /dev/sda Výsledky testů dopadly dobře, žádná chyba nebyla nalezena. Ukázka výpisu: root@cubieboard2:/home/armbian# smartctl -l selftest /dev/sda smartctl 6.4 2014-10-07 r4002 [armv7l-linux-4.19.13-sunxi] (local build) Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Self-test routine in progress 00% 7 - # 2 Conveyance offline Completed without error 00% 0 - # 3 Short offline Completed without error 00% 0 - ===== Destruktivní kontrola vadných bloků ===== Dalším rozumným krokem před vytvořením souborového systému a přenesením dat je kontrola vadných bloků na disku přes ''badblocks'' v režimu čtení i zápisu. To je potřeba brát jako destruktivní operaci, která smaže obsah zařízení. Příkaz postupně zkouší tyto vzory bitů: ''0xaa'', ''0x55'', ''0xff'', ''0x00''. badblocks -c 10240 -s -w -v /dev/sda Pokud test dopadne dobře, výpis vypadá takto: root@cubieboard2:/home/armbian# badblocks -c 10240 -s -w -v /dev/sda Checking for bad blocks in read-write mode From block 0 to 3907018583 Testing with pattern 0xaa: done Reading and comparing: done Testing with pattern 0x55: done Reading and comparing: done Testing with pattern 0xff: done Reading and comparing: done Testing with pattern 0x00: done Reading and comparing: done Pass completed, 0 bad blocks found. (0/0/0 errors) Na pomalejším zařízení může taková kontrola trvat velmi dlouho. V mém případě na Cubieboardu 2 trvala zhruba 7 dní. Jako poslední krok jsem tehdy disk ještě přepsal náhodnými daty a připravil se tak na šifrování. Vykonání tohoto příkazu zabralo něco kolem 30 hodin: badblocks -c 10240 -s -w -t random -v /dev/sda ===== Problém s většími disky na 32bit systému ===== Na 32bitovém systému jsem narazil na problém při testování 8TB disku. ''badblocks'' skončil chybou o příliš velké hodnotě pro daný datový typ: badblocks -c 10240 -s -w -v /dev/sdb badblocks: Hodnota je příliš velká pro daný datový typ invalid end block (7814026584): must be 32-bit value Pomohlo zvětšení velikosti bloku: badblocks -b 4096 -s -w -v /dev/sdb Pro ověření geometrie disku se hodí: fdisk -l /dev/sdb Disk /dev/sdb: 7,28 TiB, 8001563222016 bytes, 15628053168 sectors Disk model: 002-2ZM188 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Pointa je v tom, že větší blok znamená menší počet adresovaných bloků, což obejde limit 32bitového adresování. Pro 8TB disk: * Při velikosti bloku 512 bytů: 8 TB / 512 B = 16 000 000 000 bloků * Při velikosti bloku 4096 bytů: 8 TB / 4096 B = 2 000 000 000 bloků Menší čísla bloků jsou pak adresovatelná i v 32bitovém systému. ===== Praktická poznámka k SSD a NVMe ===== Tento postup je zaměřený na rotační disky. U SSD a NVMe dává větší smysl vycházet z jejich vlastních diagnostických nástrojů, S.M.A.R.T./NVMe health dat a zbytečně je nevystavovat dlouhým destruktivním zápisovým testům přes celý disk. ===== Zdroje ===== * [[https://www.smartmontools.org/|smartmontools]] * [[https://man7.org/linux/man-pages/man8/badblocks.8.html|badblocks]] * [[https://www.armbian.com/cubieboard-2/|Cubie Board 2]] * [[https://www.armbian.com/|Armbian]] * [[https://www.root.cz/zpravicky/bac-kblaze-vydal-statistiky-poruchovosti-disku-za-rok-2018-pocet-zavad-klesa/|Backblaze – statistiky poruchovosti disků za rok 2018]] * [[https://www.root.cz/clanky/uvod-do-lvm/|root.cz: Úvod do LVM]] * [[https://www.root.cz/clanky/lvm-prakticke-ukazky/|root.cz: LVM – praktické ukázky]] * [[https://www.root.cz/clanky/jak-vytvorit-sifrovany-oddil-v-linuxu/|root.cz: Jak vytvořit šifrovaný oddíl v Linuxu]]