Sure, setting aside windoze, LVMs are widespread and consistent today, but
BackupPC has been around for quite a while. So my comment was probably
more historical.
Craig
On Fri, Oct 2, 2020 at 4:27 PM PGNet Dev <pgnet....@gmail.com> wrote:
> 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/
