Use rsync to copy your Ubuntu server data to a remote machine or external drive for reliable, incremental backups that do not depend on cloud provider snapshots. This method gives you full control over what is stored and when it is saved. You can schedule these transfers automatically using cron jobs to ensure your critical files remain safe even if the underlying infrastructure fails unexpectedly.
Why Avoid Provider Snapshots?
While cloud providers offer convenient snapshot features, they often come with significant drawbacks. These snapshots are typically locked into the provider’s ecosystem, making it difficult to restore your data elsewhere if you decide to switch hosts. Additionally, storage costs for snapshots can accumulate quickly, especially if you keep multiple versions. By creating your own backup strategy, you maintain portability and reduce long-term expenses. This approach also allows you to compress data before transmission, saving bandwidth and storage space compared to raw disk images.
Setting Up the Backup Destination
Before running any commands, you need a secure location to store your backups. A remote Linux server is an excellent choice because it keeps your data off-site in case of physical hardware failure at your primary location. First, ensure you have SSH access to this destination server. If you do not already have key-based authentication set up, generate a new SSH key pair on your Ubuntu server using
ssh-keygen. Then, copy the public key to the remote server using
ssh-copy-id user@remote-server-ip. This step eliminates the need for password entry during automated scripts.
If you prefer local storage, you can connect an external USB drive. Mount the drive to a specific directory, such as
/mnt/backup, and ensure it has sufficient permissions for your user account. For network-attached storage (NAS), configure NFS or SMB shares similarly. The goal is to have a consistent mount point or remote path that your backup script can reliably reach every time it runs.
Creating the Backup Script
The core tool for this task is
rsync, which efficiently transfers only changed files. Create a new shell script file, for example,
backup.sh, and add the following content. This script excludes common temporary directories to save space and time.
#!/bin/bash
# Configuration
SOURCE="/home/"
DEST="user@remote-server-ip:/backups/ubuntu-backup"
DATE=$(date +%Y-%m-%d_%H-%M-%S)
# Perform the backup
rsync -avz --delete \
--exclude="tmp" \
--exclude=".cache" \
--exclude="*.log" \
$SOURCE $DEST/$DATE
# Optional: Remove backups older than 30 days
find /backups/ubuntu-backup -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;
Make the script executable by running
chmod +x backup.sh. The
-avz flags ensure archive mode, verbose output, and compression during transfer. The
--delete flag ensures that files removed from the source are also removed from the backup, keeping both locations synchronized. Adjust the
SOURCE variable to include only the directories you actually need, such as
/var/www for web servers or
/etc for configuration files.
Scheduling with Cron
To automate the process, open your crontab editor by typing
crontab -e. Add a line to run your script at a specific interval. For a daily backup at 2 AM, use the following entry:
0 2 * * * /path/to/backup.sh >> /var/log/backup.log 2>&1
This setup logs output to
/var/log/backup.log, allowing you to monitor success or troubleshoot errors later. Regularly check this log file to ensure your backups are completing without issues. If you need more frequent backups, adjust the cron schedule accordingly. Remember that frequent backups require more storage space and bandwidth, so balance frequency with your resources.
For more information on managing your server environment, consider reading our guide on
Rapid Deployment: Clone Ubuntu Server for Remote Access Network Administration, which covers similar administrative tasks.
Verifying Your Backups
A backup is only useful if you can restore from it. Periodically test your backup by downloading a small subset of files from the remote destination or mounting the backup directory locally. Verify that critical configuration files and user data are intact. If you are backing up databases, ensure you stop services or use database-specific dump tools like
mysqldump before running
rsync to prevent corrupted data.
Testing restores should be part of your routine maintenance. Schedule a quarterly review where you attempt to restore a full system image or key directories to a test environment. This practice helps identify potential issues with your backup script or destination storage before an actual disaster occurs.
For related troubleshooting tips, you might find our article on
Munin Plugin Memory: Graph Draws Wrong Total Memory on Ubuntu 24.04.1 KVM Server helpful for monitoring server health alongside your backup strategies.
Frequently Asked Questions
What happens if my internet connection drops during backup?
Rsync is designed to resume interrupted transfers rather than starting over. If the connection drops, simply re-run the script, and it will continue from where it left off, transferring only the missing chunks of data.
Can I back up encrypted files directly?
Yes, rsync handles encrypted files just like any other binary data. However, ensure that the decryption keys are available if you plan to restore them to a different system, as the encryption itself does not protect against loss of access credentials.
How much storage space do I need for incremental backups?
Storage needs depend on how many files change between backups. Using
--delete helps manage space by removing obsolete files, but you should still monitor usage regularly to avoid filling up your backup destination drive.
Is rsync faster than using a provider snapshot?
Rsync is often faster for small changes because it transfers only modified bytes rather than copying entire disk blocks. However, initial full backups may take longer depending on your network speed and the total amount of data being transferred.
Should I exclude swap files from my backup?
Yes, you should always exclude swap files and temporary caches. They contain volatile memory data that is irrelevant after a reboot and can significantly increase backup size and time without providing any restoration value.