Choose what to include in a Linux server backup

Build the backup set around what you need to restore. Linux runtime filesystems usually do not belong in a file backup, but a directory name alone is not enough to decide whether its contents are expendable. Check mounts and application ownership before setting exclusions.

Separate runtime state from persistent data

/mnt is an ordinary directory that may be used as a mount point. It is not inherently a virtual filesystem. Similarly, image layers, archived logs, and large object-store mounts need an explicit recovery decision rather than blanket exclusion.

Prevent recursion into the backup destination

The following GNU/Linux rsync example assumes /backup is the dedicated destination and that other mounted filesystems will be backed up separately:

sudo rsync -aAXHnx --numeric-ids \
  --exclude='/dev/***' --exclude='/proc/***' --exclude='/sys/***' \
  --exclude='/run/***' --exclude='/tmp/***' \
  --exclude='/mnt/***' --exclude='/media/***' \
  --exclude='/backup/***' \
  / /backup/server-root/

This is a dry run (-n). -x avoids crossing filesystem boundaries, so a separate /home, /var, or /boot mount needs another planned backup. Same-filesystem bind mounts and unusual mount arrangements still require inspection. Adjust exclusions for local swap files and reviewed recovery directories, then inspect the file list before removing -n.

A GNU tar alternative uses paths relative to / and excludes its output location:

sudo tar --acls --xattrs --numeric-owner --one-file-system \
  --exclude='./proc' --exclude='./sys' --exclude='./dev' \
  --exclude='./run' --exclude='./tmp' --exclude='./mnt' \
  --exclude='./media' --exclude='./backup' \
  -czpf /backup/server-root.tar.gz -C / .

These are file-copy examples, not complete bare-metal recovery procedures. Files changing during the run can produce an inconsistent copy; permissions, boot metadata, partition layouts, encryption keys, and mount definitions also need a recovery plan.

Include the state that rebuilds the service

Check /etc, /home, /root, /srv, /var/www, custom /opt deployments, cron definitions and spools, certificates and private keys, and application state under /var/lib. Protect backups containing credentials with appropriate encryption and access controls.

Use database-native logical or physical backups, or a documented application-consistent snapshot procedure. Copying live database files without coordination can produce an unusable database.

For containers, preserve volumes, bind-mounted state, deployment files, and secrets through their approved backup mechanisms. Images are rebuildable only when their source and registry artifacts remain available. A .env file is not safely backed up merely because deployment code is in Git; secrets often should not be in Git at all.

Test restoration

Record each job's outcome and verify restores on an isolated host. Confirm the application starts, data is consistent, and required credentials are recoverable. Collected job logs and Guance log monitors can flag reported failures or missing completion events, but restore tests establish whether the backup is usable.

References: rsync and GNU tar exclusions.