I have done a fair bit of this both on Linux using btrfs snapshots and
Windoze using VSS (volume snapshot service).
As Craig mentions, the challenge is that there are many different OS's
and filesystems, each with their own method of creating
snapshots.
Beyond that there are several complications that make it non-trivial
to implement general snapshot functionality in backuppc:
1. The snapshot create/delete needs to run on the remote system with
root privileges -- this requires something like 'ssh' or other
command to run the command on the remote system.
2. The snapshots are typically done at the filesystem level which may
or may not line up with shares -- so you need some type of mapping
to know what and where to snapshot.
3. You need various control and testing to make sure that you don't
run into conflicting snapshots from simultaneously running backups,
that errors in creating or deleting snapshots are detected and
rolled back, etc.
Bottom line, is that if you want to do it generally and robustly
across multiple OS types, filesystems, share configurations, etc., you
would need a pretty complex set of code.
Unless you are signing up to write the code, better to use the hooks
that Craig has provided. And if you look several months back in the
mailing list history, you will see that Craig has been quite
responsive in terms of adding additional hook functionality as needed.
I also have written some relatively but not completely general and
robust code for VSS on Windoze and btrfs on Linux. The advantage of my
code is I do it all with inline perl and bash script code in the
host.pl file on the backuppc server so that no extra scripts are
needed... I have posted some of this in the past in the usegroup so
check the history if you are interested...
Jeff
PGNet Dev wrote at about 16:26:52 -0700 on Friday, October 2, 2020:
> On 10/2/20 3:35 PM, Craig Barratt wrote:
> > Snapshotting is a great idea but it's not built in, since the underlying
> > commands and approaches vary so much between different OSes and
> > filesystems.
>
> noted.
>
> though, LVMs _are_ fairly widespread.
>
> support's available on linux*, of course; and, netbsd & freebsd (though
> dunno the nitpicky-gotcha differences ...)
> iirc, MacOS has (had?) CoreStorage ...
> and M$'s lumbering towards "everything on linux subsystem" ... whatever that
> ends up looking like.
>
>
> fwiw, every one of _many_ pcs 'in my neighborhood' -- local & remote, bare
> metal & containers -- are on LVs.
>
> and, of course, not every one has live(ish) data ... but _many_ do. DIY'ing
> it has always included snapshotting.
> I'm tired of maintaining separate approaches; that's why I'm looking at
> BackupPC!
>
> I'm not clear about what _specific_ variations in "underlying commands &
> approaches" you're referring to,
> I do recognize that with zfs/btrfs/stratis/etc/etc, there's a whole other
> ball of wax.
>
> > Several users have developed scripts that do snapshots, which are
> > especially beneficial on windoze given the prevalence of enforced file
> > locking. It sounds like you have discovered some of those already.
>
> yup.
>
> > Generally the approach is to use $Conf{DumpPreShareCmd} to set up the
> > snapshot, and $Conf{DumpPostShareCmd} to clean up.
>
> yep. for any one share it's reasonably trivial.
>
> I think one should be able to provide an iteration framework across
> backup-types, that wraps specifics provided in configs.
>
>
> For a list of shares -- such as in my "something like" example^^ -- it gets
> more complicated.
>
> rsnapshot's approach, specifying in config
>
> linux_lvm_cmd_lvcreate /usr/sbin/lvcreate
> linux_lvm_cmd_lvremove /usr/sbin/lvremove
> linux_lvm_cmd_mount /usr/bin/mount
> linux_lvm_cmd_umount /usr/bin/umount
> linux_lvm_snapshotsize 100M
> linux_lvm_snapshotname snap_rsnapshot
> linux_lvm_vgpath /dev
> linux_lvm_mountpath /mnt/rsnaphsot/snap
>
> then using form
>
> backup lvm://vg0/home/path2/ lvm-vg0/
> Backs up the LVM logical volume called home, of volume group
> vg0,
> to <snapshot_root>/<interval>.0/lvm-vg0/. Will create, mount,
> backup,
> unmount and remove an LVM snapshot for each lvm:// entry.
>
> e.g.
>
> backup lvm://dev/VG0/LV_DATA1 this.project/LV_DATA1
>
> works quite flexibly/portably.
>
> My 1st inclination is to try to take the 'old' approach, put all my needed
> snapshotting in an external script, and pass the "(current) $share" from
> BackupPC's exec shell to the external script ...
>
> Still messy; hence the chat about some form of integration.
>
> > One recent addition which should be helpful is $Conf{ClientShareName2Path}
> > which allows you to map the share name to the real path (in this case, the
> > snapshot path). There is, however, an open issue that I haven't addressed
> > yet which is that it also is applied during restore, which doesn't seem
> > like the right thing to do.
>
> I don't see that in the release docs; I assume it's in recent/master. (Will
> take a peek here in a bit ...)
>
>
>
>
> _______________________________________________
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: https://github.com/backuppc/backuppc/wiki
> Project: https://backuppc.github.io/backuppc/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/
