What does this guide solve?
Linux backup is more than copying files; application consistency, databases, configuration, keys/certificates and restore procedures must be designed together.
What should be backed up?
Inventory application data, databases, config, certificates/keys, cron/systemd definitions, container manifests and automation repositories.
In some environments, rebuild plus config automation is cleaner than OS-image recovery.
Snapshots and backups
LVM/ZFS/hypervisor snapshots enable fast rollback but are not independent backups when they share the same storage.
Offsite and preferably immutable copies create a separate failure domain.
Database consistency
Use supported application-aware methods for PostgreSQL/MySQL and similar systems.
Test WAL/binlog requirements and actual restore duration, not only backup completion.
Restore testing
Perform periodic full restores to clean infrastructure, file-level recovery and application startup checks.
RTO is meaningful only when restore time has been measured.
Frequently Asked Questions
Is rsync by itself a backup?
No. Without retention, versioning, immutability and offsite design it is not a complete backup strategy.
How long should snapshots be kept?
It depends on storage and change rate; independent backup is better for long retention.
Should backups be encrypted?
Especially for offsite/cloud copies, use appropriate encryption in transit and at rest.
Sources and technical references
Evaluate Your Linux Server Project
We can review your Windows/Linux roles, application dependencies and migration targets.
Architecture and operating model
Linux recovery needs package versions, mounts, service definitions, configuration and identity as well as data. Ordinary copies of running database files do not guarantee consistency. Bare-metal, file and application restores have different scope. Discover container data and external storage separately.
- 1Data/config/inventory
- 2Consistent copy
- 3Clean OS and mounts
- 4Service and user tests
Design parameters
- Data and system components
- List configuration, packages, databases, ACLs and keys separately; copying home alone does not recover a service.
- Consistent snapshot
- A filesystem snapshot does not automatically ensure application consistency; coordinate with application backup methods.
- Recovery unit
- Distinguish file, application, database and full-system recovery. Each has different dependencies and validation methods.
- Copy consistency
- Do not rely solely on job success. Verify consistency through application preparation, log-chain integrity and actual restores.
- Capacity and transfer
- Calculate using daily change, retention, full-copy method and measured throughput. Measure compression and deduplication rather than assuming ratios.
- Independent recovery
- Test access to backup management, keys, catalogs and target infrastructure after losing production.
Worked example
On a clean VM, reinstall packages, recover configuration and restore application data using supported methods. Validate UID/GID, SELinux contexts, ownership and mounts. Test a real user workflow and resumed backup after startup.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Permissions differ after recovery | UID/GID, ACLs or extended attributes may not be preserved. | Check actual reads/writes and security context as the service identity. |
| Backup succeeds but restore fails | Chain, key, catalog or application-consistency problems may be present. | Perform a real restore to a separate target; review product logs with application validation. |
| Transfer misses the target time | Source reads, networking, target writes or many small objects can limit throughput. | Measure speed and latency across all three layers simultaneously, not just link capacity. |
| Capacity grows faster than forecast | Change rate, full copies, lock periods or delayed cleanup may be missing from the estimate. | Compare actual usage and deletion-eligible points by policy. |
Acceptance checks
- Validate permissions, contexts, services and consistency separately from file counts.
- Restore the chosen recovery point to a clean target and validate business data.
- Compare the observed data-loss window with target RPO.
- Record preparation, transfer, startup and business approval separately.
- Test required recovery access without the production administrator account.
- Test protected copies with controlled deletion attempts and actual restores.
Related concepts
File permissions and service identities
File access combines users/groups, permission bits, ACLs and security policies. Running an application as root can hide permission problems; prefer a justified, restricted service identity in production. Directory traversal permission differs from file-read permission. Sharing permissions do not necessarily override filesystem restrictions. Identify the account actually running the application, directory chain and ACLs when troubleshooting. Test narrowly required access rather than opening permissions globally.
Filesystem and storage layers
An application directory, mount point, logical volume and physical device belong to different layers. Inode exhaustion, read-only mounts and filesystem errors can stop writes even when space appears available. A snapshot often shares the same storage failure domain and is not an independent backup. Mount options and expansion methods depend on the filesystem. Verify mounts after reboot: writing to an unmounted directory can fill the wrong device.
Application consistency
A bootable copy does not prove application-data consistency. Operating-system caches, database logs and write ordering across disks or services affect the result. A crash-consistent copy resembles recovery after an unexpected shutdown; an application-consistent copy follows supported application preparation and write coordination. Validate transaction integrity, relationships between records and application behavior after recovery, rather than only counting files. Confirm backup integration, application version and reported errors before assuming that consistency was achieved.
RPO and the actual loss window
RPO is the acceptable duration of data loss after an incident. A backup schedule alone does not prove it: failed jobs or delayed replication to another site can enlarge the window. Compare the incident time with the latest usable, consistent recovery point. If an incident occurs at 14:00 and the verified copy is from 13:20, the observed loss window is 40 minutes. Set targets per application; a file archive and a database receiving continuous orders may have different requirements.
RTO and end-to-end recovery time
RTO specifies how soon a service must become usable after an incident. Downloading a backup or booting a VM accounts for only part of that duration. Record detection, approval, infrastructure preparation, data transfer, application startup and business validation separately. Define exactly what starts and stops the test clock. The same technical restore duration can produce different business interruptions when dependencies or access approvals introduce additional waiting.
Encryption and key lifecycle
Encryption makes data difficult to read without its key; access control, deletion protection and backup address different needs. Identify which layer protects data in transit and data at rest. Key generation, protection, rotation and emergency recovery are part of the design. A key needed to restore a backup must not exist only on the server that could be lost in the incident. Test decryption and key-access recovery using a separate administrator in a lab, and keep real keys out of documentation and support messages.