<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>recovery &amp;mdash; Sei lá e pans</title>
    <link>https://rberlim.writeas.com/tag:recovery</link>
    <description>O título diz tudo.</description>
    <pubDate>Tue, 12 May 2026 23:13:02 +0000</pubDate>
    <item>
      <title>Recuperando um pool ZFS</title>
      <link>https://rberlim.writeas.com/recuperando-um-pool-zfs?pk_campaign=rss-feed</link>
      <description>&lt;![CDATA[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.&#xA;&#xA;Esperançoso que o pool onde realmente estão os dados estava intacto, comecei a tarefa de tentar recuperar tudo. &#xA;Felizmente, dada situações pregressas, eu tinha pelo menos alguma idéia de quais os discos realmente estavam envolvidos no pool que queria recuperar. &#xA;&#xA;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 &#xA;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&#xA;Após preparar o novo sistema para o zfs e adicionar alguns discos do pool antigo, um simples &#xA;  pool: dados&#xA;     id: 1176411848024315794&#xA;  state: DEGRADED&#xA;status: The pool was last accessed by another system.&#xA; action: The pool can be imported despite missing or damaged devices.  The&#xA;&#x9;fault tolerance of the pool may be compromised if imported.&#xA;   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-EY&#xA; config:&#xA;&#xA;&#x9;dados                          DEGRADED&#xA;&#x9;  raidz1-0                     DEGRADED&#xA;&#x9;    ata-ST32000644NS9WM7LQT3  ONLINE&#xA;&#x9;    ata-ST32000644NS9WM7N07E  UNAVAIL&#xA;&#x9;    wwn-0x5000cca224c5ea5c     ONLINE&#xA;Otimo, o pool estava lá. Com um disco a menos, mas estava lá. A partir daí, um &#xA;agora, para substituição do disco ausente, coloquei o pool offline com &#xA;dessa forma, só bastou fazer um &#xA;Agora é configurar snapshots e backups para não precisar contar com a sorte no próximo incidente :)&#xA;&#xA;zfs&#xA;debian&#xA;recovery]]&gt;</description>
      <content:encoded><![CDATA[<p>Recentemente perdi meu servidor principal de casa. Os discos do pool zroot estavam ruins, e quando fui trocar um, <em>puf</em>, 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.</p>

<p>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.</p>

<p>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 <code>/dev/disk/by-uuid</code> em vez de usar os clássicos <code>/dev/sdX</code> ou coisa assim, que as vezes mudam a qual disco se referem. Pelo menos comigo, aconteceu mais de uma vez.</p>

<p>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 <code>zpool import</code> começou a me encher de esperança</p>

<pre><code>  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
</code></pre>

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

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

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

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

<p><a href="https://rberlim.writeas.com/tag:zfs" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">zfs</span></a>
<a href="https://rberlim.writeas.com/tag:debian" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">debian</span></a>
<a href="https://rberlim.writeas.com/tag:recovery" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">recovery</span></a></p>
]]></content:encoded>
      <guid>https://rberlim.writeas.com/recuperando-um-pool-zfs</guid>
      <pubDate>Sat, 22 Mar 2025 16:43:09 +0000</pubDate>
    </item>
  </channel>
</rss>