"Snapshots" e "Copy-on-Write" LVM, e pesquisas no Facebook pouco fiáveis.
Migração para o Substack lenta, mas em curso.
Precisava de fazer algumas actualizações profundas num servidor virtual, mas se corressem mal a recuperação a partir dos backups iria demorar demasiado tempo. O cliente autorizou uma janela de intervenção demasiado curta para isso.
É mais fácil, e rápido, parar o servidor virtual1…
virsh stop srv-37lvcreate --snapshot /dev/vg/lv-srv-37 --size=10g --name=20250507-lv-srv-37-snapshot-before-update… arrancar novamente o servidor…
virsh start srv-37… e actualizá-lo:
[root@srv-37 ~]# yum updateDepois de alguns testes para confirmar a boa operacionalidade da máquina, podemos eliminar o snapshot. Já não me recorda se era com “lvremove" ou "lvconvert --merge”, mas lembro-me que usar a opção errada dá asneira grossa!
E agora?
Acho que tinha publicado algo sobre o assunto há uns anos, deixa procurar no Facebook: pesquisas por “lvm”, “lvremove”, “lvconvert” e “snapshot” nas minhas publicações nada devolvem, eu tenho a CERTEZA que a publicação incluía essas palavras.
Hmm, recordo que a publicação estava ilustrada com o Bart Simpson, deixa vasculhar as minhas fotos: cá está!
Estes nabos da Meta nem um motor de pesquisa decente conseguem fazer. Ou se calhar deixam de indexar publicações mais antigas. E já passei pelo mesmo no LinkedIn, várias vezes. Seja como for, não me servem, logo que possível tenho que terminar a migração das minhas tretas para o Substack.
Portanto, como as actualizações correram bem, queremos simplesmente eliminar o snapshot, antes que encha com mais alterações induzidas pelo funcionamento normal da máquina virtual.
Nem sequer é necessário parar a máquina virtual, devido à tecnologia CoW - Copy-On-Write (qualquer alteração num bloco na máquina virtual despoleta uma cópia da informação original desse bloco para o volume de snapshot):
lvremove /dev/vg/20250507-lv-srv-37-snapshot-before-updateSe as alterações não tivessem corrido bem, e quiséssemos reverter o servidor virtual ao estado em que estava aquando do snapshot, desactivaria a máquina, revertia o LVM, e iniciava-a novamente com:
virsh stop srv-37
lvconvert --merge /dev/vg/20250507-lv-srv-37-snapshot-before-update
virsh start srv-37Feito, ‘bora lá debitar o pacote de suporte do cliente! ;)
Um cluster em alta disponibilidade arranca o servidor virtual novamente, a não ser que seja instruído a não fazê-lo, por exemplo com um: "crm resource stop srv-37; crm resource stop srv-37-drbd”, ou equiparável.
Neste caso, 10GB chegavam bem para as alterações induzidas pela actualização do servidor, e alguns testes finais. Ajustar ao vosso caso, porque se o tamanho do snapshot não chegar para armazenar as alterações, terão problemas. Sérios.
A ocupação do snapshot pode ser consultada com um simples “lvs”.