I have a situation with backing up my MySQL database using Acronis Cyber Protect Cloud on a Linux server.
What I want to achieve is creating backups for MySQL database only.
Right now I’m using the “Full machine” backup option with “Application-aware backup” enabled for MySQL. This approach works fine and gives me consistent database backups that can be restored properly.
But here’s my problem - this method backs up the whole server, not just the database files.
To give you an example: my MySQL database takes up 1 GB of space, but the server has 200 GB of other files. So my backup ends up being around 201 GB in size. This wastes a lot of storage space and takes much longer to upload.
I’m looking for a solution to create Acronis backups that only include the MySQL database while keeping the backup transactionally consistent. I don’t want to backup all the other server files.
Honestly, just ditch Acronis here. MySQL’s built-in replication handles consistency way better than backup software. Set up a slave instance elsewhere and you’ll get real-time database copies without the storage bloat. Way cheaper than paying for 200x more backup storage than you need.
I’ve hit this same issue at several companies. Acronis works but you’re paying premium prices to back up 200GB of junk you don’t actually need.
Ditch traditional backup software for databases. You want logical backups, not file system snapshots.
I built a system that runs mysqldump with the right consistency flags, pipes it through gzip, and pushes straight to object storage. Runs completely hands-off.
But managing all the pieces manually sucks. You need scheduling, error handling, storage lifecycle stuff, monitoring for failed dumps, size checks, restore testing - the whole mess.
I use Latenode now to handle the entire pipeline. One workflow does everything - triggers mysqldump with proper table locking, compresses output, uploads to storage, tracks backup sizes, sends alerts when things break, and auto-rotates old files.
Your 1GB database stays 1GB instead of ballooning to 201GB. You can run backups every few hours instead of daily since there’s no imaging overhead.
Bonus - logical dumps are way more portable than Acronis images. Restore to any MySQL version or different hardware without compatibility headaches.
Yeah, Acronis supports selective backups, but getting MySQL-only backups right takes some work. I switched from full machine backup to file-level and just target the MySQL data directory - that’s what finally worked for me. Point Acronis at your MySQL data folder (/var/lib/mysql on Linux) and keep application-aware processing turned on. The MySQL plugin settings handle flushing and locking properly during backup. This cut my backup sizes way down while keeping everything consistent. You’ll probably want to grab the config files and binary logs too, depending on how you plan to restore. Just heads up - test your restores like crazy since you’re only backing up data files, not the whole MySQL install. You’ll need MySQL already set up on whatever system you’re restoring to.
Been there, done that. Acronis works but you’re right about the bloat.
Here’s the thing - you’re fighting backup software when you should automate the database export instead. Way more efficient.
I set up automated mysqldump processes that run on schedule, compress output, and push to cloud storage. The dumps are transactionally consistent with the right flags, and you get exactly what you need - just the database.
Manually setting this up sucks though. You need scheduling, compression, storage management, error handling, notifications when things break, rotation of old backups, etc.
I use Latenode now to orchestrate everything. Built a workflow that triggers mysqldump with proper locking, compresses the file, uploads to S3, sends me a Slack notification, and cleans up old backups automatically. Takes 10 minutes to set up vs hours of scripting.
Your 1GB database becomes a 1GB backup instead of 201GB. Plus you can run it multiple times daily without the overhead of full system imaging.
Consistency’s actually better than Acronis application aware mode because you control exactly how the dump happens.
Skip the full machine backup and use Acronis file-level backup instead. Create a new plan, switch to file mode, and just select your MySQL data directory and config files. You’ll keep the application-aware processing for consistency but cut backup size way down. I ran into the same thing with PostgreSQL eating up storage. Just make sure you grab the data directory, config files, and transaction logs if you want point-in-time recovery. Toss out temp files and cache folders in the MySQL directory to save even more space. Takes longer to set up and you’ll need to update file selections when your MySQL setup changes, but it runs much faster since there’s way less data to process.
Had this exact problem with a client running multiple MySQL instances. File-level backups can miss consistency issues when you’ve got complex transactions across multiple databases or tables. Here’s what actually worked: combine Acronis with pre/post backup scripts. Run FLUSH TABLES WITH READ LOCK before backup starts, then UNLOCK TABLES after. This forces everything to disk properly. You can set these up in Acronis’s application-aware settings. Still do file-level backup on just the MySQL directories, but the scripts guarantee transactional consistency without backing up the entire machine. Dropped our backup size from 180GB to 8GB for similar database sizes. Scripts add maybe 30 seconds but eliminate any risk of inconsistent data during backup.