HDD, Luckybackup, fsck, GSmartControl, fstab etc

Tenho várias dúvidas, mas como elas são entrelaçadas, achei melhor não dispersá-las em vários tópicos. ─ Optei pela categoria “Linux”, pois não vejo como decidir sobre o hardware sem primeiro entender o que posso fazer com o fsck, GSmartControl etc. ─ De qualquer modo, já faz tempo que pretendo comprar 1 novo HDD, independente de haver ou não um “defeito físico” num dos atuais.

Luckybackup

Uso Luckybackup há mais de 5 anos, e só faço backup das partições de trabalho, onde tudo pertence ao “usuário”. ─ Todas as partições são ext4, tanto nos originais quanto nos backups.

Talvez por burrice, executo o Luckybackup em modo root ─ opção de 5 anos atrás, quando Kubuntu, Mint etc. ofereciam essa escolha. Naquela época, era comum “Dolphin as root”, “Kate as root” etc. ─ Hoje, só vejo isso no openSUSE.

Quando dá problema, em geral é nos arquivos ocultos que o próprio Luckybackup cria nos locais de destino. ─ Nesses casos, deleto os arquivos .luckybackup e deixo ele criar de novo.

Várias vezes já me perguntei se não seria melhor executá-lo sem privilégios. ─ Afinal, ele só vai lidar com arquivos pertencentes ao usuário.

Melhor ainda… Usar o rsync, diretamente, e como “usuário” comum. ─ Basta criar um script com os comandos. ─ Aproveito para estudar o significado dos parâmetros, e quem sabe altero algum deles:

  1. Depot1 >> Depot2
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /path/Depot1/Backup             /path/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /path/Depot1/Biblioteca         /path/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /path/Depot1/Fotos-digitais     /path/Depot2/
  1. Partitions >> Depot1
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /path/Warehouse    /path/Depot1/Backup/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /path/Works        /path/Depot1/Backup/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /path/Sites        /path/Depot1/Backup/

Ou seja, primeiro faço o backup geral da partição “Depot1” para “Depot2” ─ e depois, o backup das partições “Sites”, “Works”, “Warehouse” para a pasta “Depot1/Backup”.

  • Alguém vê algum motivo para continuar usando Luckybackup?
  • Alguma sugestão sobre esses comandos rsync ou sobre os parâmetros?
  • Algum motivo para continuar usando privilégios, em qualquer dos dois casos?

Como disse, tive raros problemas, durante 5 anos de ações rotineiras ─ mas às vezes faço “movimentações” maiores ─ por exemplo, quando deletei a partição “XTudo”, que não uso desde 2019.

Movi seu backup de /Depot1/Backup/XTudo para /Depot1/XTudo ─ e fiz a mesma coisa em “Depot2” ─ coisas que não exigiriam “mover” dados de um lugar para outro, mas “apenas” alterar o PATH de algumas centenas de milhares de arquivos, nas tabelas dessas partições.

Bom, pelo menos, “tentei mover”. Conseguir isso, me custou várias horas, ao longo de alguns dias, em várias tentativas. ─ A “herença” do Luckybackup foi uma barreira chata, apesar de eu já lidar com isso há vários anos

Não sei se o rsync vai criar arquivos ocultos nos locais de destino (como faz o Luckybackup), mas desde que eu não use privilégios, imagino que já não me criarão tantos problemas.

GSmartControl

2021-06-13_18-46-21_oSU-inicio-Malfunction-HDD-sdd-Warehouse-SMART-Status-KDE-5-22_CROP

Aquela “movimentação” foi na segunda metade de Maio. ─ E três semanas depois, o KDE resolveu me arranjar “novidades” ─ primeiro no openSUSE Tumbleweed, depois também no PCLinuxOS e no KDE Neon.

Toda vez que uma dessas 3 distros iniciava, lá vinha aquele aviso apavorante!

Clicando no aviso, abria-se a seção “Smart” do KInfocentre ─ tacando o terror.

Por coincidência, logo depois, um colega imaginou que seu HDD estaria apresentando falhas ─ e felizmente o @Deleterium debelou a situação. ─ Mas eu ainda fiquei com uma semente de incerteza.

Aquele aviso insidioso durou uns 30 dias (talvez o tempo de corrigirem o bug, ou “inconveniência”?) ─ depois, parou de aparecer ao inicializar o openSUSE ─ mas na seção “Smart” do KInfocentre o aviso assustador continuava presente.

No openSUSE, no KDE Neon e no PCLinuxOS, esta seção “Smart” do KInfocentre oferecia apenas um botão “Ignore” ─ coisa que não me interessava. ─ Nada de varrer para baixo do tapete.

No Debian testing ─ com um KDE menos avançado (e sabe-se lá quais outras diferenças, no que se refere à lista de pacotes instalados, configurações ativadas etc.) ─ nenhum aviso apavorante.

Encontrei nele os botões “Backup” e “Partition Manager” ─ este último, abre o KDE Partition Manager.

O KDE Partition Manager, por sua vez, oferece um relatório super-detalhado de “SMART properties” ─ onde pude ver:

  1. Smart status: Good!
  2. Overall assessment: Healthy
  3. Self tests: Success
  4. Powered On for: 70.903 horas ─ o que dá 2.954 dias de 24 horas = 8,1 anos sem desligar. ─ Naquele momento, esse HDD estava comigo havia 12 anos e alguns meses. A conta dá 2/3 = 16 horas ligado por dia. “Reservemos” esse número, diria a Youtuber de culinária.
  5. etc.

A versão “Save SMART Report” é mais crua, e assusta um pouco mais, por mostrar detalhes das vísceras ─ mas as conclusões à direita são exatamente as mesmas.

Mas àquela altura, eu já tinha contraído o vírus do hipocondríaco que coleciona bulas de remédios, artigos sobre doenças etc. ─ Encontrei o GSmartControl já instalado no PCLinuxOS ─ veio como dependência do “Plasma-Disks”, que apareceu em “Novo no repositório” em Outubro 2020.

Ele apresentou 2 abas com títulos em vermelho, e corri para olhar o “Error Log” ─ nada menos que 8 erros em vermelho brilhante! ─ coisa de fazer água na boca de qualquer hipocondríaco que se preze.

O mais recente desses erros foi registrado às 41.724 horas do “tempo de vida”; e o mais antigo, às 40.192 horas. ─ Pelas minhas contas, isso foi “há 29.000 horas atrás”, ou há 1.216 dias, ou há 3,33 anos. ─ Considerando aquela relação de 2/3 do tempo ligado, isso foi 5 anos antes de Julho 2021. Digamos então, +/- em Julho 2016.

Posso estar enganado na interpretação dos detalhes, e nessas contas ─ mas parece que foi-se pelo ralo minha expectativa de ver o pobre do HDD (de 2008!) estertorar até a morte nos próximos dias.

A diferença de umas 1.500 horas entre o primeiro e o último erro (acho que há um limite de “8 últimos erros”) equivale a uns 2 meses ─ ou 3 meses, considerando 16 horas ligado por dia.

O GSmartControl bem que tentou me animar: ─ “… could lead to a complete mechanical failure. Please backup” ─ mas eu já estava decepcionado e cético.

É verdade que, para um HDD morrer, basta estar vivo ─ já dizia minha avó. ─ É por isso que a gente faz backup.

De 30 Agosto a 3 Setembro scanneei uns 800 documentos no MX Linux e nos dias 2 e 4 achei bom ir fazer logo backups, pelo openSUSE, antes de prosseguir. ─ No dia 2, nenhum erro. ─ No dia 4, o Luckybackup indicou 402 erros.

É verdade que no dia 3 tinha caído a rede elétrica na minha rua, mas eu mal havia tinha o computador ─ coisa de 3 minutos uptime (entre 7:17 e 7:20). ─ Nem deu tempo de abrir o Konsole para testar a conexão e capturar a tela.

Deletei os arquivos ocultos do próprio Luckybackup, até onde pude, mas alguns não consegui, nem com reza braba. ─ Os erros caíram para 26. ─ Com mais algumas tentativas, os erros caíram para 13.

Eu nunca tinha encontrado uma barreira dessas, me impedindo de consertar a caca do Luckybackup.

Àquela altura, o openSUSE não conseguiu acabar de desmontar o drive SSD externo (USB). Registrei uns 5 minutos de “ampulheta girando”. Como desgraça pouca é bobagem, encerrei a demora com o velho R-E-I-S-U-B. ─ Logo em seguida, verifiquei a seção “SMART Status” do KInfocentre, no Mageia, e dizia que todas as unidades estavam bem, obrigado.

fsck

Para facilitar o uso do fsck, rodei uma sessão Live Mageia 7 KDE.

Logo durante o boot (verbose), já acusou “Buffer I/O error on dev sdb, logical block 7, lost async page write”.

Pelos inúmeros testes com lsblk, blkid, fsck etc. ─ bem documentados em TXT e capturas de tela ─ sei que não trocou as letras de nenhum disco.

Tratava-se, mesmo, do meu HDD mecânico mais “novo” (2016), de 1 TB ─ onde está meu 1º backup, “Depot1”.

Tentei vários comandos tune2fs, dumpe2fs, e2fsck etc., pesquisados na hora (aqui), mas não teve jeito. ─ No final de tudo, não saiu disso:

# fsck -f /dev/sdb1
fsck from util-linux 2.33.2
e2fsck 1.45.2 (27-May-2019)
Depot1: recovering journal
fsck.ext4: No such device or address while trying to re-open Depot1

Depot1: ********** WARNING: Filesystem still has errors **********

O que guardei sobre essa partição ─ para pesquisar com calma o que significa:

# dumpe2fs -h /dev/sdb1 | grep -i 'mount count'
dumpe2fs 1.45.2 (27-May-2019)
Mount count:              425
Maximum mount count:      -1

# dumpe2fs -h /dev/sdb1
dumpe2fs 1.45.2 (27-May-2019)
Filesystem volume name:   Depot1
Last mounted on:          /media/flavio/Depot1
Filesystem UUID:          1bf499a2-c2c2-4211-b3b8-2e116c619f6f
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              61054976
Block count:              244190208
Reserved block count:     12209510
Free blocks:              116745191
Free inodes:              60430507
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      965
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Wed Feb 26 13:54:34 2020
Last mount time:          Sun Sep  5 14:42:57 2021
Last write time:          Sun Sep  5 14:42:57 2021
Mount count:              425
Maximum mount count:      -1
Last checked:             Sun May 23 23:36:56 2021
Check interval:           0 (<none>)
Lifetime writes:          747 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      6193264e-0967-4859-9254-a05994072cb5
Journal backup:           inode blocks
FS Error count:           1
First error time:         Sat Sep  4 10:47:44 2021
First error function:     ext4_journal_check_start
First error line #:       83
First error inode #:      0
First error block #:      0
Last error time:          Sat Sep  4 10:47:44 2021
Last error function:      ext4_journal_check_start
Last error line #:        83
Last error inode #:       0
Last error block #:       0
Checksum type:            crc32c
Checksum:                 0xeffa3bdc
Journal features:         journal_incompat_revoke journal_checksum_v3
Journal size:             1024M
Journal length:           262144
Journal sequence:         0x00004016
Journal start:            1
Journal checksum type:    crc32c
Journal checksum:         0x5313e68f

As partições-raiz e home estavam Ok, no geral. ─ Recomendou outras ferramentas para as do openSUSE (BtrFS, XFS). ─ O detalhe interessante ficou por conta da partição-raiz do MX Linux, que não estava 100% católica, e continuou assim, mesmo após repetir a tentativa de consertar:

# fsck /dev/sda13
fsck from util-linux 2.33.2
e2fsck 1.45.2 (27-May-2019)
Linux12: ignoring check interval, broken_system_clock set
Linux12: clean, 341571/1966080 files, 2273447/7864320 blocks

Imagino que isso pode ter contribuído, pelo menos em parte, para o surgimento do problema.

De qualquer modo, ficou claro que eu não sabia fazer mais do que digitar “fsck /dev/sdXn” e esperar que resolvesse tudo. ─ Se é que não se trate de algum problema “físico”, fora do alcance do software.

Para qualquer outra coisa, tinha de pesquisar na hora ─ e sem meus bookmarks sincronizados pelo Chromium / Google, perdi muito tempo, sem encontrar muita coisa útil.

Só no caso da partição “Sites”, a primeira execução do fsck já bastou para corrigir alguma coisinha:

# fsck /dev/sdc1
fsck from util-linux 2.33.2
e2fsck 1.45.2 (27-May-2019)
Sites primary superblock features different from backup, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Sites: 16017/786432 files (0.1% non-contiguous), 399515/3145728 blocks

# fsck /dev/sdc1
fsck from util-linux 2.33.2
e2fsck 1.45.2 (27-May-2019)
Sites: clean, 16017/786432 files, 399515/3145728 blocks

Uma grata surpresa: ─ Nenhum problema em “Warehouse” ─ minha partição de uso diário (inclusive os scanneamentos), naquele disco com 8 falhas em vermelho berrante:

# fsck /dev/sdd1
fsck from util-linux 2.33.2
e2fsck 1.45.2 (27-May-2019)
Warehouse: clean, 62344/19537920 files, 22615247/78142464 blocks

Feitas as contas, não consegui quase nada ─ exceto testar todas as partições rapidamente, com alguma comodidade, e registrar os detalhes das partições que apresentam problemas.

Não deixa de ser um bom começo, pois até então, eu me sentia totalmente perdido, em meio àquela enxurrada de dados do KInfocentre ─ contraditórios, conforme a versão do KDE ─ e do GSmartControl:

  • A partição Depot1 tem erros no “journal” ─ e tenho algumas palavras-chave para pesquisar. ─ Pode ser problema físico? Pelo meu fraco conhecimento, não dá para descartar essa possibilidade, mas vale tentar pelo lado soft, primeiro.
  • A partição-raiz do MX Linux tem um problema de relojoeiro
  • A partição Warehouse está bem de saúde

Terminada essa colheita, carreguei algumas distros:

  • MX Linux não conseguiu montar Depot1 (18:51). ─ Tentei de novo, continuou sem conseguir (19:05):
# cat /var/log/messages | grep sdb1
Sep  5 18:51:37 Linux13 kernel: [    2.124960]  sdb: sdb1
Sep  5 18:51:56 Linux13 kernel: [   32.077588] EXT4-fs warning (device sdb1): ext4_clear_journal_err:5628: Filesystem error recorded from previous mount: Journal has aborted
Sep  5 18:51:56 Linux13 kernel: [   32.077592] EXT4-fs warning (device sdb1): ext4_clear_journal_err:5630: Marking fs in need of filesystem check.
Sep  5 18:51:56 Linux13 kernel: [   32.080644] EXT4-fs (sdb1): warning: mounting fs with errors, running e2fsck is recommended
Sep  5 19:05:21 Linux13 kernel: [    2.884452]  sdb: sdb1
Sep  5 19:05:40 Linux13 kernel: [   32.022911] EXT4-fs warning (device sdb1): ext4_clear_journal_err:5628: Filesystem error recorded from previous mount: Journal has aborted
Sep  5 19:05:40 Linux13 kernel: [   32.022915] EXT4-fs warning (device sdb1): ext4_clear_journal_err:5630: Marking fs in need of filesystem check.
Sep  5 19:05:40 Linux13 kernel: [   32.026041] EXT4-fs (sdb1): warning: mounting fs with errors, running e2fsck is recommended

  • Slackware, Neon, Manjaro, montaram normalmente Depot1. ─ Tudo muito “good”:

Falta ler e começar a testar alguns comandos “smartctl” ─ ou aprender o quê configurar no GSmartControl ─ mas nessa hora, claro, meu provedor me deixou 12 horas fora do ar.

fstab

Falta ler mais sobre aquele par de números no final das linhas do fstab ─ e que sempre deixei tal como vêm “de fábrica”.

O Debian é a única distro em que uso o fstab para montar partições “extras”, como Warehouse e Depot1, por exemplo. ─ Alterei os últimos números para ver se isto será de algum proveito.

E instalei o GSmartControl no Debian, que ainda não tinha.

Com essas 2 providências, é no Debian que vou ficar por uns dias, enquanto pesquiso, leio, experimento, para ver se obtenho algum resultado prático.

HDD

A loja da esquina tem Seagate barracuda ─ por acaso, o mesmo (ou quase o mesmo) que apresenta problema, embora seja o mais novo dos HDDs mecânicos que tenho. ─ Tem 3,9 anos “powered on”.

(É chato admitir que os mais antigos, mais lentos, de apenas 320 MB, não apresentem sintomas, após 12 anos de uso. ─ Eram eles, que eu gostaria de estar substituindo).

A loja mais bem aparelhada, a 20 km, tem barracuda e tem Toshiba. ─ A diferença de preço no barracuda não cobre um Uber até a metade do caminho. ─ O Toshiba é mais barato, o que me dá medo.

As lojas a 800+ km têm esses, além de WDs e alguns outros mais caros. A diferença de preço no barracuda, o frete engole. Escolher outro mais caro, só depois de ler e ouvir muita fofoca contra o barracuda.

De qualquer modo, vou começar pelos cabos. Pelo menos 2 ainda são antigos, e sem presilhas. Cabo é barato. Posso comprar 4, trocar os 2 antigos, e ir experimentando trocar os outros, 1 de cada vez, para ver se causa algum milagre.

Conclusão

Não há conclusões. Por enquanto, apenas reuni os dados sobre a situação e levantei os tópicos que preciso ler e pesquisar.

E conto com vocês para me contarem todas as fofocas sobre as várias marcas e modelos de HDD, claro.

2 curtidas

Considerações:

Eu uso o KUP, ferramenta de backup simples integrada ao kde. Ele roda com rsync por baixo dos panos. O rsync não cria nenhum arquivo.

Todos os dispositivos de armazenamento tem problemas de “silent corruption” em maior ou menor grau. Se a integridade dos dados é necessária em grau absoluto, vc vai precisar de redundância nos dados e executar um “scrub test” periodicamente para corrigir esses erros. Daí vc vai precisar mudar de sistema de arquivos dos seus discos para zfs, lvm, ou gerenciar via software em NAS ou coisas profissionais que eu não sei em detalhe. Pessoalmente nas minhas fotos eu uso o Krusader e uma opção para guardar um hash do arquivo. Posso então mandar checar o hash e garantir que todas as fotos estão perfeitas. Acredite que eu já tive fotos que se corromperam “sozinhas”. Como tenho dois backups, já cheguei a salvar o backup do meu site antigo, que estava corrompido no backup mais novo mas estava íntegro no mais no antigo, daí atualizei o backup novo com o arquivo do backup antigo. Isso era arquivo de quase 20 anos de idade.

HDD com 70 mil horas, pra mim, é de baixa confiabilidade. A gente tende a acreditar que esse que está funcionando é bom porque é das antigas, mas a realidade é que os ‘irmãos’ desse hd que morreram com 30 mil horas já foram esquecidos. É algo como inferir que as pessoas que nasceram em 1940 eram mais resistentes porque hoje elas estão com 80 anos e ainda estão vivas!

Erro ‘lost async page write’ me dá arrepios, ainda mais no bloco 7 que fica na tabela de partição do disco. Tomara que seja problema do conector!

fsck não ajuda nada quando o problema é de hardware. Nesses casos só o ‘smartctl’ pra dar alguma informação, ou como último suspiro tentar uma formatação de baixo nível por ele.

man fstab já dá a informação sobre os numeros do quinto e sexto campo. Pessoalmente eu nunca vi o sistema checar automaticamente um disco na inicialização, por isso acho que eles não importam, ao menos atualmente.

Marca de hd: Já comprei seagate bom, seagate ruim, WD bom, WD ruim, e um toshiba lento que tbm é um “mun-rá”. Pessoalmente eu acho que é loteria, que depende do balanceamento do disco na fabricação e alguns saem “quase perfeitos” e são bastante duradouros, outros saem no limite da tolerância de aceitação e vão durar o mínimo coberto pela garantia.

2 curtidas

Aqui explico como ler o tempo de vida útil do ssd

The SSD_Life_Left Attribute of my new SandForce based SSD reports zero

It doesn’t. The RAW value of this attribute is always 0 and has no meaning. Check the normalized VALUE instead. It starts at 100 and indicates the approximate percentage of SDD life left. It typically decreases when Flash blocks are marked as bad, see the RAW value of Retired_Block_Count:

Fonte

https://www.smartmontools.org/wiki/FAQ#Iseesomestrangeoutputfromsmartctl.Whatdoesitmean

1 curtida

No tópico explico como medir velocidade do ssd ou hdd no Linux e no Windows.

1 curtida

Estou me concentrando nos 2 HDDs mecânicos que se encontram “sob suspeita” imediata:

# lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT

sdb       8:16   0 931.5G  0 disk   HDD  Sata3  Seagate   ST1000DM003-1SB102   1  TB -- 2016
└─sdb1    8:17   0 931.5G  0 part   ----------------> Depot1

sdd       8:48   0 298.1G  0 disk   HDD  Sata2  Samsung   HD322HJ             320 GB -- 2008
└─sdd1    8:49   0 298.1G  0 part   ----------------> Warehouse

Ambos têm apenas 1 partição:

  • Depot1 – (sdb1) – que é meu backup primário.

  • Warehouse– (sdc1) – onde gravo tudo no dia-a-dia

Uma pesquisa por “lost async page write” (com aspas duplas) deu inúmeros resultados “não exatamente iguais”, envolvendo situações muito distantes da minha. – Vai-se minha esperança depositada em palavras-chave.

Não parece ter nada a ver com badblocks, mas segui o link para o artigo do Dio, e verifiquei mesmo assim:

# badblocks -nsv -c 1024 /dev/sdb1
Tue  7 Sep 12:27:10 -03 2021
Checking for bad blocks in non-destructive read-write mode
From block 0 to 976760831
Checking for bad blocks (non-destructive read-write test)

Testing with random pattern: 2.35% done, 13:47 elapsed. (0/0/0 errors)s)s)

Interrupted at block 22991872

Catei mais algumas informações:

# smartctl --info /dev/sdb

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda 7200.14 (AF)
Device Model:     ST1000DM003-1SB102
Serial Number:    W9A3ZBDM
LU WWN Device Id: 5 000c50 09c9d9dad
Firmware Version: CC43
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Sep  7 12:44:41 2021 -03
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

# smartctl --info /dev/sdd

=== START OF INFORMATION SECTION ===
Model Family:     SAMSUNG SpinPoint F1 DT
Device Model:     SAMSUNG HD322HJ
Serial Number:    S1G2J50QB76878
LU WWN Device Id: 5 0000f0 00b7b8687
Firmware Version: 1AC01113
User Capacity:    320,072,933,376 bytes [320 GB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA/ATAPI-7, ATA8-ACS T13/1699-D revision 3b
Local Time is:    Tue Sep  7 12:45:31 2021 -03
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Uns testes rápidos:

# smartctl -t short /dev/sdb
Test will complete after Tue Sep  7 13:48:03 2021 -03

# smartctl -H /dev/sdb
SMART overall-health self-assessment test result: PASSED


# smartctl -t short /dev/sdd
Test will complete after Tue Sep  7 13:53:17 2021 -03

# smartctl -H /dev/sdd
SMART overall-health self-assessment test result: PASSED

Mais alguns resultados:

# smartctl -A /dev/sdb

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   080   063   006    Pre-fail  Always       -       106245352
  3 Spin_Up_Time            0x0003   099   097   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   099   099   020    Old_age   Always       -       1531
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   082   060   045    Pre-fail  Always       -       186151903
  9 Power_On_Hours          0x0032   061   061   000    Old_age   Always       -       34539
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   020    Old_age   Always       -       1517
183 Runtime_Bad_Block       0x0032   079   079   000    Old_age   Always       -       21
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   082   000    Old_age   Always       -       0 0 56
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   058   052   040    Old_age   Always       -       42 (Min/Max 25/44)
193 Load_Cycle_Count        0x0032   099   099   000    Old_age   Always       -       2365
194 Temperature_Celsius     0x0022   042   014   000    Old_age   Always       -       42 (0 14 0 0 0)
195 Hardware_ECC_Recovered  0x001a   011   001   000    Old_age   Always       -       106245352
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   169   000    Old_age   Always       -       873
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       32380h+37m+02.044s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       14244576863
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       12787823001


# smartctl -A /dev/sdd

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   093   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0007   094   094   011    Pre-fail  Always       -       2880
  4 Start_Stop_Count        0x0032   095   095   000    Old_age   Always       -       5548
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   100   100   051    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0025   100   100   015    Pre-fail  Offline      -       9603
  9 Power_On_Hours          0x0032   086   086   000    Old_age   Always       -       72212
 10 Spin_Retry_Count        0x0033   100   100   051    Pre-fail  Always       -       1
 11 Calibration_Retry_Count 0x0012   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   095   095   000    Old_age   Always       -       5535
 13 Read_Soft_Error_Rate    0x000e   100   093   000    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   000    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       466
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   066   055   000    Old_age   Always       -       34 (Min/Max 21/34)
194 Temperature_Celsius     0x0022   063   052   000    Old_age   Always       -       37 (Min/Max 21/38)
195 Hardware_ECC_Recovered  0x001a   100   100   000    Old_age   Always       -       25665
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   100   100   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x000a   100   100   000    Old_age   Always       -       0
201 Soft_Read_Error_Rate    0x000a   253   253   000    Old_age   Always       -       0

Mais um histórico:

# smartctl -l selftest /dev/sdb

=== 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  Short offline       Completed without error       00%     34539         -
# 2  Extended offline    Interrupted (host reset)      00%     34502         -
# 3  Short offline       Completed without error       00%     34477         -
# 4  Short offline       Completed without error       00%     34391         -
# 5  Short offline       Completed without error       00%     34246         -
# 6  Short offline       Completed without error       00%     34112         -
# 7  Short offline       Completed without error       00%     33947         -
# 8  Extended offline    Completed without error       00%     33785         -
# 9  Extended offline    Completed without error       00%     33256         -
#10  Extended offline    Interrupted (host reset)      50%     33150         -
#11  Short offline       Completed without error       00%     33017         -
#12  Extended offline    Completed without error       00%     32851         -
#13  Short offline       Completed without error       00%     32441         -
#14  Short offline       Completed without error       00%     32375         -
#15  Short offline       Completed without error       00%     32195         -
#16  Short offline       Completed without error       00%     32171         -
#17  Short offline       Completed without error       00%     32147         -
#18  Short offline       Completed without error       00%     32136         -
#19  Short offline       Completed without error       00%     32030         -
#20  Short offline       Completed without error       00%     32017         -
#21  Short offline       Interrupted (host reset)      20%     31798         -


# smartctl -l selftest /dev/sdd

=== 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  Short offline       Completed without error       00%      6675         -
# 2  Extended offline    Completed without error       00%      6640         -
# 3  Short offline       Completed without error       00%      6614         -
# 4  Short offline       Completed without error       00%      6528         -
# 5  Short offline       Completed without error       00%      6383         -
# 6  Short offline       Completed without error       00%      6250         -
# 7  Short offline       Completed without error       00%      6084         -
# 8  Extended offline    Completed without error       00%      5922         -
# 9  Short offline       Completed without error       00%      5421         -
#10  Extended offline    Completed without error       00%      5388         -
#11  Extended offline    Interrupted (host reset)      10%      5282         -
#12  Short offline       Completed without error       60%      5149         -
#13  Extended offline    Completed without error       00%      4982         -
#14  Short offline       Completed without error       00%      4574         -
#15  Short offline       Completed without error       00%      4507         -
#16  Short offline       Completed without error       00%      4328         -
#17  Short offline       Completed without error       00%      4304         -
#18  Short offline       Completed without error       00%      4280         -
#19  Short offline       Completed without error       00%      4268         -
#20  Short offline       Completed without error       00%      4163         -
#21  Short offline       Completed without error       00%      4150         -

Imagino que boa parte dessas informações já estejam nas cópias que fiz dos relatórios do GSmartControl e do KDE Partition Manager sobre o SMART status.

Parece bonito, mas para mim ainda acrescenta muito pouco, ou quase nada.

(Sobre o GSmartcontrol e derivados)O bom pra tirar suspeitas e usando softwares no Windows(como o cristaldiskinfo), no Linux parece que esses softwares não tem calibragem nenhuma pra identificar coisas sensíveis em hardware

Obrigado por falar desse pacote do KDE. ─ Eu estava no Debian hoje, abri o Synaptic para pesquisar, e descobri que eu já tinha o kup-backup. Foi instalado “automaticamente” com a atualização de 31 Dezembro 2020, junto com o bup, o plasma-disk e o smartmontools. Não parece ser dependência de nenhum pacote, pois sua “remoção completa” não afeta nenhum outro. Enfim, não sei por quê o Debian o incluiu naquela atualização de fim de ano. Se não fosse KDE, poderia jurar que foi obra de algum gnomo.

Isso explica por que a seção “SMART Devices” do KInfocentre do Debian oferece o botão “Backup”.

Não encontrei o kup-backup na lista de pacotes instalados em nenhuma das outras distros, aqui.

As propostas do kup-backup não são exatamente o que eu queria, mas consegui encontrar e alterar rapidamente todas as opções, para deixar ao meu gosto.

Fiz um teste e o resultado foi perfeito. Criei um “Plano” de backup, só com a pasta de documentos scanneados, escolhi o tipo rsync, e num instante criou o backup, com o número exato de arquivos e subpastas da pasta original.

Agora vou comparar o comando usado pelo kup-backup com o comando usado pelo Luckybackup ─ um bom começo para aprender sobre os parâmetros do rsync:

Luckybackup:

rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after   /path/Sites      /path/Backup/

kup-backup:

rsync "-avX" "--delete-excluded" "--delete-before" "--info=progress2" "/path/Scanner"  "/path/Backup/"

Portanto, essa parte da solução parece bem encaminhada, seja usando o KUP, seja usando diretamente comandos rsync.

De qualquer modo, eu precisava eliminar todos os arquivos pertencentes ao root, tanto nas partições de origem quanto nas partições de backup.

Com ajuda do KFind foi muito fácil localizar todos esses arquivos ─ e eliminá-los pelo mc com privilégios, ou transferir a propriedade de alguns arquivos para o usuário.

Um pouco mais complicado, foi localizar uns 5.725 arquivos read-only que descobri ─ velhos arquivos de fontes TTF; e um monte de fotos do antigo celular WindowsPhone, que na época eu baixava por cabo USB. ─ Agora que sei onde estão, fica fácil alterar em massa suas permissões:

tree -f -p | grep -v rw > read-only-files.txt

EDIT: - Afinal, foi mais simples executar, em cada uma das 5 partições de documentos do usuário:

$ sudo chmod -R +rw *

Eu costumava notar isso durante o boot do Mint, pois exibia uma mensagem durante o splash. Não sei era só devido a essa opção no fstab. Lembro que havia uma contagem de número de inicializações. ─ Com o tempo, passei a trocar o splash pelo verbose do boot, e vejo que acontece em algumas distros (não lembro quais). ─ Mas isso, para a partição-raiz, quando o número é 1.

Ainda não sei se isso basta, para que minhas partições de dados sejam verificadas regularmente. Colocar o número 2 para elas, no fstab, foi só um primeiro passo. Preciso ver se é preciso habilitar mais algum serviço.

Quanto ao número anterior (dup), tenho certeza de que jamais resultou em backup da partição-raiz. Um negócio desse tamanho seria evidente demais. Mas é coisa que resolvi por outro caminho: ─ Ter várias distros em dualboot… e não ficar fazendo traquinagens demais.

Cheguei a uma solução satisfatória, usando apenas o rsync:

time rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Warehouse /run/media/flavio/Depot1/Backup/; date
time rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Works     /run/media/flavio/Depot1/Backup/; date
time rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Sites     /run/media/flavio/Depot1/Backup/; date

time rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after  /run/media/flavio/Depot1/  /run/media/flavio/Depot2/; date

Primeiro, tentei o comando do KUP, mas cometi um errinho bobo, e a primeira coisa que aconteceu foi apagar imediatamente os backups de 3 partições, com centenas de milhares de arquivos.

O errinho bobo foi colocar uma barra no final do nome da partição de origem:

/run/media/flavio/Warehouse/

Isto, somado ao parâmetro --delete-before garantiu a destruição instantânea. – Mas se usasse --delete-after aconteceria a mesma coisa – com a diferença de que eu só ficaria sabendo no final.

Eu bem que poderia ter feito um teste (dry-run), primeiro, com o parâmetro -n

No último comando, sim, interessa a barra no final da partição de origem, para copiar o conteúdo de uma partição “diretamente” na outra – ao invés de criar uma “pasta” com o conteúdo da partiçao de origem:

/run/media/flavio/Depot1/

No geral, os comandos do KUP e do Luckybackup são muito parecidos.

Onde o Luckybackup usa -r -tgo -p -l -D, o KUP usa -avX, onde o -a = -rlptgoD (no -H,-A,-X).

No mais, preferi --delete-after em vez de --delete-before – e para não ficar fazendo mil tentativas e erros, para testar cada parâmetro, adotei logo o comando do Luckybackup.

Luckybackup:

    rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after   /path/Sites      /path/Backup/

-h   --human-readable    output numbers in a human-readable format
     --progress          show progress during transfer
     --stats             give some file-transfer stats
-r   --recursive         recurse into directories
-t   --times             preserve modification times
-g   --group             preserve group
-o   --owner             preserve owner (super-user only)
-p   --perms             preserve permissions
-l   --links             copy symlinks as symlinks
-D                       same as --devices --specials
-u   --update            skip files that are newer on the receiver
     --delete-after      receiver deletes after transfer, not during

kup-backup:

    rsync "-avX" "--delete-excluded" "--delete-before" "--info=progress2" "/path/Scanner"  "/path/Backup/"

-a   --archive           archive mode; equals -rlptgoD (no -H,-A,-X)
-v   --verbose           increase verbosity
-X   --xattrs            preserve extended attributes
     --delete-excluded   also delete excluded files from dest dirs
     --delete-before     receiver deletes before xfer, not during
     --info=FLAGS        This option lets you have fine-grained control over the information output you want to see.
                         An individual flag name may be followed by a level number, with 0 meaning to silence that output, 1 being the default output level, and higher numbers increasing the output of that flag (for those that support higher levels).
                         Use --info=help to see all the available flag names, what they output, and what flag names are added for each increase in the verbose level.

                         $ rsync --info=help
                         Use OPT or OPT1 for level 1 output, OPT2 for level 2, etc.; OPT0 silences.

Afora o “pequeno acidente”, tudo transcorreu com perfeição.

Refazer os 3 backups levou 17 minutos (Warehouse) + 23 minutos (Works) + 1 minuto (Sites).

EDIT: - Note que o segundo backup (em Depot2) não foi afetado – Continuou íntegro.

Na segunda parte – de Depot1 para Depot2 – a maior demora foi de 1 minuto na pasta com os 3 backups, pois bastava copiar os arquivos mais recentes. Para as outras pastas, a demora variou de 10 segundos até frações de segundo.

Nenhuma falha de nenhum HDD, nem do SSD-USB externo de 2011.

Isso não impede que os HDDs estejam à beira de um colapso – inclusive o mais “novo”, comprado por último. – Por isso me preocupo em ter pelo menos 1 backup de todos os arquivos, e nos casos mais críticos 2 backups, atualizados todas as semanas.

Só falta manter os backups em prédios diferentes e bem afastados – afinal, se minha casa for assaltada, explodir ou pegar fogo, de nada terão adiantado 1.000 backups… no mesmo chassi do mesmo PC. :sob:

Sim, a “lógica” do “backup” deve, necessariamente, levar em conta esse tipo de detalhes: – Assalto e roubo do PC, ataque por um drone dos EUA a um casamento no lote vizinho, incêndio “natural” y otras cositas más.

Hardware, SMART & fsck

Rodei mais uma sessão Live, para novos testes com smartctl e novas verificações com o fsck.

Comecei por um # smartctl -t long para todas as unidades – alguns com previsão de 30 minutos, outros com previsão de 4 horas-- e à medida que cada um se completava, fui colhendo os dados e salvando em TXT:

smartctl --info      /dev/sdX
smartctl -a          /dev/sdX
smartctl -x          /dev/sdX
smartctl -c          /dev/sdX
smartctl -H          /dev/sdX
smartctl -A          /dev/sdX
smartctl -l selftest /dev/sdX

Vários desses relatórios estão incluídos em outros, de modo que há repetições (por exemplo, o primeiro está incluído no segundo). Preferi pecar por excesso de dados, a deixar algum faltando.

Interpretar todos esses dados, são outros 500.

De qualquer modo, vou comprar um HDD de 1TB e substituir os dois HDDs mais antigos, de 320 GB. – Isso já facilita ter 2 backups de tudo. – Se o preço for bom, compro 2 HDDs. Mas acho improvável, além de não tão necessário.

2 curtidas

Normalmente uso para cópia

rsync -rtpl --info=progress2 pasta

1 curtida
-r   --recursive         recurse into directories
-t   --times             preserve modification times
-p   --perms             preserve permissions
-l   --links             copy symlinks as symlinks

Por que só isso?

Por que não mais do que isso?

Por que não, menos do que isso?

Por algum motivo, os primeiros 3 comandos continunua funcionando bem – mas o último não funcionou mais.

Hoje, suponho que devido à barra “/” no final de /Depot1/ – coisa que não pus nos primeiros 3 comandos.

Naqueles dias, não percebi isso, e acabei criando 2 scripts – nos quais não cometi esse erro – e fiquei achando que o problema fosse um outro qualquer, misterioso.

backup-0-1.sh

time rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Warehouse /run/media/flavio/Depot1/Backup/; date
time rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Works     /run/media/flavio/Depot1/Backup/; date
time rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Sites     /run/media/flavio/Depot1/Backup/; date

E passei a usar esses 2 comandos, mais simples:

$ history
761  2021-10-17_15-34-18 bash backup-1-2.sh
763  2021-10-17_15-38-44 bash backup-0-1.sh

Sempre fazendo, primeiro, o backup de Depot1 para Depot2 – e em seguida, o backup das 3 partições para o Depot1.

HDD novo, de 1 TB.

Rodando uma Live MX Linux 21.

Resolvi começar por um teste longo:

smartctl -t long     /dev/sdb

Diz que vai terminar às 20:50, mas devolveu o controle para o prompt. Quer dizer que nunca vou saber com certeza, se acabou antes, ou se ainda não acabou, quando chegar a hora.

Depois, vou recolher todas as informações que consigo imaginar:

smartctl --info      /dev/sdb
smartctl -a          /dev/sdb
smartctl -x          /dev/sdb
smartctl -c          /dev/sdb
smartctl -H          /dev/sdb
smartctl -A          /dev/sdb
smartctl -l selftest /dev/sdb

(alguns são redundantes, mas informação que abunda não prejudica).

Aproveitei para instalar o Chromium, sincronizar, e me divertir um pouco, porque 108 minutos são quase 2 horas.