[Guide] Incremental backup using the official backup system revisions

Go back to topic: [Guide] Incremental backup using the official backup system

  1. v7 anchor; v7 full version
  2. v6 anchor; v6 full version
  3. v5 anchor; v5 full version
  4. v4 anchor; v4 full version
  5. v3 anchor; v3 full version
  6. v2 anchor; v2 full version

Revision #7

Edited on
2024-06-15
Edited by user
solene
I'd be happy to receive feedback about it, I didn't try it much yet. I'd be happy to receive feedback about it, I didn't try it much yet. Update: I've been using it for 2 months with success, the backup repository doesn't grow much at each new backup.

Revision #6

Edited on
2024-04-18
Edited by user
solene

Revision #5

Edited on
2024-04-12
Edited by user
solene
python3 -c "import sys; print(b'Please enter passphrase: '.decode(), end='', file=sys.stderr); sys.stderr.flush()" python3 -c "import sys; print(b'Please confirm passphrase: '.decode(), end='', file=sys.stderr); sys.stderr.flush()" printf "Please enter passphrase: " >/dev/stderr printf "Please confirm passphrase: " >/dev/stderr
python3 -c "import sys; print(b'Please enter passphrase: '.decode(), end='', file=sys.stderr); sys.stderr.flush()" fi printf "Please enter passphrase: " >/dev/stderr fi

Revision #4

Edited on
2024-04-12
Edited by user
solene
As stated in the second post of this topic, backups could be tampered with through the qube handling the backup tool. This is quite unlikely if you use packages from a template on a qube that isn't exposed to non trusted binaries, but be sure it fits into your threat model!
# Performance result (restic) Here are some results, I didn't expect it to be so effective :joy: Doing backups of multiple qubes at once slightly reduce deduplication effectiveness, but it still works great. Doing a 20 GB qube backup is fast and end up as a 6 GB backup using restic defaults. Doing the backup again without much changes skips all data already in the repository, this makes the backup process **extremely** fast because restic just skip data until there is something new to save.# Performance I made a benchmark to compare. The protocol was to use the command `qvm-backup --no-compress --yes` with both restic (defaults settings) and borg (compression set to zstd instead of lz4). The default backup was done with scrypt disabled, and was using `--compress`, plain good old qvm-backup. With restic and borg, I did two backups of all my qubes (except the one with the backup) in a row, then I rebooteed and did a new backup, all temporary qubes disks got merged after that, increasing the size. I did not do the qvm-backup multiple times because the size and time would be almost identical to the first run. ``` Type size (bytes / GB) time ---- default backup with compression 94670100 (91GB) 137 minutes restic 76439920 (73GB) 22 minutes restic 2nd backup 77499468 (74GB) 15 minutes restic 3rd backup post reboot 81685884 (78GB) 15 minutes borg 78847352 (76GB) 23 minutes borg 2nd backup 82468580 (79GB) 17 minutes borg 3rd backup post reboot 90346032 (87GB) 19 minutes ```

Revision #3

Edited on
2024-04-12
Edited by user
solene
You can't use backups make prior to this change, you would have to rename `/usr/bin/scrypt.old` back to `/usr/bin/scrypt` to make them work again. You can't use backups made prior to this change, you would have to rename `/usr/bin/scrypt.old` back to `/usr/bin/scrypt` to make them work again.
I verified and dom0 should only use the scrypt command for backups and restore, so it shouldn't break anything :slight_smile:I verified and dom0 should only use the scrypt command for backups and restore, so it shouldn't break anything :slight_smile: # Performance result (restic) Here are some results, I didn't expect it to be so effective :joy: Doing backups of multiple qubes at once slightly reduce deduplication effectiveness, but it still works great. Doing a 20 GB qube backup is fast and end up as a 6 GB backup using restic defaults. Doing the backup again without much changes skips all data already in the repository, this makes the backup process **extremely** fast because restic just skip data until there is something new to save.

Revision #2

Edited on
2024-04-12
Edited by user
solene
You can't use regular backups with it, you would have to rename `/usr/bin/scrypt.old` back to `/usr/bin/scrypt` to make them work again. A dom0 update or upgrade may overwrite scrypt binary.You can't use backups make prior to this change, you would have to rename `/usr/bin/scrypt.old` back to `/usr/bin/scrypt` to make them work again. A dom0 update or upgrade may overwrite scrypt binary. # Misc I verified and dom0 should only use the scrypt command for backups and restore, so it shouldn't break anything :slight_smile: