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
