Updated to version 1.2

Dockerfile

@@ -6,7 +6,7 @@ LABEL container.name="virtnbdbackup-docker"
 LABEL container.source.description="Backup utiliy for Libvirt kvm / qemu with Incremental backup support via NBD"
 LABEL container.description="virtnbdbackup and virtnbdrestore (plus depedencies) to run on hosts with libvirt >= 6.0.0"
 LABEL container.source=$source
-LABEL container.version="1.1"
+LABEL container.version="1.2"
 LABEL maintainer="Adrián Parilli <adrian.parilli@staffwerke.de>"
 
 # Deploys dependencies and pulls sources, installing virtnbdbackup and removing unnecessary content:

README.md

@@ -5,15 +5,19 @@
 ## Overwiew
 Virtnbdbackup-docker is intended for scenarios where isn't viable to provide the necessary environment, such as dependencies or tools, due to system limitations; such as an old OS version, inmutable or embedded rootfs, live distros, docker oriented OSes, etc.
 
-For production usage on servers or hosts without these mentioned limitations, it's much better to deploy directly, via your package manager or directly downloading/installing the latest version of its [source code](https://github.com/abbbi/virtnbdbackup)
+This image was originally made to be used on UnRaid (tested since v6.9.2), but should work equally fine on any other GNN/Linux distro, as much as some [requirements](#requirements) are accomplished.
 
-It was originally made to be used on UnRaid (tested since v6.9.2), but should work equally fine on any other GNN/Linux distro, as much as below requirements can be accomplished.
-
-This image includes 'virtnbdbackup' and 'virtnbdrestore' utils installed along with their required dependecies and other utilities such as latest Qemu Utils and OpenSSH Client in order to leverage all available features.
+It includes 'virtnbdbackup' and 'virtnbdrestore' utils installed along with their required dependecies, and other utilities such as latest Qemu Utils and OpenSSH Client in order to leverage all available features.
 
 Currently, is being built from `debian:bookworm-slim` as base OS.
 
-Refer to the [source code](https://github.com/abbbi/virtnbdbackup) for better understanding, and get familiar with syntax, help and troubleshooting.
+For production usage on 'normal' servers without the above mentioned limitations, is highly recommended to [install the software directly in your OS environment,](https://github.com/abbbi/virtnbdbackup#installation) either via your package manager or downloading the [latest release](https://github.com/abbbi/virtnbdbackup/releases).
+
+Refer to the original [source code](https://github.com/abbbi/virtnbdbackup) for better understanding, get familiar with syntax, help and troubleshooting.
+
+Issues or bugs found with backup/restore tools that aren't related with this docker image environment (as well congratulations for such great work ^_^) must be addressed to the original author, [Michael Ablassmeier](https://github.com/abbbi).
+
+Any other issue and/or pull request made to improve this image, keep it updated, or notify  mistakes or inconsistencies in documentation, will be happily welcomed!
 
 ## Requirements
 - Docker Engine on the host server. See [Docker Documentation](https://docs.docker.com/get-docker/) for further instructions
@@ -30,7 +34,7 @@ Refer to the [source code](https://github.com/abbbi/virtnbdbackup) for better un
   But in some operating systems, `/run` and `/var/run` are still separated folders. Under this scenario you need to bind mount with `-v /var/run:/run`
   And most likely, you will need to mount with either `-v /var/lock:/run/lock` or `-v /var/run/lock:/run/lock` in order to run this container correctly.
 
-  If you're in trouble with this, read source [FAQ](https://github.com/abbbi/virtnbdbackup#faq) and create a [persistent container](###persistent-container) in order to debug, and get the correct bind mounts that work for your main host.
+  If you're in trouble with this, read [Virtnbdbackup's FAQ](https://github.com/abbbi/virtnbdbackup#faq) and create a [persistent container](#persistent-container) in order to debug, and get the correct bind mounts that work for your main host.
 
 - 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`
 
@@ -40,84 +44,69 @@ Refer to the [source code](https://github.com/abbbi/virtnbdbackup) for better un
 
 ### Full Backup
 
-
-`docker run --rm \`
-
-`-v /run:/run -v /var/tmp:/var/tmp -v /mnt/backups:/mnt/backups \`
-
-`adrianparilli/virtnbdbackup-docker \`
-
-`virtnbdbackup -d <domain-name> -l full -o /mnt/backups/<domain-name>`
-
-
+```
+docker run --rm \
+-v /run:/run -v /var/tmp:/var/tmp -v /mnt/backups:/mnt/backups \
+adrianparilli/virtnbdbackup-docker \
+virtnbdbackup -d <domain-name> -l full -o /mnt/backups/<domain-name>
+```
 ### Incremental Backup
 
-
-`docker run --rm \`
-
-`-v /run:/run -v /var/tmp:/var/tmp -v /mnt/backups:/mnt/backups \`
-
-`adrianparilli/virtnbdbackup-docker \`
-
-`virtnbdbackup -d <domain-name> -l inc -o /mnt/backups/<domain-name>`
-
+```
+docker run --rm \
+-v /run:/run -v /var/tmp:/var/tmp -v /mnt/backups:/mnt/backups \
+adrianparilli/virtnbdbackup-docker \
+virtnbdbackup -d <domain-name> -l inc -o /mnt/backups/<domain-name>
+```
 
 ### Backup Restoration
 
-
-`docker run --rm \`
-
-`-v /run:/run -v /var/tmp:/var/tmp -v /mnt/backups:/mnt/backups -v /mnt/restored:/mnt/restored -v /etc/libvirt/qemu/nvram:/etc/libvirt/qemu/nvram \`
-
-`adrianparilli/virtnbdbackup-docker \`
-
-`virtnbdrestore -i /mnt/backups/<domain-backup> -a restore -o /mnt/restored`
-
+```
+docker run --rm \`
+-v /run:/run -v /var/tmp:/var/tmp -v /mnt/backups:/mnt/backups \
+-v /mnt/restored:/mnt/restored -v /etc/libvirt/qemu/nvram:/etc/libvirt/qemu/nvram \
+adrianparilli/virtnbdbackup-docker \
+virtnbdrestore -i /mnt/backups/<domain-backup> -a restore -o /mnt/restored
+```
 
 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.
 
-Mount point `/etc/libvirt/qemu/nvram` is required when involved backup includes NVRAM disks (e.g. UEFI Operating Systems), since virtnbdresore will attempt to restore it to its original location.
+Mount point `/etc/libvirt/qemu/nvram` is required when involved backup includes NVRAM disks (e.g. UEFI Operating Systems, as Wndows 10+), since the command will attempt to restore it to its original location.
 
 ### Interactive mode / debugging virtnbdbackup
 
 You can also run the container in interactive mode by running its build in shell, and then execute multiple backup/restoration commands, as needed. This also very is useful for debugging purposes:
 
-
-`docker run -rm -it \`
-
-`-v /var/tmp:/var/tmp -v /run:/run -v /mnt/backups:/mnt/backups -v /mnt/restored:/mnt/restored' \`
-
-`adrianparilli/virtnbdbackup-docker \`
-
-`/bin/bash`
-
+```
+docker run -rm -it \
+-v /var/tmp:/var/tmp -v /run:/run -v /mnt/backups:/mnt/backups -v /mnt/restored:/mnt/restored \
+adrianparilli/virtnbdbackup-docker \
+/bin/bash
+```
 
 and execute commands as desired. The container will keep running until you type `exit` on the internal shell.
 
 ### Persistent container
 In the 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. In addition, you can set a persistent container with all necessary bind mounts with:
 
-
-`docker create --name <container-name> \`
-
-`-v /var/tmp:/var/tmp -v /run:/run -v /mnt/backups:/mnt/backups -v /mnt/restored:/mnt/restored' \`
-
-`adrianparilli/virtnbdbackup-docker \`
-
-`/bin/bash`
-
+```
+docker create --name <container-name> \
+-v /var/tmp:/var/tmp -v /run:/run -v /mnt/backups:/mnt/backups -v /mnt/restored:/mnt/restored' \
+adrianparilli/virtnbdbackup-docker \
+/bin/bash
+```
 
 Just creating a new container (with custom name) with mount points set and ready to run in interactive mode. To start it and automatically enter into the internal shell, just type:
 
-
-`docker start -i <container-name>`
-
+```
+docker start -i <container-name>
+```
 
 And again, stopping it with the command `exit` from its shell.
 
 ## Quick Notes for SysAdmins
 
-- When libvirt <= 7.6.0, modifications on VM's XML files to enable incremental backup capability can be made while domains are running, but requires to restart such domains for changes take effect.
+- When libvirt <= 7.6.0, modifications on VM's XML files to enable incremental backup capability can be made while domains are running, but requires to restart such domains for changes to take effect.
 - Only a 'full' backup chain operation requires to start the domain in advance. All other operations (copy, diff, inc) doesn't need the domain running.
 - Both 'full and 'inc' checkpoints created while domain is running are stored in memory, but only saved to qcow images as bitmaps when domain is shut down. Under OS or libvirt failing scenarios (e.g. power drops, system crashes, etc.) non-saved checkpoints are lost, resulting into broken backup chains that can't receive more incremental checkpoints. This is due to Qemus Bitmap Persistence's way of working and more details can be found [here.](https://qemu-project.gitlab.io/qemu/interop/bitmaps.html#id17) Involved backups can be normally restored, though.
 - Restoration task is independent of domain's state, but actual domain restoring has to be done by hand, by:
@@ -125,6 +114,3 @@ And again, stopping it with the command `exit` from its shell.
   - Renaming / replacing image files on its final location
   - Starting the domain
   Files as persistent NVRAMs are automatically restored
-- Ensure to read and understand documentation regarding virtnbdbackup completely
-
-Any pull request to improve this work is more than welcome!