On 3/31/21 12:50 PM, Nicolas Kovacs wrote:
The problem with using Rsnapshot on the VM's filesystems rather than backing up
the whole VM is the time it takes to restore all the mess.
All the same, backing up the VM filesystem from within the VM is the
best way to back them up using rsnapshot.
rsnapshot's approach of hard links and rsync necessarily means that each
time a file changes, the copy in the backup set consumes the entire file
size if any byte in the origin file has changed. If you're backing up VM
images, you're giving up all of the efficiency that rsnapshot was
designed for.
I'd note that your original message said that you were transferring the
entire VM image. That *shouldn't* be the case. rsync should be
transferring only the changed bits over the network, but on disk you'll
have an entirely new file.
There are a few ways you can work around that with rsnapshot, but I'm
not aware of an easy solution.
One option would be to use btrfs as your backup volume and write wrapper
scripts for cmd_cp and cmd_rm. Rather than the default behavior, you'd
want to create a snapshot (for cmd_cp) and remove snapshots (for cmd_rm).
The other option that comes to mind would be to use either XFS or btrfs
as your backup volume and write a wrapper script for cmd_cp. This would
be simpler, the script would just be:
#!/bin/sh
exec cp --reflink=always "$@"
If you pursued either option, you'd want to modify the rsnapshot
rsync_long_args setting, and add --inplace.
Those two approaches would take advantage of CoW filesystem capabilities
to conserve disk space. If you decide to pursue them, bear in mind that
"du" will report that each of the resulting VM images are full size,
even though that's not really the case. The only way (that I know of)
to accurately measure disk use will be to run "df" before a backup and
after, and compare the disk use of the filesystem.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
