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:
- 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/
- 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
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:
- Smart status: Good!
- Overall assessment: Healthy
- Self tests: Success
- 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.
- 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.
