Sei lá e pans

debian

Recentemente perdi meu servidor principal de casa. Os discos do pool zroot estavam ruins, e quando fui trocar um, puf, a máquina parou de dar boot. Retornar os discos anteriores não dava muito resultado, já que a máquina ficava trava em erros de discos. Acho que consegui uma falha em ambos os discos do pool zroot, parabéns para mim.

Esperançoso que o pool onde realmente estão os dados estava intacto, comecei a tarefa de tentar recuperar tudo. Felizmente, dada situações pregressas, eu tinha pelo menos alguma idéia de quais os discos realmente estavam envolvidos no pool que queria recuperar.

Desde o meu post anterior sobre zfs, comecei a usar a boa prática de adicionar os discos pelo seu número serial, conforme estão em /dev/disk/by-uuid em vez de usar os clássicos /dev/sdX ou coisa assim, que as vezes mudam a qual disco se referem. Pelo menos comigo, aconteceu mais de uma vez.

Enfim, após reinstalar o sistema em um disco a parte (resolvi por enquanto abandonar a idéia de ter o root em zfs) começa o trabalho de descobrir quais discos fazem parte do pool e remonta-lo Após preparar o novo sistema para o zfs e adicionar alguns discos do pool antigo, um simples zpool import começou a me encher de esperança

  pool: dados
     id: 1176411848024315794
  state: DEGRADED
status: The pool was last accessed by another system.
 action: The pool can be imported despite missing or damaged devices.  The
	fault tolerance of the pool may be compromised if imported.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-EY
 config:

	dados                          DEGRADED
	  raidz1-0                     DEGRADED
	    ata-ST32000644NS_9WM7LQT3  ONLINE
	    ata-ST32000644NS_9WM7N07E  UNAVAIL
	    wwn-0x5000cca224c5ea5c     ONLINE

Otimo, o pool estava lá. Com um disco a menos, mas estava lá. A partir daí, um zpool import dados -f fez o trabalho de deixar o pool disponível.

agora, para substituição do disco ausente, coloquei o pool offline com zpool offline dados ata-ST32000644NS_9WM7N07E e depois um zpool replace dados ata-ST32000644NS_9WM7N07E /dev/disk/by-id/ata-ST32000644NS_9WM7KY7S como sempre, tomando cuidado para usar o /dev/by-id para evitar que os discos se movimentem para um outro /dev/sdX em alguma manipulação futura dos cabos.

dessa forma, só bastou fazer um zfs mount -a e pronto, os datasets estavam montados e disponíveis.

Agora é configurar snapshots e backups para não precisar contar com a sorte no próximo incidente :)

#zfs #debian #recovery

Uma nova versão dos arquivos source.list, no modelo chamado deb822 está em curso no #debian. Eu fiz recentemente a atualização em um Debian Trixie. Tudo teria dado certo, exceto pelo erro abaixo

Notice: Missing Signed-By in the sources.list(5) entry for 'http://deb.debian.org/debian'

Humm. teria eu feito algo de errado?

Resolvi dar uma olhada nos novos arquivos de source.list gerados, agora presentes em /etc/apt/sources.list.d/

Logo encontrei o erro no arquivo debian-backports.source:

# Modernized from /etc/apt/sources.list
Types: deb deb-src
URIs: http://deb.debian.org/debian/
Suites: trixie-backports
Components: main contrib non-free non-free-firmware
Signed-By:

O campo Signed-By: havia ficado em branco. Ao fuçar um pouco no site do debian, achei isso, sugerindo que preenche o campo com /usr/share/keyrings/debian-archive-keyring.gpg

Feito isso e pans, problema resolvido :) vamos esperar que isso seja corrigido no modernize-sources antes do lançamento do Debian Trixie

#debian #apt #modernize-sources

Esses dias mexendo com o pool ZFS na minha máquina, notei algo. De vez enquando, alguns HDs dão problema (sou quebrado, então são reaproveitados de discos descomissionados que iriam ser descartados). Normalmente bastaria fazer um zpool replace <nome do pool>/dev/<disco ruim> /dev/<disco novo>. Perfeito, tudo muito simples, mas tem um detalhe... E quando você não sabe o disco que quer substituir? Eu explico, obviamente, você quer trocar o disco defeituoso, mas nem sempre as informações do zpool status são tão claras quanto eu gostaria.

Por exemplo, olhe isso aqui:

  pool: dados
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
	continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Wed Feb 19 11:27:10 2025
	389G scanned at 862M/s, 34.8G issued at 77.2M/s, 389G total
	34.8G resilvered, 8.96% done, 01:18:15 to go
config:

	NAME                             STATE     READ WRITE CKSUM
	dados                            DEGRADED     0     0     0
	  mirror-0                       DEGRADED     0     0     0
	    replacing-0                  DEGRADED     0     0     0
	      16849396304634906415       UNAVAIL      0     0     0  was /dev/sda1
	      ata-ST32000644NS_9WM5X8TR  ONLINE       0     0     0  (resilvering)
	    sdb                          ONLINE       0     0     0

errors: No known data errors

Nesse caso, temos esse disco com esse identificador “16849396304634906415”. Como saber no fim das contas, qual disco é esse? Ele já foi /dev/sda1, mas como o meu lsblk mostra:

# lsblk 
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 111,8G  0 disk 
sdb      8:16   0   1,8T  0 disk 
├─sdb1   8:17   0   1,8T  0 part 
└─sdb9   8:25   0     8M  0 part 
sdc      8:32   0 223,6G  0 disk 
├─sdc1   8:33   0   512M  0 part /boot/efi
├─sdc2   8:34   0 222,1G  0 part /
└─sdc3   8:35   0   976M  0 part [SWAP]
sdd      8:48   0   1,8T  0 disk 
├─sdd1   8:49   0   1,8T  0 part 
└─sdd9   8:57   0     8M  0 part 
sde      8:64   1     0B  0 disk

esse não é necessáriamente mais o caso, visto que meu pool usa discos de 1.8TB e o atual /dev/sda tem apenas 111,8GB.

Não me pergunte porque, mas essas coisas acontecem. Em todo caso, decidi tomar um novo caminho, a partir de agora, faço os pools a a partir que consta em /dev/disk/by-id

# ls -l /dev/disk/by-id/
total 0
lrwxrwxrwx 1 root root  9 fev 19 11:07 ata-KINGSTON_SUV300S37A240G_50026B72630171DA -> ../../sdc
lrwxrwxrwx 1 root root 10 fev 19 11:07 ata-KINGSTON_SUV300S37A240G_50026B72630171DA-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 fev 19 11:07 ata-KINGSTON_SUV300S37A240G_50026B72630171DA-part2 -> ../../sdc2
lrwxrwxrwx 1 root root 10 fev 19 11:07 ata-KINGSTON_SUV300S37A240G_50026B72630171DA-part3 -> ../../sdc3
lrwxrwxrwx 1 root root  9 fev 19 11:07 ata-SATA_SSD_181210101001015 -> ../../sda
lrwxrwxrwx 1 root root  9 fev 19 11:27 ata-ST32000644NS_9WM5X8TR -> ../../sdd
lrwxrwxrwx 1 root root 10 fev 19 11:27 ata-ST32000644NS_9WM5X8TR-part1 -> ../../sdd1
lrwxrwxrwx 1 root root 10 fev 19 11:27 ata-ST32000644NS_9WM5X8TR-part9 -> ../../sdd9
lrwxrwxrwx 1 root root  9 fev 19 11:07 ata-ST32000644NS_9WM7KRXX -> ../../sdb
lrwxrwxrwx 1 root root 10 fev 19 11:07 ata-ST32000644NS_9WM7KRXX-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 fev 19 11:07 ata-ST32000644NS_9WM7KRXX-part9 -> ../../sdb9
lrwxrwxrwx 1 root root  9 fev 19 11:07 usb-Multiple_Card_Reader_058F63666485-0:0 -> ../../sde
lrwxrwxrwx 1 root root  9 fev 19 11:07 wwn-0x5000000000000000 -> ../../sda
lrwxrwxrwx 1 root root  9 fev 19 11:27 wwn-0x5000c500353451fe -> ../../sdd
lrwxrwxrwx 1 root root 10 fev 19 11:27 wwn-0x5000c500353451fe-part1 -> ../../sdd1
lrwxrwxrwx 1 root root 10 fev 19 11:27 wwn-0x5000c500353451fe-part9 -> ../../sdd9
lrwxrwxrwx 1 root root  9 fev 19 11:07 wwn-0x5000c5003ec2f9c0 -> ../../sdb
lrwxrwxrwx 1 root root 10 fev 19 11:07 wwn-0x5000c5003ec2f9c0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 fev 19 11:07 wwn-0x5000c5003ec2f9c0-part9 -> ../../sdb9

Não que seja a coisa mais compreensível do mundo, mas pelo menos aí você pode usar o serial do disco (que normalmente vem estampado na etiqueta) para identificar qual disco você precisa trocar quando o seu pool der pau, aí fica muito mais simples. No meu caso, rodei: zpool replace dados 16849396304634906415 /dev/disk/by-id/ata-ST32000644NS_9WM5X8TR

e já sei que o disco 9wm5x8tr substitui o anterior que deu pau. Futuramente, pretendo adotar essa prática também para quando for criar um novo pool, ai evito essa incerteza de que, quando eventualmente o disco der pau (e vai dar) eu consigo saber qual devo trocar.

#zfs #debian