delonix backup

Backup de UM recurso — container, pod, vm ou stack — em tar.gz.

Não confundir com o system snapshot create, que leva o NÓ inteiro. Aqui o arquivo leva o registo do recurso e os DADOS dos volumes que ele usa — não a imagem nem o rootfs, porque um rootfs medido são 435 MB contra 1,5 KB de registo, e a imagem é endereçada por conteúdo e volta a descarregar-se. A VM é a excepção: o overlay dela É o estado dela, por isso viaja (a base dourada não). Nada tem de parar: um container (ou todos os membros de um pod/stack, em conjunto) é mantido no freezer do cgroup v2 durante o snapshot — nenhum processo consegue escrever enquanto o tar lê, e o PID não muda; uma VM passa pelo snapshot externo do libvirt, a correr sobre um overlay temporário enquanto o disco real é copiado, e volta a assentar nele a seguir. A garantia é consistência-de-falha, exactamente o que uma falta de energia deixa — um sistema de ficheiros com jornal e qualquer base de dados com write-ahead log recuperam dela. O que NÃO é: a memória não é guardada, logo um processo não é retomado a meio (isso é CRIU) e uma aplicação que só tenha estado em RAM perde-o — --stop e --quiesce são as duas formas de pedir mais, e cada uma diz o que custa. O destino pode ser uma pasta ou um volume:<nome>, que é como o arquivo vai parar a um NAS. Sendo o motor daemonless, o backup schedule instala um temporizador de utilizador do systemd: o --max-for-day N espaça N corridas pelo dia, e o --cron traduz a expressão de crontab — recusando o que não conseguir exprimir em vez de aproximar. O schedule tira também o primeiro arquivo, já: um agendamento cuja primeira corrida é daqui a horas deixa quem o instalou sem backup e com a impressão de ter um. O restore desempacota para uma pasta de trabalho ANTES de tocar em seja o que for — um arquivo truncado custa então zero — e recusa-se enquanto o recurso estiver a correr (--force pára-o, repõe, e volta a arrancá-lo). O <kind> deixou de ser posicional: o arquivo já regista o que leva, e o --kind continua a existir para quem quiser que uma discordância seja recusada.

📄 Implementação real em Rust: cmd/rbackup.rs

Usage: delonix backup [OPTIONS] <COMMAND>

Commands:
  inspect   What an archive holds, without unpacking it
  ls        The archives in a directory
  create    Write an archive of one resource, now
  remove    Delete an archive
  restore   Put a resource back from an archive
  schedule  Keep archiving this resource on a systemd user timer
  help      Print this message or the help of the given subcommand(s)

Options:
      --l18n <en|pt>
          Output language: `en` (default) or `pt` (Portuguese, pt_AO). Also settable via `$DELONIX_L18N`. Global — works before any subcommand

  -h, --help
          Print help (see a summary with '-h')

COMMAND MAP:
  Inspect    ls · inspect
  Configure  create · schedule · restore · remove

EXAMPLES:
  # archive one resource, now
  delonix backup create container db

  # what archives exist
  delonix backup ls --from /srv/backups

  # put one back
  delonix backup restore container-db-20260811-205312.tar.gz

SEE ALSO:
  delonix backup create · delonix backup ls · delonix backup restore · delonix
  system snapshot

  delonix › backup

ExemplosExamples

O registo e os dados dos volumes, aqui mesmo

delonix backup create container db

Para um NAS, através de um volume nomeado

delonix backup create container db --to volume:nas-backups

Uma stack inteira: cada membro e cada volume, o partilhado uma só vez

delonix backup create stack loja --to /srv/backups

Uma VM A CORRER — o convidado não pára e o PID não muda

delonix backup create vm dev --to /srv/backups

Consistência ao nível do filesystem do convidado (precisa do qemu-guest-agent lá dentro)

delonix backup create vm dev --quiesce --to /srv/backups

Parar mesmo, para uma aplicação que só tem estado em RAM

delonix backup create container cache --stop --to /srv/backups

Ver o que entraria, sem escrever nada

delonix backup create pod api --dry-run

Duas vezes por dia, guardando os dois mais recentes

delonix backup schedule container db --max-for-day 2 --to /srv/backups

Ou no horário que quiseres, em sintaxe de crontab

delonix backup schedule stack loja --cron "30 3 * * 1" --to /srv/backups

Que arquivos existem, e o que cada um leva

delonix backup ls --from /srv/backups

O que está dentro de um, sem o desempacotar

delonix backup inspect container-db-20260811-205312.tar.gz --from /srv/backups

Repor os dados (recusa enquanto estiver a correr)

delonix backup restore container-db-20260811-205312.tar.gz

Parar, repor e arrancar de novo

delonix backup restore ./container-db-20260811-205312.tar.gz --force

Afirmar o kind, para que um arquivo trocado seja recusado

delonix backup restore vm-dev-20260811-210109.tar.gz --kind vm

Apagar um arquivo (recusa o que não foi este comando a escrever)

delonix backup remove container-db-20260811-205312.tar.gz --from /srv/backups