backup of CT's is buggy

mir

Famous Member
Apr 14, 2012
3,568
127
133
Copenhagen, Denmark
Hi,

It seems the current backup functionality of CT's is useless if the CT is running services. I have a CT which only provides owncloud but no matter what I do it is only possible to make a backup of this CT if it is stopped. The situation is that an owncloud provides online synchronization to clients and apps in which case files atime changes frequently which always results in a backup failure. The reason is that the CT is resumed before the final tar.lzo packages is made and in that time frame between resume and the final tar.lzo is completed files can change in the CT. See log below:

INFO: starting new backup job: vzdump 112 --remove 0 --mode snapshot --compress lzo --storage qnap_nfs --node esx1
INFO: Starting Backup of VM 112 (openvz)
INFO: CTID 112 exist mounted running
INFO: status = running
INFO: mode failure - unable to detect lvm volume group
INFO: trying 'suspend' mode instead
INFO: backup mode: suspend
INFO: ionice priority: 7
INFO: starting first sync /mnt/pve/qnap_nfs/private/112/ to /mnt/pve/qnap_nfs/dump/vzdump-openvz-112-2013_02_16-15_38_09.tmp
INFO: Number of files: 36180
INFO: Number of files transferred: 28716
INFO: Total file size: 1411528544 bytes
INFO: Total transferred file size: 1408105673 bytes
INFO: Literal data: 1408105673 bytes
INFO: Matched data: 0 bytes
INFO: File list size: 837530
INFO: File list generation time: 0.146 seconds
INFO: File list transfer time: 0.000 seconds
INFO: Total bytes sent: 1410373332
INFO: Total bytes received: 586768
INFO: sent 1410373332 bytes received 586768 bytes 7037207.48 bytes/sec
INFO: total size is 1411528544 speedup is 1.00
INFO: first sync finished (200 seconds)
INFO: suspend vm
INFO: Setting up checkpoint...
INFO: suspend...
INFO: get context...
INFO: Checkpointing completed successfully
INFO: starting final sync /mnt/pve/qnap_nfs/private/112/ to /mnt/pve/qnap_nfs/dump/vzdump-openvz-112-2013_02_16-15_38_09.tmp
INFO: Number of files: 36182
INFO: Number of files transferred: 3
INFO: Total file size: 1411528885 bytes
INFO: Total transferred file size: 31021 bytes
INFO: Literal data: 921 bytes
INFO: Matched data: 30100 bytes
INFO: File list size: 837602
INFO: File list generation time: 0.037 seconds
INFO: File list transfer time: 0.000 seconds
INFO: Total bytes sent: 841470
INFO: Total bytes received: 2970
INFO: sent 841470 bytes received 2970 bytes 58237.24 bytes/sec
INFO: total size is 1411528885 speedup is 1671.56
INFO: final sync finished (14 seconds)
INFO: resume vm
INFO: Resuming...
INFO: vm is online again after 14 seconds
INFO: creating archive '/mnt/pve/qnap_nfs/dump/vzdump-openvz-112-2013_02_16-15_38_09.tar.lzo'
INFO: tar: ./var/www/apps/files_texteditor/appinfo: file changed as we read it
INFO: Total bytes written: 1434112000 (1.4GiB, 16MiB/s)
ERROR: Backup of VM 112 failed - command '(cd /mnt/pve/qnap_nfs/dump/vzdump-openvz-112-2013_02_16-15_38_09.tmp;find . '(' -regex '^\.$' ')' -o '(' -type 's' -prune ')' -o -print0|sed 's/\\/\\\\/g'|tar cpf - --totals --sparse --numeric-owner --no-recursion --one-file-system --null -T -|lzop) >/mnt/pve/qnap_nfs/dump/vzdump-openvz-112-2013_02_16-15_38_09.tar.dat' failed: exit code 1
INFO: Backup job finished with errors
TASK ERROR: job errors

Does this mean that the only way to make a proper backup of a CT is to stop the services before making the backup?
 
The reason is that the CT is resumed before the final tar.lzo packages is made and in that time frame between resume and the final tar.lzo is completed files can change in the CT.

We sync the whole content to a temporary directory '/mnt/pve/qnap_nfs/dump/vzdump-openvz-112-2013_02_16-15_38_09.tmp' before we resume,and the following tar use those temporary directory.

I am not sure who/what changes those files, but it can't be the container itself.
 
I am very certain the container is responsible for changing the files.

INFO: resume vm
INFO: Resuming...
INFO: vm is online again after 14 seconds
INFO: creating archive '/mnt/pve/qnap_nfs/dump/vzdump-openvz-112-2013_02_16-15_38_09.tar.lzo'
INFO: tar: ./var/www/apps/files_texteditor/appinfo: file changed as we read it
INFO: Total bytes written: 1434112000 (1.4GiB, 16MiB/s)

I you study the above you will notice that the container is resumed before the final tarball is created leaving plenty of room for the container to change files while the final tarball is created.
 

I you study the above you will notice that the container is resumed before the final tarball is created leaving plenty of room for the container to change files while the final tarball is created.

Againm, 'tar' does not use any files from original container!
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!