Disk Backup and Check

Data loss can begin with a failed drive, a damaged filesystem, or an accidental deletion. Whether the system is an enter

Data loss can begin with a failed drive, a damaged filesystem, or an accidental deletion. Whether the system is an enterprise server or a personal workstation, a dependable backup plan must be paired with routine disk-health checks. The goal is not merely to copy files occasionally, but to create a repeatable process that can protect data and restore it when needed.
Before designing a backup strategy, check the current condition of the storage device. Most modern hard drives, including HDDs and SSDs, support S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology). This technology records indicators such as read errors, temperature, power-on hours, and reallocated sectors.

On Linux, the smartmontools package provides the smartctl command-line utility.

Install smartmontools

On Ubuntu or Debian:

sudo apt update
sudo apt install smartmontools

Identify the device

Use lsblk to list disks and partitions, then query the selected drive:

lsblk
sudo smartctl -i /dev/sda

Replace /dev/sda with the correct device name. NVMe disks are often named /dev/nvme0, while SATA and USB devices may appear as /dev/sdX.

Run a self-test

A short self-test usually takes only a few minutes:

sudo smartctl -t short /dev/sda

After the drive completes the test, display its health status and recent results:

sudo smartctl -H /dev/sda
sudo smartctl -l selftest /dev/sda

A result of PASSED indicates that the drive did not report a failure during the test. A FAILED result should be treated seriously: back up important data immediately and plan to replace the device.

A passing S.M.A.R.T. test does not guarantee that a disk will remain operational. Some failures occur without triggering a warning, so backups, monitoring, and recovery testing are still necessary.

Checking Filesystem Integrity

Hardware health and filesystem health are separate concerns. A disk can report no mechanical problems while its filesystem contains corrupted metadata, inconsistent file sizes, or broken directory structures.

The Linux fsck utility checks and repairs common filesystem errors:

sudo fsck -f /dev/sda1

The target must be a filesystem partition, not the entire disk, such as /dev/sda1. Do not run fsck against a mounted filesystem, because active writes can make the damage worse. Unmount the partition first, or boot into a rescue environment when checking the root filesystem.

Not every filesystem supports every repair operation. Always review the reported messages and consult the relevant filesystem documentation before forcing repairs.

Choosing a Backup Strategy

A backup policy should reflect how quickly data must be recoverable and how much downtime can be tolerated. Common approaches include:

  • Full backup: Copies all selected data. Restoration is straightforward, but the operation takes more time and consumes more storage.
  • Incremental backup: Stores only changes made since the previous backup. It is fast and space-efficient, but recovery requires the full backup and every subsequent incremental set.
  • Differential backup: Stores all changes made since the last full backup. It uses more space than incremental backups but usually simplifies recovery.
  • Image or snapshot backup: Captures an entire filesystem, partition, or system state. This is useful for rapid recovery of servers and workstations.

For important data, maintain multiple generations where possible. A single current copy can be corrupted by a faulty program, ransomware, or a synchronization mistake. Versioned backups, snapshots, or retention policies provide a safety net against these events.

Creating File-Level Backups with rsync

rsync efficiently transfers and synchronizes files. It can compare source and destination data and transmit only what is necessary, making it suitable for scheduled file-level backups.

The following script mirrors a documents directory to an external drive:

#!/usr/bin/env bash
set -euo pipefail

SRC="/home/user/documents/"
DEST="/media/external-drive/backup/documents/"

rsync -a --delete --info=stats2 "$SRC" "$DEST"

Key options include:

  • -a preserves permissions, timestamps, symbolic links, and other common file attributes.
  • --delete removes destination files that no longer exist in the source directory.
  • --info=stats2 provides a useful summary of transferred data.

The trailing slash on SRC is significant: it copies the contents of documents into the destination directory. The --delete option also makes the destination an exact mirror, so use it carefully. If the source directory is mounted incorrectly or empty, the command may delete matching destination files. For archives where old versions must be preserved, omit --delete or use a tool designed for versioned backups.

Making Raw Disk Images with dd

When an exact sector-level copy is required, the dd utility can create a raw disk image:

sudo dd if=/dev/sda of=/path/to/backup/disk_image.img bs=4M status=progress conv=noerror,sync

To restore the image to another disk:

sudo dd if=/path/to/backup/disk_image.img of=/dev/sdb bs=4M status=progress

Warning: dd performs no safety checks on its destination. An incorrect of= value can overwrite an entire disk immediately. Confirm every device name and output path before running the command.

Raw imaging is most appropriate when every sector must be preserved, such as during forensic imaging or migration to a larger drive. It is less suitable as the only backup of a running system because filesystems mounted during the copy may be inconsistent. For ordinary operating-system deployment, consider filesystem-aware imaging or snapshot tools instead.

Automating Backups

Manual backups are easily postponed or forgotten. After testing the commands interactively, automate them with cron or a systemd timer.

For example, the following entry runs a backup script every day at 2:00 a.m.:

0 2 * * * /usr/local/sbin/backup-script.sh >> /var/log/backup.log 2>&1

Use absolute paths, redirect output to a log, and configure the scheduler to send an email or other alert when the job fails. The script should return a nonzero exit status if the backup does not complete correctly.

A local backup on the same disk is not sufficient. Follow the 3-2-1 rule:

  1. Keep at least three copies of important data.
  2. Use at least two different storage media or systems.
  3. Keep at least one copy in a separate physical location.

For example, retain the original data, a backup on an external drive, and an encrypted off-site copy. Protect remote storage with strong credentials, encryption, and access controls appropriate to the data.

Testing Restoration

A backup has value only when it can be restored. Schedule regular recovery drills that include more than checking whether a backup file exists.

A practical test should:

  • Restore a sample of files into a clean directory.
  • Compare restored files with source checksums.
  • Verify permissions, timestamps, symbolic links, and ownership.
  • Restore a complete system to a virtual machine or spare machine when possible.
  • Record how long the recovery takes and what steps are missing.
  • Review backup and hardware-monitoring logs for unnoticed failures.

By combining disk-health monitoring, filesystem checks, structured backup policies, and tested recovery procedures, administrators can reduce both the likelihood and the impact of data loss. The strongest backup plan is not the one with the most data copied; it is the one that can reliably bring the data back when the original disk becomes unavailable.