Hey everyone! I'm looking for some reliable methods to back up a live database directory from my local disk to a Ceph cluster. Unfortunately, we don't have the database running on the Ceph cluster currently due to network issues. I've tried mounting the Ceph volume and using `rsync` to copy files over, but I've run into a problem: `rsync` often fails because the files are being modified during the transfer. I'm considering two workarounds: using filesystem snapshots or making a local copy before syncing. Has anyone tried something similar, or do you have better suggestions for backing up in this scenario?
6 Answers
If you can't use any backup tool that handles the database, snapshots might be your best bet for a consistent backup. It’s surprising if your database lacks means to generate a consistent backup. But honestly, always aim to use your database's native backup methods when possible!
You're spot on about avoiding `rsync` on live database files! A snapshot-based approach is definitely the way to go. Here’s how it looks: snapshot your `/data`, mount that snapshot, and then use `rsync` to copy it to Ceph. Don't forget to delete the snapshot afterward! If snapshots aren't an option, your `data-temp` method is a fallback, just know it uses more space and I/O. Also, check out tools like **BorgBackup** or **Restic** for incremental backups, as well as native DB dump tools like `pg_dump` or `mysqldump`. They're quite handy!
You really shouldn't rely solely on `rsync` for backing up database files, as you won't get a functional restore from that. It'd be safer to stick with the database's native tools like `pg_dump` or `mysqldump` and backup those output files using `rsync`. Better safe than sorry!
When backing up databases, it's usually best to utilize the built-in database commands like `mysqldump` or `mongodump` for the task. These commands ensure you're getting a usable file. If you really want to copy the files directly, remember to stop the database service first to avoid issues.
I think the filesystem snapshot option is promising, especially since you'll be doing this multiple times. Each time, the diffs should be smaller. Just make sure to conduct a final shutdown of the database before you perform that last `rsync` for best results. It’s worth testing before you commit!
What do you typically use for other backups? Can’t those methods help with SQL-aware backups? Every SQL server generally offers tools to create dumps or backup files, so the simplest route would be to create an SQL dump and then copy that dump file over.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures