Keeping Your Linux Servers Safe: A Practical Guide to Online Backups

It's a bit like having a safety net, isn't it? That feeling of knowing your digital life, or in this case, your crucial server data, is protected. For anyone managing Linux systems, setting up a robust online backup strategy isn't just good practice; it's essential. Let's dive into how we can build a reliable system, drawing from some practical insights.

Imagine you have a couple of servers humming along – maybe a web server (let's call it web01) and a storage server (nfs01). You also need a dedicated backup server, backup, to receive all this precious data. The goal is simple: every night, at precisely midnight, we want to capture vital system files, website content, and logs from web01 and nfs01, and send them securely to backup.

The Core Requirements: What We're Protecting

First off, consistency is key. Every server should have its backup directory neatly organized under /backup. Now, what exactly needs safeguarding?

• System Configuration: Think about the heart of your system. This includes things like scheduled tasks (/var/spool/cron/root), startup scripts (/etc/rc.local), and any custom scripts you've put in /server/scripts. For firewalls, the configuration file (/etc/sysconfig/iptables) is a must-have. And of course, always consider what else is unique to your setup – what custom configurations or settings are critical?
• Web Server Specifics: For web01, we're talking about the actual website files, typically found in /var/html/www, and the access logs, often residing in /app/logs.

Retention Policies: How Long Do We Keep Things?

This is where it gets interesting. On the web01 server itself, we don't want to hoard too much. Keeping 7 days of compressed backups locally is usually a good balance to prevent disk space issues. But on the backup server, we can afford to be more generous. The plan is to keep every Monday's backup for a full six months, while other days' backups are kept for the same duration. After six months, only the Monday backups remain, with everything else being purged. This ensures we have a good historical record without overwhelming storage.

The Mechanics: Getting the Data There

So, how do we actually do this? It starts on the client servers (web01 and nfs01).

1. Preparation: Create the necessary directories: /backup, /server/scripts, and even a placeholder for the firewall config if it doesn't exist. For web01, ensure /var/html/www and /app/logs are ready.

2. Compression is Key: We'll use tar to bundle up the files. A common pitfall is just archiving the files directly. It's crucial to use the -h flag with tar to ensure that symbolic links are followed and the actual content they point to is archived, not just the link itself. Also, to keep things clean and avoid leading slashes in the archive names, it's best to cd to the root directory (/) before running the tar command. For example, tar -zchf /backup/system_backup.tar.gz ./var/spool/cron/root ./etc/rc.local ./server/scripts/ ./etc/sysconfig/iptables. For web content and logs, we'll compress them separately: tar -zchf /backup/www_backup.tar.gz ./var/html/www and tar -zchf /backup/www_log_backup.tar.gz ./app/logs.

3. Adding Dates and Cleaning Up: To manage retention, we need to include the date in the backup filenames. So, instead of system_backup.tar.gz, we'll use something like system_backup_$(date +%F).tar.gz. To remove old backups, we can use find /backup/ -type f -mtime 7 | xargs rm. This command finds files older than 7 days and deletes them.

4. The Transfer: Rsync to the Rescue: Now, we need to move these compressed files to our backup server. rsync is the go-to tool for this. A common mistake is just pushing everything into a single directory on the backup server. To keep things organized, especially when backing up multiple source servers, it's best to create a subdirectory on the backup server named after the source server's IP address. So, from web01, the command might look like: rsync -avz /backup/ rsync_backup@<backup_server_ip>::backup/<web01_ip>/ --password-file=/etc/rsync.pass. This ensures that backups from different servers are neatly segregated.

Ensuring Integrity and Notifications

Just sending data isn't enough. We need to be sure it's complete and usable. This is where MD5 checksums come in. After the rsync transfer, you can generate MD5 sums on both the source and destination to verify that the files haven't been corrupted during transit. And to keep administrators informed, setting up email notifications for backup success or failure is crucial. This can be achieved by incorporating mail commands into your backup scripts.

Automation: The Final Touch

All these steps should be wrapped in shell scripts and then scheduled using cron to run automatically at the designated time (midnight, in our case). This ensures that backups happen consistently without manual intervention.

Building a reliable backup system takes a bit of planning and attention to detail, but the peace of mind it provides is invaluable. It’s about creating that safety net, so you can focus on running your systems, knowing your data is well-protected.