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/
