delonix backup

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

Backup of ONE resource — container, pod, vm or stack — into a 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.

Not to be confused with system snapshot create, which takes the whole NODE. Here the archive carries the resource record and the DATA of the volumes it uses — not the image nor the rootfs, because a measured rootfs is 435 MB against 1.5 KB of record, and the image is content-addressed and re-downloads. The VM is the exception: its overlay IS its state, so that one travels (the golden base does not). Nothing has to stop: a container (or all members of a pod/stack, together) is held in the cgroup v2 freezer during the snapshot — no process can write while tar reads, and the PID does not change; a VM goes through libvirt's external snapshot, running on a temporary overlay while the real disk is copied, then settling back onto it. The guarantee is crash consistency, exactly what a power cut leaves — a journalled filesystem and any write-ahead-log database recover from it. What it is NOT: memory is not saved, so a process is not resumed mid-flight (that is CRIU) and an app with state only in RAM loses it — --stop and --quiesce are the two ways to ask for more, and each says what it costs. The destination can be a folder or a volume:<name>, which is how the archive lands on a NAS. Being a daemonless engine, backup schedule installs a systemd user timer: --max-for-day N spaces N runs across the day, and --cron translates the crontab expression — refusing what it cannot express rather than approximating. schedule also takes the first archive, now: a schedule whose first run is hours away leaves whoever installed it with no backup and the impression of having one. restore unpacks into a working folder BEFORE touching anything — a truncated archive then costs nothing — and refuses while the resource is running (--force stops it, restores, and starts it again). The <kind> is no longer positional: the archive already records what it carries, and --kind stays for anyone who wants a mismatch to be refused.

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

Usage: delonix backup <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:
  -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

delonix backup create container db

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

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

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

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

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

delonix backup create pod api --dry-run

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

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

delonix backup ls --from /srv/backups

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

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

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

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

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