*"Backup utility for libvirt, using the latest changed block tracking features. Create thin provisioned full and incremental backups of your kvm/qemu virtual machines."*
Virtnbdbackup-docker is intended for scenarios where isn't viable for SysAdmins to provide a up-to-date dependencies (stable distros); or when this is totally impossible due to system constraints (inmutable / embedded rootfs, docker oriented OSes, etc.)
This image includes 'virtnbdbackup' and 'virtnbdrestore' utils installed along with required dependecies, and currently is being built from `debian:bullseye-slim` as base.
- To have performed the punctual modifications on VM's XML file and image format, as pointed at [source code's README](https://github.com/abbbi/virtnbdbackup), so this tool will work for you.
In basically all mainstream distros of today (Debian, RedHat, Archlinux and the countless distros based on these) as in this image, `/var/run` is a symlink to `/run` and `/var/lock` a symlink to `run/lock`.
For the vast majority of scenarios the correct bind mount is: `-v /run:/run`
If you're in trouble with this, *read source FAQ* and create a persistent contiainer as described below in order to debug the behaviour from inside, and get the correct bind mounts that work for your main host (And feel free to contribute by sharing your experience / commit about such distros.)
- Virtnbdbackup and virtnbdrestore create sockets for backup/restoration jobs tasks at /var/tmp. Ensure to always add a bind mount with `-v /var/tmp:/var/tmp`
- Finally, to warrant clearness with all input commands, it's convenient to use same backup (and restoration) bind mounts at both endpoints, such as `-v /mnt/backups:/mnt/backups` in order to parse commands in same way as you were running it natively on your main host.
Where `/mnt/restored` is an example folder in your system, where virtnbdrestore will rebuild virtual disk(s) based on existing backups, with its internal block device name, such as 'sda', 'vda', 'hdc', etc.
In above examples, the container will be removed as soon the invoked command has been executed. This is the optimal behaviour when you intend to automatize operations (such as incremental backups.)
And attach to its Shell with: `docker start -i <container-name>` to perform manual backups/restorations, or for debugging purposes. Exiting the Shell will stop it immediately.