search

masc3d / btrfs-sxbackup

Incremental btrfs snapshot backups with push/pull support via SSH
GNU General Public License v2.0
117 stars 20 forks source link

Run a pre- script on remote source? #62

Open basinilya opened 3 years ago

basinilya commented 3 years ago

I want to backup my ext4 /boot partition to a directory on the remote btrfs source when my backup server calls btrfs-sxbackup run. Preferably, use the same SSH connection for the backup as snapshot and transfer operations do.

In one of the previous issues @masc3d wrote:

pre / post local snapshot scripts (post script may not execute if there's a connection problem leaving database locked forever)

I didn't understand this. Do we already support pre/post scripts?

masc3d commented 3 years ago

I didn't understand this. Do we already support pre/post scripts?

no. and it most probably won't be.

PS: except someone makes a good case for it, but I didn't hear any just yet.

MurzNN commented 3 years ago

Good case of pre-post commands is flushing database caches to disk, for example in mysql:

  1. SQL FLUSH TABLES WITH READ LOCK
  2. Do the snapshot
  3. SQL UNLOCK TABLES

We can do this via separate calls before and after btrfs-sxbackup, but with remote ssh connection it will require separate ssh connections and slows down the whole process.

basinilya commented 3 years ago

The rsync tool allows overriding the location of the ssh binary. Maybe we can do the same here. Then our custom ssh can wrap the remote shell command passed to ssh as a command line argument with pre and post commands

пн, 16 авг. 2021 г., 10:19 Alexey Murz Korepov @.***>:

Good case of pre-post commands is flushing database caches to disk, for example in mysql:

  1. SQL FLUSH TABLES WITH READ LOCK
  2. Do the snapshot
  3. SQL UNLOCK TABLES

We can do this via separate calls before and after btrfs-sxbackup, but with remote ssh connection it will require separate ssh connections and slows down the whole process.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/masc3d/btrfs-sxbackup/issues/62#issuecomment-899281863, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANLB653XJVC74TIIEW6ZUDT5C3XDANCNFSM4YD4R4GA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

masc3d commented 3 years ago

Good case of pre-post commands is flushing database caches to disk, for example in mysql:

imho it's not and it's usually bad practice to do so. some databases can be configured to work well with (lvm or btrfs) snapshots and if it cannot, a filesystem snapshot tool is probably not the right tool for the job.

eg for mariadb you don't need flush when using innodb https://serverfault.com/questions/805257/backing-up-a-mysql-database-via-zfs-snapshots

masc3d commented 3 years ago

to elaborate why it's bad to do it remotely, you cannot reliably perform series of commands (lock -> flush -> backup -> unlock) as the connection may terminate in between and your lock may stay in place indefinitely.

if you need such logic, you can use a local script combining btrfs-sxbackup push job with anything else you need. simple and reliable.