What should you back up on a Linux server?

A Linux server contains an operating system, installed packages, configuration, application code, generated data, credentials, logs, caches, and temporary state. Treating the entire root filesystem as equally valuable makes backups larger without answering the real recovery question: what would be impossible, slow, or risky to recreate after the machine disappears?

Begin with a blank replacement-server scenario. Package repositories can usually supply the operating system again. A container registry may supply application images. Version control may supply code and infrastructure definitions. Customer uploads, database records, locally generated keys, and uncommitted configuration are different: if the server holds the only copy, losing it can be permanent.

This does not mean configuration is unimportant merely because it could be rewritten. Recovery time matters. A small set of verified configuration files and an installation record can turn a two-day forensic reconstruction into a controlled rebuild. Classify data by replacement source and recovery cost, not by directory size.

On an FHS-style Linux system, /etc is the main home of host-specific system configuration. It can include network settings, service units, scheduled jobs, user and group information, web-server configuration, database access rules, and references to secrets. Backing it up gives an operator evidence of how the host was assembled.

Do not assume every important setting is under /etc. Locally installed software may use /opt, /usr/local, /srv, an application directory, or a service user’s home. Custom systemd units and deployment environment files can also live in organization-specific locations. Follow the services you actually run.

Configuration backups are sensitive. They may contain password hashes, private keys, API credentials, internal hostnames, or database connection details. Encrypt backup contents, restrict repository access, and understand which secrets should be recovered from a separate secret manager rather than copied broadly.

Server data commonly lives under /srv, /var/lib, /var/www, /opt, or a purpose-built mount such as /data. Those conventions are clues, not proof. Inspect service definitions, application settings, mount tables, and container configuration to find the authoritative path.

Include user-generated uploads, application-managed documents, search indexes that cannot be rebuilt, license files, and local queues whose loss would matter. Mark caches and derived assets separately. If a cache can be recreated cheaply and reliably from source data, excluding it reduces backup time and restore clutter.

Check separate disks and network mounts. Linux presents them inside one directory tree, so a path can look ordinary while its underlying filesystem is absent during a backup. Conversely, a network mount may already be protected elsewhere and backing it up again could create unnecessary cost or consistency problems. Record the ownership decision.

A running database is not just a directory of unrelated files. Its engine coordinates memory, transaction state, data files, and logs. Use the database’s supported logical dump, physical backup, or snapshot procedure rather than assuming a generic file copy taken during writes is recoverable.

For PostgreSQL, pg_dump produces a consistent logical backup of one database while users continue working. Cluster-wide roles and other global objects require separate consideration, and point-in-time recovery uses a different combination of base backups and write-ahead logs. The right method follows the recovery requirement, database size, and tolerated data loss.

Protect the produced artifacts off-host and test them with the matching restore tool. Verify schema, representative records, extensions, ownership, and application behavior. A large dump file with a recent timestamp proves much less than a successful isolated restore.

Home directories can hold scripts, SSH configuration, deployment notes, cron definitions, local repositories, and operational tools. The root user’s home deserves the same review. Do not back up every personal cache by reflex, but do not assume all server administration is perfectly captured elsewhere.

Ask operators what they would search for after losing the machine. A one-off migration script, a manually maintained allowlist, or an unpushed configuration change can be operationally critical even when it should eventually move into version control. Backing it up buys recovery time; fixing its ownership prevents the next hidden dependency.

Keep an inventory of installed packages and enabled services when it will speed reconstruction. Package binaries themselves are often replaceable, while the knowledge of which versions and repositories were used may not be. The inventory is supporting recovery metadata, not a substitute for application data.

For Docker workloads, identify named volumes and bind mounts used for persistent state. Container images do not contain changes stored in attached volumes, and writable container layers disappear with containers. Compose files explain intended mounts, while runtime inspection reveals what is actually attached.

Bind mounts may point outside familiar application directories. Named volumes are managed by Docker and can change identity when a project is renamed or recreated. Map each persistent mount to a backup method and service owner, then review the mapping after deployments.

Avoid blindly copying a live database volume simply because it is easy to find. The database consistency rule still applies inside containers. Often the correct backup is a logical dump from the database service plus direct coverage for uploads and configuration.

Pseudo-filesystems and volatile paths such as /proc, /sys, /run, and much of /tmp are runtime interfaces or temporary state rather than recovery data. Caches, downloaded packages, container image layers, build outputs, and regenerated indexes may also be poor backup candidates.

An exclusion needs a reason. “Large” is not enough if the data takes days to recreate or depends on an external source that may disappear. Record the reconstruction method, expected time, and dependency. During a restore test, confirm that excluded state really is reproducible.

Logs are a judgment call. They may be required for security, audit, or incident analysis, but a backup repository is not always the best log archive. Decide retention and access separately from core service recovery, especially because logs can contain personal or sensitive data.

For each service, list its authoritative data, configuration, database artifact, required credentials, software source, backup destination, owner, and validation check. Then add explicit exclusions. This map is far more useful than a long list of filesystem paths with no explanation.

Review it against three events: the server is gone, an administrator deletes a small amount of data, and an attacker controls the provider account. Those scenarios expose different gaps. A provider snapshot may speed whole-server recovery but share an account failure domain; an encrypted off-site backup protects a different boundary.

Finally, restore a representative service to a clean target. If the team cannot rebuild without rediscovering paths or requesting missing secrets, update the map. Backup scope is correct only when it produces the service you intended to recover.