Re: [BackupPC-users] rsync + lvm snapshot in BackupPC v4+? integrated, or DIY via 'DumpPreUserCmd' ?
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. 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. Generally the approach is to use $Conf{DumpPreShareCmd} to set up the snapshot, and $Conf{DumpPostShareCmd} to clean up. 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. Craig On Fri, Oct 2, 2020 at 3:04 PM PGNet Dev wrote: > Within the scope of a single backup I've a mix of live data sources. > > For a live data source, e.g. /src/data1, that resides on a dedicated LV, > > mount | grep vmail > /dev/mapper/VG0-LV_DATA1 on /src/data1 type ext4 > (rw,relatime,dax=never) > > I'd like to snapshot the volume prior to backup of the entire volume with > BackupPC > > Reading online, I've found some old efforts -- script based -- on the ML, > etc. afaict, they've not been carried over to v4 (yet? at all?). > > With v4, I see in config.pl _mention_ of snapshot > > Optional commands to run before and after dumps and restores, > and also before and after each share of a dump. > ... > One example of using these commands would be to > shut down and restart a database server, dump a database > to files for backup, or doing a snapshot of a share prior > to a backup. > > in reference to (e.g.), > > $Conf{DumpPreUserCmd} = '$sshPath -q -x -l root $host > /usr/bin/dumpMysql'; > > What level of LV snapshotting integration exists with v4, or planned work? > > Is there any? > > Or, does the `lvcreate -s (snapshot) ... etc etc` need to be externally > managed, and passed completely as an argument to $Conf{DumpPreUserCmd} ? > > To my per-PC config, > > /etc/BackupPC/pc/localhost.pl > > I've added > > $Conf{RsyncArgsExtra} = [ '--one-file-system', ]; > > as well as (initially) a list of shares' LV mount points, e.g. > > $Conf{RsyncShareName} = [ > '/src/data1', > '/src/data2', > ... > '/src/dataN', > ]; > > If snapshot 'integration' is limited, and I have to manage each target > share's snapshotting separately ... > ... it's certainly DO-able, but messy. > > Ideally, I'd _like_ to -- similar to rsnapshot's approach -- specify a > per-share target type, differentiating between 'filesystem direct' and > 'snapshot'. Something like, > > $Conf{RsyncShareName} = [ > 'lvm://dev/VG0/LV_DATA1, bkup_root:/, > mount_name:src/data1', > 'lvm://dev/VG0/LV_DATA2, root:/some/path, > mount_name:src/data2', > ... > 'lvm://dev/VG0/LV_DATAN, mountpt:src/dataN', > '/usr/local/some/path1', > '/usr/local/some/path2', > ]; > > wherein for 'lvm://' > > - a snapshot (e.g., 'snap-LV_DATA1') is created in the parent VG, > /dev/VG0 > - BackupPC mounts /dev/VG0/snap-LV_DATA1 to > /config'd/tmp-mount/path/BackupPC-snap > - BackupPC rsyncs /config'd/tmp-mount/path/BackupPC-snap/ -> > $TOPDIR/'mount_name'/ > - on ok backup, snapshot's destroyed > - next share ... > > So, is this currently doable/planned in BackupPCv4+? > > If it's there, I've missed it. > > If it's not, it'd be quite useful to have in a well-thoughtout, integrated > feature -- rather than YA-DIY script. > > > > ___ > 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/
Re: [BackupPC-users] rsync + lvm snapshot in BackupPC v4+? integrated, or DIY via 'DumpPreUserCmd' ?
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 /.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/
Re: [BackupPC-users] rsync + lvm snapshot in BackupPC v4+? integrated, or DIY via 'DumpPreUserCmd' ?
On 10/2/20 4:26 PM, PGNet Dev wrote: > I don't see that in the release docs; I assume it's in recent/master. (Will > take a peek here in a bit ...) well, if I'd look at the *current* release docs, THAT might help ... ___ 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/
Re: [BackupPC-users] rsync + lvm snapshot in BackupPC v4+? integrated, or DIY via 'DumpPreUserCmd' ?
Craig, digging around a bit, it appears, $Conf{DumpPreUserCmd} $Conf{DumpPostUserCmd} $Conf{DumpPreShareCmd} $Conf{DumpPostShareCmd} are declared as single value string types, ./lib/BackupPC/Config/Meta.pm DumpPreUserCmd => {type => "string", undefIfEmpty => 1}, DumpPostUserCmd=> {type => "string", undefIfEmpty => 1}, DumpPreShareCmd=> {type => "string", undefIfEmpty => 1}, DumpPostShareCmd => {type => "string", undefIfEmpty => 1}, whereas RsyncShareName => { type => "list" & ClientShareName2Path => { type => "hash" if DumpPreShareCmd DumpPostShareCmd were, instead, similarly hash types, with key: (RsyncShareName) value: 'cmd string' then, if 'cmd string' would exec for current $share, if def'd, otherwise a default value (e.g., DumpPreShareCmdDefault) and, all of (current)$share matching ClientShareName2Path value (if any) matching 'cmd string' (if any) were available and could be cleanly passed 'out' to an external script, in 'cmd string', that might provide a convenient approach the "treat each share differently" framework. i.e., each share could have BOTH a unique share->path map, AND a unique Pre/PostShare cmd. thoughts? ___ 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/
Re: [BackupPC-users] rsync + lvm snapshot in BackupPC v4+? integrated, or DIY via 'DumpPreUserCmd' ?
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 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 /.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/
Re: [BackupPC-users] rsync + lvm snapshot in BackupPC v4+? integrated, or DIY via 'DumpPreUserCmd' ?
Sure, there are a lot of ways to do it. The various Dump{Pre|Post}ShareCmds can take arguments that are passed to whatever the first argument specifies as the command. While it doesn't execute it with a shell (to avoid various security issues), it does allow arguments (simple breaking at white space) and also does substitution of various dump-specific parameters (eg, $host, $share etc). However, I don't think there's a variable replacement for the share->path map for that share, although it would be easy to add. Craig On Fri, Oct 2, 2020 at 6:00 PM PGNet Dev wrote: > Craig, > > digging around a bit, > > it appears, > > $Conf{DumpPreUserCmd} > $Conf{DumpPostUserCmd} > $Conf{DumpPreShareCmd} > $Conf{DumpPostShareCmd} > > are declared as single value string types, > > ./lib/BackupPC/Config/Meta.pm > > DumpPreUserCmd => {type => "string", undefIfEmpty => > 1}, > DumpPostUserCmd=> {type => "string", undefIfEmpty => > 1}, > DumpPreShareCmd=> {type => "string", undefIfEmpty => > 1}, > DumpPostShareCmd => {type => "string", undefIfEmpty => > 1}, > > whereas > > RsyncShareName => { > type => "list" > > > & > > ClientShareName2Path => { > type => "hash" > > > if > > DumpPreShareCmd > DumpPostShareCmd > > were, instead, similarly hash types, with > > key: (RsyncShareName) > value: 'cmd string' > > then, if 'cmd string' would exec for current $share, if def'd, otherwise a > default value (e.g., DumpPreShareCmdDefault) > > and, all of > > (current)$share > matching ClientShareName2Path value (if any) > matching 'cmd string' (if any) > > were available and could be cleanly passed 'out' to an external script, in > 'cmd string', > > that might provide a convenient approach the "treat each share > differently" framework. > > i.e., each share could have BOTH a unique share->path map, AND a unique > Pre/PostShare cmd. > > thoughts? > ___ 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/
Re: [BackupPC-users] rsync + lvm snapshot in BackupPC v4+? integrated, or DIY via 'DumpPreUserCmd' ?
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 /.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
Re: [BackupPC-users] rsync + lvm snapshot in BackupPC v4+? integrated, or DIY via 'DumpPreUserCmd' ?
Craig Barratt via BackupPC-users wrote at about 15:35:38 -0700 on Friday, October 2, 2020: > 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. > > Craig Craig, I have found that the native backuppc restore code (whether CLI or web) is somewhat limited in terms of flexibility -- in addition, to the concern you mention above, I also had difficulties in restoring the shares to an arbitrary offset path... I ended up running my own "klugey" shell command when testing my code of form: (NUM=1; BASE=/tmp/restore_point; SHARE=root; RESTORE=${SHARE%/}; RESTORE=${RESTORE##*/}-${NUM}; HOST=testmachine; FILESFROM=;MERGE="${NUM}/3/4"; LOG=1; sudo ${RSYNCBPC:-/usr/bin/rsync_bpc} --bpc-top-dir /var/lib/backuppc --bpc-host-name $HOST --bpc-share-name $SHARE --bpc-bkup-num $NUM --bpc-bkup-comp 3 --bpc-bkup-merge $MERGE --bpc-attrib-new --bpc-log-level $LOG -e /usr/bin/sudo\ -h --rsync-path=/usr/bin/rsync --recursive --super --protect-args --numeric-ids --perms --owner --group -D --times --links --hard-links --delete --partial --log-format=log:\ %o\ %i\ %B\ %8U,%8G\ %9l\ %f%L --stats --acls --xattrs ${FILESFROM:+--files-from=$FILESFROM} / localhost:${BASE}/${RESTORE} >| ${BASE}/${RESTORE}.restore 2>&1) It would be great if there were at least a restore CLI command that would allow more flexibility in terms of where the share is restored... ___ 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/
Re: [BackupPC-users] rsync + lvm snapshot in BackupPC v4+? integrated, or DIY via 'DumpPreUserCmd' ?
On 10/4/20 4:41 PM, backu...@kosowsky.org wrote: > better to use the hooks that Craig has provided sure. here's my initial take -- seems to be working well enough. so far. still testing ... for a localhost test with 2 'live data' source types that I want to 'snapshot' appropriately before backing up, (1) an LVM with fast-flux fs data lvs LVVG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert ... LV_DATA1 VG0 -wi-ao 30.00g ... & (2) a live sqlite3 db ls -al /srv/db/sqlite/app1.db -rw-r--r-- 1 wwwrun www 528K Oct 4 11:00 /srv/db/sqlite/app1.db with a localhost config /usr/local/etc/backuppc/pc/localhost.pl that includes $Conf{SshPath} = '/usr/bin/ssh'; $Conf{RsyncClientPath} = 'sudo /usr/bin/rsync'; $Conf{RsyncSshArgs} = [ '-e', '$sshPath -l root -i /srv/sec/ssh.backuppc.ed25519', ]; $Conf{RsyncArgsExtra} = [ '--acls', '--xattrs', ]; $Conf{RsyncRestoreArgsExtra} = [ '--acls', '--xattrs', ]; $Conf{RsyncShareName} = [ '/data/data1', '/srv/db/sqlite', ]; $Conf{ClientShareName2Path} = { '/data/data1' => '/mnt/BackupPC/snap_data1', '/srv/db/sqlite' => '/srv/db/sqlite-snap', }; $Conf{DumpPreUserCmd} = '$sshPath -q -x -l root $host -i /srv/sec/ssh.backuppc.ed25519 /usr/local/etc/backuppc/scripts/pre-localhost.sh'; $Conf{DumpPostUserCmd} = '$sshPath -q -x -l root $host -i /srv/sec/ssh.backuppc.ed25519 /usr/local/etc/backuppc/scripts/post-localhost.sh'; and pre-/post- user scripts, /usr/local/etc/backuppc/scripts/pre-localhost.sh #!/usr/bin/bash SQLITE3="/usr/bin/sqlite3" BPCMNT="/mnt/BackupPC" LV_SNAP_SZ="2G" mk-sqlite3-snap () { _dbDIR=$1 _dbFILE=$2 _uidgid=$3 _dbSNAPDIR="${_dbDIR}-snap" if [[ -d ${_dbSNAPDIR} ]] then rm -rf ${_dbSNAPDIR} fi mkdir -p ${_dbSNAPDIR} ${SQLITE3} ${_dbDIR}/${_dbFILE} "vacuum into '${_dbSNAPDIR}/${_dbFILE}';" chown -R ${_uidgid} ${_dbSNAPDIR} } mk-lvm-snap () { _VG=$1 _LV=$2 _snapLV=$3 if [[ $(findmnt -m /dev/${_VG}/${_snapLV}) ]] then umount --force --quiet ${BPCMNT}/${_snapLV} lvremove --force --quiet /dev/${_VG}/${_snapLV} fi lvcreate -s -L${LV_SNAP_SZ} -n ${_snapLV} /dev/${_VG}/${_LV} if [[ -d ${BPCMNT}/${_snapLV} ]] then rm -rf ${BPCMNT}/${_snapLV} fi mkdir -p ${BPCMNT}/${_snapLV} mount /dev/${_VG}/${_snapLV} ${BPCMNT}/${_snapLV} } mk-sqlite3-snap "/srv/db/sqlite" "app1.db" "wwwrun:www" mk-lvm-snap "VG0" "LV_DATA1" "snap_data1" exit 0 & /usr/local/etc/backuppc/scripts/post-localhost.sh #!/usr/bin/bash BPCMNT="/mnt/BackupPC" rm-sqlite3-snap () { _dbDIR=$1 # unused: $2 # unused: $3 _dbSNAPDIR="${_dbDIR}-snap" if [[ -d ${_dbSNAPDIR} ]] then rm -rf ${_dbSNAPDIR} fi } rm-lvm-snap () { _VG=$1 _LV=$2 _snapLV=$3 if [[ $(findmnt -m /dev/${_VG}/${_snapLV}) ]] then umount --force --quiet ${BPCMNT}/${_snapLV} lvremove --force --quiet /dev/${_VG}/${_snapLV} fi rm -rf ${BPCMNT}/${_snapLV} } rm-sqlite3-snap "/srv/db/sqlite" "app1" "wwwrun:www" rm-lvm-snap "VG0" "LV_DATA1" "snap_data1" exit 0 BackupPC exec correctly 'snaps' the LV & db as needed. As you mentioned, ssh (and getting the keys/perms right!) makes life a lot easier -- and, makes ma