Backup and Restore Procedures

Let's start with the absolute basics. A backup is a copy of data that you keep separate from the original. The restore is the process of putting that data back where it belongs after the original is lost or damaged. In Linux, everything is a file: documents, databases, configuration settings, even the operating system itself. So backing up Linux means copying those files to another location.

Why do we need backups? Hard drives fail. People delete things by accident. Ransomware encrypts files. A building catches fire. Backups are insurance. The cost of storing backup data is tiny compared to the cost of losing business data, customer records, or an entire server.

There are different types of backups. Let's list the three main categories:

Now, how do you actually perform backups on Linux? The classic tools are tar, cpio, dd, and rsync. tar stands for 'tape archive' — historically used to write data to magnetic tape drives. Today we use tar to bundle a group of files into a single archive file (like a .tar file), often compressed with gzip or bzip2. cpio is an older tool for copying files in and out of archives. dd is a low-level tool that copies raw data, bit by bit, from one device to another — useful for cloning entire hard drives. rsync is a modern tool that synchronises files between two locations, only transferring the parts that changed, which is perfect for incremental backups over a network.

Where do you store backups? Options include local hard drives, external USB drives, network-attached storage (NAS), tape drives, and cloud storage. Each has trade-offs in speed, cost, and safety. A best practice is the 3-2-1 rule: keep three copies of your data, on two different types of media, with one copy stored off-site.

The restore process is the other half. You must be able to retrieve your data quickly. This is where backup verification comes in. A backup that you cannot read is worthless. Tools like md5sum or sha256sum generate checksums — digital fingerprints of your backup files. After creating a backup, you compute the checksum and store it separately. During a restore, you recompute the checksum and compare it. If they match, the backup is intact.

Finally, automation is critical. No one remembers to run backups manually at midnight. In Linux, you use cron to schedule backup jobs. Cron is a time-based job scheduler — you write a script that runs tar or rsync, and cron executes it at the specified time. The script should log its output to a file so you can check for errors. A typical cron entry looks like: 0 2 * * * /usr/local/bin/backup-script.sh — this runs the backup script every day at 2 AM.

The key takeaway: backups are not optional. They are the safety net that lets you sleep at night knowing your data can survive a disaster.

Imagine you are a junior systems administrator for a mid-sized e-commerce company. The company runs its website on a Linux server. Customer orders, product inventory, and payment logs are stored in a PostgreSQL database. One Tuesday morning, a developer accidentally runs a script that deletes the entire 'orders' table. The CEO wants the data back immediately.

Here is what you do step by step:

First, you assess the situation. You check if you have a backup. Let's say your team uses a nightly cron job that runs pg_dump (a PostgreSQL backup tool) to create a compressed SQL dump file, stored on a separate network drive. You locate the most recent backup file from last night, named 'orders_backup_2025-03-17.sql.gz'.

Second, you verify the backup file is not corrupted. You use the sha256sum command to compare the backup file's checksum against the one logged in your backup log. The checksums match.

Third, you restore the database. You uncompress the file with gunzip and use psql (the PostgreSQL command-line tool) to import the SQL dump into a temporary database called 'orders_recovery'. This prevents accidentally overwriting any data that may still be in the live database.

Fourth, you confirm the restored data looks correct. You run a SELECT query to count the rows in the 'orders' table. It shows exactly the number you expected. You then inform the developer to point the application to the restored database.

Finally, you document the incident. You write a post-mortem explaining what happened, how you restored the data, and what process changes could prevent a recurrence — such as adding a confirm step before destructive SQL commands.

Tools you would use in this scenario: - pg_dump for database backups - sha256sum for integrity checking - cron for scheduling - rsync to copy backup files to an off-site location - tar to bundle log files - systemd timers as an alternative to cron

The real-world lesson: a tested restore procedure is more valuable than any backup. You must practise the restore process at least quarterly, not just on the day of the crisis.