Fix for snapshot mode backups in ploop.

Fix for snapshot mode backups in ploop. (0 Replies, Read 3378 times)

Jay-P	# October 18, 2016, 9:26 pm
Group: NOC Post Group: Newbie Posts: 7 Status:	I was facing issues creating backups using virtualizor, vzdump would go in backup mode: suspend despite leaving an appropriate amount of free space on the main volume group. After many reinstalls and tests I've solved the problem. Take a look in /var/log/vzdump/ on your hardware node, you will see many files named openvz-<vmid>.log if you see backup mode: suspend then the system is taking containers offline for the backup process. Here's how to fix the issue: 1) Fix the recommended partitions to include. Standard ext3/ext4 /boot Volume Group #1 / <swap> /vz Leave enough free storage for vzdump to use in making live snapshots. Recommended is >5GB but I personally did 17 GB. Volume Group #2 /vz/dump = the largest container's size + 10 GB 2) The version of vzdump shipped by the Softaculous repo has a bug that won't let it use snapshot mode for backups. Only suspend mode is supported which takes the container offline for the duration of the backup. Here's the fix: /usr/share/perl5/PVE/VZDump.pm On line 622, you will find the following: if ($line =~ m\|^\s(\S+):(\S+):(\d+(\.\d+))M$\|) { Replace this with: if ($line =~ m\|^\s(\S+):(\S+):(\d+([\.,]\d+))[mM]$\|) { Save and close the file. 3) The default size for the temporary vzsnap partition is 1024MB, it's likely to cause issues so you need to create /etc/vzdump.conf with the following line: size: 5120 That will tell vzdump to use the full 5 GB of free space left in Volume Group #1 Final recommendation to Virtualizor developers: The virtualizor backup logs will show backups as completed even when there are issues with the backup process. When the temporary vzsnap partition was created for the snapshot process it wasn't large enough. Here's an example: Oct 17 06:51:44 INFO: Starting Backup of VM 611 (openvz) Oct 17 06:51:44 INFO: CTID 611 exist mounted running Oct 17 06:51:44 INFO: status = CTID 611 exist mounted running Oct 17 06:51:44 INFO: backup mode: snapshot Oct 17 06:51:44 INFO: bandwidth limit: 10240 KB/s Oct 17 06:51:44 INFO: creating lvm snapshot of /dev/mapper/vg_server13-LogVol02 ('/dev/vg_server13/vzsnap-server13.gotekky.com-0') Oct 17 06:51:44 INFO: Logical volume "vzsnap-server13.gotekky.com-0" created. Oct 17 06:51:44 INFO: creating archive '/vz/dump/206.tar.gz' Oct 17 07:18:18 INFO: tar: ./root.hdd/root.hdd: File shrank by 22025486336 bytes; padding with zeros Oct 17 07:25:33 INFO: tar: ./etc/vzdump/vps.conf: Warning: Read error at byte 0, while reading 1914 bytes: Input/output error Oct 17 07:25:33 INFO: Total bytes written: 57650718720 (54GiB, 28MiB/s) Oct 17 07:25:37 INFO: archive file size: 7.71GB Oct 17 07:25:37 INFO: umount: /mnt/vzsnap0: not mounted Oct 17 07:25:37 ERROR: command 'umount /mnt/vzsnap0' failed with exit code 1 Oct 17 07:25:38 INFO: Logical volume "vzsnap-server13.gotekky.com-0" successfully removed Oct 17 07:25:38 INFO: Finished Backup of VM 611 (00:33:54) I'm hoping you can make your backup utility aware of that failure, perhaps by monitoring the output for the string "ERROR". Also when there's a failure to backup one container, virtualizor keeps creating backups for the remaining ones even though it plans to delete them all (counter productive and possibly dangerous since an admin has to view the logs to realize it). You could be missing backups for an entire box because a single container failed to backup. I suggest adding proper notification when backups fail (via email) and allowing backups to fail individually without affecting them all. Edited by Jay-P : October 18, 2016, 9:49 pm
IP: --

Users viewing this topic
	1 guests, 0 users.