Linux VPS Backup: Files, Databases & Snapshots

Updated 7 November 2026 · Standard formula, shown below

This guide walks you through backing up a Linux VPS, covering file-level backups, database dumps, and VPS snapshots. You’ll learn how to create each type of backup, store them safely, and restore them when needed. Before starting, ensure you have SSH access to your VPS with sudo privileges, and know which database system you use (MySQL/MariaDB or PostgreSQL).

What You’ll Need

SSH client (e.g., OpenSSH, PuTTY) and your VPS IP address
Root or sudo user credentials
Database credentials (username/password) for your database system
Enough disk space on your VPS or an external storage location (like another server or object storage)
Optional: a backup tool like rsync or tar (usually pre-installed)

Step-by-Step

Connect to your VPS via SSH. Open a terminal and run ssh user@your-vps-ip. Enter your password or use your SSH key.
Create a backup directory. Run sudo mkdir -p /backup to create a central location for your backups. You can use a different path if you prefer.
Back up your files with tar. To create a compressed archive of your web root and configuration files, run a command like:
sudo tar -czf /backup/files-$(date +%F).tar.gz /var/www /etc/nginx
Replace /var/www and /etc/nginx with the directories you want to back up. The $(date +%F) adds the date to the filename.
Back up your MySQL/MariaDB database. Use mysqldump to create a SQL dump:
sudo mysqldump --all-databases --single-transaction -u root -p > /backup/db-$(date +%F).sql
You’ll be prompted for the MySQL root password. For PostgreSQL, use sudo -u postgres pg_dumpall > /backup/db-$(date +%F).sql.
Compress the database dump. To save space, gzip the SQL file: sudo gzip /backup/db-$(date +%F).sql. This creates a .sql.gz file.
Create a VPS snapshot (if your provider supports it). Log into your VPS provider’s control panel (e.g., DigitalOcean, Linode, AWS). Look for a “Snapshots” or “Backups” section. Click “Take Snapshot”, give it a name, and confirm. This creates a full disk image that can be restored instantly.
Copy backups off-site. Use rsync or scp to copy the backup files to another server or local machine. For example: rsync -avz /backup/ user@backup-server:/backup/. This protects against VPS failure.
Verify your backups. List the backup files with ls -lh /backup to check sizes. For database dumps, you can test by restoring to a temporary database (see Troubleshooting).

Common Mistakes

Not backing up the database before files. Always dump the database first to ensure data consistency, especially if your application writes to both files and DB.
Using mysqldump without --single-transaction on InnoDB tables. This can lock tables and cause downtime. The flag gives a consistent snapshot without locking.
Storing backups only on the same VPS. If the VPS fails, you lose everything. Always copy backups off-site.
Forgetting to exclude unnecessary directories. Backing up /proc, /sys, or /dev with tar can cause errors and waste space. Use --exclude flags.
Not testing restores. A backup that can’t be restored is useless. Test your backups periodically.

Tips

Automate with cron. Create a script that runs the backup commands and schedule it with crontab -e. For example, run daily at 2 AM: 0 2 * * * /path/to/backup-script.sh.
Use incremental backups for files. Instead of full tar archives every time, use rsync with --link-dest to create incremental backups that only store changed files.
Keep multiple snapshots. Most providers allow several snapshots. Keep at least three: one daily, one weekly, and one monthly.
Encrypt sensitive backups. Use gpg to encrypt database dumps before storing off-site: gpg -c /backup/db.sql.gz.
Monitor backup success. Add a line to your script that sends a notification (e.g., email) if the backup fails.

Troubleshooting

Backup file is empty or too small. Check the command output for errors. For mysqldump, ensure you have correct permissions and the database exists. Test by running sudo mysqldump -u root -p database_name and see if it outputs SQL.
Restore fails with “database already exists”. Drop the existing database first: sudo mysql -e "DROP DATABASE database_name;", then restore with sudo mysql -u root -p < /backup/db.sql.
Snapshots not appearing in provider panel. Wait a few minutes; some providers take time to process. If still missing, contact support.
Not enough disk space for backups. Check with df -h. Clean up old backups with sudo rm /backup/*.gz after verifying they are safely stored off-site.
Permission denied when running tar. Use sudo to ensure you can read all directories, or add the user to the appropriate group.

Frequently Asked Questions

How often should I back up my VPS?

At least daily for files and databases, and weekly snapshots. If your data changes frequently, consider hourly backups for critical directories.

What is the difference between a snapshot and a backup?

A snapshot is a full disk image taken by your hosting provider, useful for quick rollback. A backup (like tar or mysqldump) is a file-level copy that you can store anywhere and restore selectively.

Can I restore a single file from a snapshot?

Not directly. Snapshots are disk images. You would need to restore the entire snapshot to a new VPS, then extract the file. For single-file recovery, use your file-level backups.

How do I restore a database from a gzipped dump?

First decompress: gunzip /backup/db.sql.gz, then import: sudo mysql -u root -p < /backup/db.sql. For PostgreSQL, use sudo -u postgres psql < /backup/db.sql.

Should I back up the entire VPS or just specific directories?

It depends. For a standard web server, backing up /var/www, /etc, and the database is usually enough. For system-critical servers, a full snapshot is safer.

How long should I keep backups?

Keep at least 7 daily backups, 4 weekly, and 3 monthly. This gives you a good balance between recovery options and storage costs. Adjust based on your needs.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.