How to Choose the Right Backup Solution for Your Linux Server

Table of Contents

1. Understanding Your Backup Needs
2. Types of Backups: Which One Fits Your Workflow?
3. Key Features to Look for in a Linux Backup Solution
4. Popular Linux Backup Tools: Pros, Cons, and Use Cases
5. Step-by-Step: How to Choose Your Backup Solution
6. Best Practices for Linux Server Backups
7. Conclusion
8. References

1. Understanding Your Backup Needs

Before diving into tools, you must first define what you need to back up, how critical it is, and how quickly you need to recover it. Answering these questions will narrow down your options.

1.1 What Data Are You Protecting?

Not all data is created equal. Start by categorizing your server’s data:

• Critical data: Databases (MySQL, PostgreSQL), user data (/home), application configurations (/etc), or customer records. Loss here could halt operations.
• Non-critical data: Logs (/var/log), cached files, or temporary directories. Loss here is inconvenient but not catastrophic.
• System state: The entire OS, including kernel, drivers, and installed packages (useful for disaster recovery).

Example: A small business server might prioritize its PostgreSQL database and customer files, while a developer’s server might focus on project code and Docker containers.

1.2 How Much Data Do You Have?

Storage size dictates tool choice. A 10GB blog database has different needs than a 10TB media server. Tools like BorgBackup excel at deduplicating large datasets, while simpler tools (e.g., rsync) may struggle with scale.

1.3 What Are Your RTO and RPO?

• Recovery Time Objective (RTO): How long can your server be down before operations are disrupted? A e-commerce site might need RTO < 1 hour; a personal blog could tolerate 24 hours.
• Recovery Point Objective (RPO): How much data can you afford to lose? A financial system might require RPO = 5 minutes (near real-time backups), while a static website could use RPO = 1 day (daily backups).

1.4 Where Will You Store Backups?

• Local storage: External HDDs, NAS devices, or another server on-site. Fast recovery but vulnerable to physical disasters (e.g., fire, theft).
• Offsite/cloud storage: AWS S3, Backblaze B2, or a remote server. Protects against local disasters but may have slower recovery (due to bandwidth).
• Hybrid: A mix of local and offsite (e.g., daily local backups + weekly cloud syncs).

1.5 Compliance and Security Requirements

If you handle sensitive data (e.g., healthcare, finance), compliance standards (HIPAA, GDPR) may mandate:

• Encryption (at rest and in transit).
• Immutable backups (to prevent ransomware deletion).
• Audit logs for backup activity.

2. Types of Backups: Which One Fits Your Workflow?

Backup solutions use different strategies to balance speed, storage, and recovery ease. Here’s how they stack up:

2.1 Full Backups

What: Copies all selected data every time.
Pros: Simplest recovery (one file to restore).
Cons: Slow (copies everything) and storage-heavy (duplicates unchanged data).
Best for: Small datasets, initial backups, or systems with strict RTOs (since recovery is fast).

2.2 Incremental Backups

What: Copies only data changed since the last backup (full or incremental).
Pros: Fast backups and minimal storage (only new/changed data).
Cons: Recovery is slow: you need the full backup + all incremental backups since then.
Best for: Large datasets with frequent changes (e.g., active databases) and low RPOs.

2.3 Differential Backups

What: Copies data changed since the last full backup.
Pros: Faster recovery than incremental (full + latest differential).
Cons: Slower than incremental over time (backs up more data as changes accumulate).
Best for: Balancing backup speed and recovery simplicity (e.g., weekly full + daily differential).

2.4 Snapshot Backups

What: Captures the state of a filesystem at a point in time (e.g., LVM snapshots, ZFS zvols).
Pros: Near-instantaneous (no data copying upfront); ideal for live systems (e.g., databases).
Cons: Snapshots are not backups—they’re stored on the same disk, so disk failure destroys both data and snapshots. Always pair with a secondary backup.

2.5 Cloud-Native Backups

What: Backups stored in the cloud (e.g., AWS S3, Google Cloud Storage) with tools like rclone or cloud provider APIs.
Pros: Scalable, offsite, and often managed (e.g., AWS Glacier for long-term archiving).
Cons: Cost (bandwidth + storage fees) and latency for large restores.

Comparison Table

3. Key Features to Look for in a Linux Backup Solution

Not all tools are created equal. Prioritize these features based on your needs:

3.1 Reliability

The tool must consistently complete backups without corruption. Look for:

• Checksums (e.g., SHA256) to verify data integrity.
• Crash recovery (resumes interrupted backups).
• A track record (avoid unmaintained “hobby” tools for critical data).

3.2 Deduplication and Compression

• Deduplication: Eliminates redundant data (e.g., 10 copies of the same PDF are stored once). Critical for large datasets (e.g., media libraries).
• Compression: Reduces backup size (e.g., gzip, LZ4). Tools like BorgBackup and Restic excel here.

3.3 Encryption

Sensitive data (e.g., user passwords) must be encrypted:

• At rest: Backups stored on disks/cloud are unreadable without a key.
• In transit: Data transferred to offsite storage is encrypted (e.g., TLS).
  Tools like Restic and BorgBackup encrypt by default; avoid tools with weak encryption (e.g., DES).

3.4 Automation

Manual backups are error-prone. Look for:

• Scheduling (e.g., cron jobs, systemd timers).
• Event triggers (e.g., backup after a database dump).
• Retention policies (auto-delete old backups to save space).

3.5 Ease of Use

• CLI vs. GUI: Linux admins often prefer CLI tools (e.g., borg, restic) for scripting, but GUIs (e.g., Webmin for Amanda) simplify management for teams.
• Documentation: Clear guides for setup, recovery, and troubleshooting.

3.6 Scalability

As your data grows, the tool should scale:

• Support for large files (e.g., 4GB+).
• Parallel processing (back up multiple directories at once).
• Integration with cloud storage (e.g., S3, Backblaze B2) for infinite capacity.

3.7 Compatibility

Ensure the tool works with your:

• Filesystem (ext4, XFS, ZFS).
• Storage targets (local disks, NAS, cloud).
• Server architecture (x86, ARM, Docker/Kubernetes).

4. Popular Linux Backup Tools: Pros, Cons, and Use Cases

Linux has no shortage of backup tools. Here’s how to pick the right one for your scenario:

4.1 BorgBackup (Borg)

Type: Deduplicating, incremental backup tool.
Key Features: Deduplication, compression, AES-256 encryption, client-server support.
Use Case: Large datasets (e.g., 1TB+), developers, or anyone needing space-efficient backups.
Pros: Open-source, fast, and highly efficient (deduplication reduces storage by 50-90%).
Cons: CLI-only (no official GUI); steeper learning curve for beginners.
Example Command:

borg create --compression zstd /backup/server::$(date +%F) /home /etc /var/lib/postgresql  

4.2 Restic

Type: Secure, deduplicating backup tool.
Key Features: Encryption, deduplication, cloud support (S3, B2), cross-platform (Linux/macOS/Windows).
Use Case: Users prioritizing security and cloud integration (e.g., backing up to AWS S3).
Pros: Simpler CLI than Borg; native cloud support; checksums for integrity.
Cons: Less mature than Borg (fewer plugins); slower for very large datasets.
Example Command:

restic -r s3:s3.amazonaws.com/my-backups init  # Initialize repo  
restic -r s3:s3.amazonaws.com/my-backups backup /home  

4.3 rsync

Type: File synchronization tool (not a “backup” tool, but widely used for backups).
Key Features: Incremental transfers, compression, SSH support.
Use Case: Simple, lightweight backups (e.g., syncing a blog’s /var/www to a NAS).
Pros: Preinstalled on most Linux distros; simple syntax; fast for small datasets.
Cons: No deduplication/encryption (requires extra tools like ssh + gpg); not ideal for large-scale backups.
Example Command:

rsync -avz /home/user/ [email protected]:/backup/home/  # Sync to remote server  

4.4 Timeshift

Type: System snapshot tool (like Windows System Restore).
Key Features: Creates restore points for the OS, supports Btrfs/LVM snapshots.
Use Case: Desktop Linux or single-server disaster recovery (e.g., restoring after a bad update).
Pros: GUI/CLI options; simple recovery; lightweight.
Cons: Not for user data (use alongside borg for files); limited to local storage.

4.5 Amanda (Advanced Maryland Automatic Network Disk Archiver)

Type: Enterprise-grade network backup suite.
Key Features: Client-server architecture, supports multiple OSes, tape/cloud storage, reporting.
Use Case: Large organizations with multiple servers (e.g., a company with 50+ Linux workstations).
Pros: Scalable; centralized management; audit logs for compliance.
Cons: Complex setup; overkill for small environments.

4.6 Rclone

Type: Cloud storage sync tool.
Key Features: Supports 40+ cloud providers (S3, Google Drive, Dropbox); encryption; chunked uploads.
Use Case: Syncing local backups to the cloud (e.g., daily borg backup → weekly rclone to Backblaze B2).
Pros: Universal cloud support; fast transfers; scriptable.
Cons: Not a backup tool alone (use with borg/restic for versioning).

Tool Selection Cheat Sheet

5. Step-by-Step: How to Choose Your Backup Solution

Follow this workflow to select and implement your tool:

Step 1: Define Your Requirements

Use Section 1 to document:

• Critical data (e.g., /var/lib/mysql, /home).
• Data size (e.g., 500GB).
• RTO/RPO (e.g., RTO=1 hour, RPO=1 day).
• Storage targets (e.g., local NAS + AWS S3).

Step 2: Shortlist Tools

Use Section 4 to list 2-3 tools that match your needs. For example:

• Scenario: 2TB media server, RPO=1 day, offsite storage.
• Shortlist: BorgBackup (deduplication) + rclone (cloud sync).

Step 3: Test the Tool

Never deploy a tool without testing:

• Backup test: Run a full backup and check size/speed.
• Recovery test: Restore a file/directory to verify integrity.
• Edge cases: Test interrupted backups, corrupted files, or network outages.

Step 4: Evaluate Cost

• Open-source tools: Free (e.g., Borg, Restic) but require admin time.
• Paid tools: Enterprise support (e.g., Veeam for Linux) but cost $$$.
• Cloud storage: Factor in bandwidth (e.g., AWS S3 egress fees).

Step 5: Check Support and Community

• Active forums (e.g., Reddit r/linuxquestions, Borg GitHub).
• Regular updates (avoid tools with 2+ years of inactivity).

Step 6: Implement and Monitor

• Automate backups with cron or systemd timers.
• Set up alerts (e.g., email/Slack notifications for failed backups).
• Logs: Store backup logs in /var/log/backups/ and audit monthly.

6. Best Practices for Linux Server Backups

Even the best tool fails without good habits:

6.1 Follow the 3-2-1 Rule

• 3 copies of data: Original + 2 backups.
• 2 storage types: Local (HDD) + cloud (S3) or tape.
• 1 offsite copy: Protects against fires, floods, or theft.

6.2 Test Backups Regularly

A backup that can’t be restored is useless. Test recovery:

• Monthly: Restore a random file and verify it opens.
• Quarterly: Full system restore to a test server.

6.3 Encrypt Everything

Use tools like borg or restic to encrypt backups. Store encryption keys offline (e.g., a hardware wallet) to avoid lockouts.

6.4 Automate and Monitor

• Use cron to schedule backups (e.g., 0 2 * * * /usr/local/bin/backup-script.sh).
• Monitor logs with tools like Prometheus + Grafana or simple scripts (e.g., grep "ERROR" /var/log/backups/borg.log | mail -s "Backup Failed" [email protected]).

6.5 Prune Old Backups

Use retention policies to avoid storage bloat:

• Example: Keep daily backups for 7 days, weekly for 4 weeks, monthly for 6 months.
  Borg/Restic have built-in prune commands (e.g., borg prune --keep-daily=7 /backup/repo).

7. Conclusion

Choosing the right Linux server backup solution isn’t about picking the “best” tool—it’s about aligning tools with your unique needs. Start by defining your data, RTO/RPO, and storage targets, then evaluate tools based on reliability, encryption, and scalability.

Remember# How to Choose the Right Backup Solution for Your Linux Server

Introduction

In today’s digital landscape, data is the lifeblood of businesses, developers, and system administrators. For Linux server users—whether managing a personal blog, an enterprise-grade application, or a distributed cloud infrastructure—the risk of data loss is ever-present: hardware failures, ransomware attacks, human error, or even natural disasters can erase critical files, databases, or configurations in minutes. A reliable backup solution isn’t just a “nice-to-have”; it’s a non-negotiable safety net.

But with hundreds of tools, strategies, and buzzwords (deduplication! snapshots! 3-2-1 rule!), choosing the right backup solution for your Linux server can feel overwhelming. Do you need a simple command-line tool or an enterprise-grade platform? Should you back up to local disks, the cloud, or both? What about encryption, automation, or recovery speed?

This guide cuts through the noise to help you systematically evaluate your needs and select a backup solution tailored to your Linux environment. We’ll break down key concepts, compare popular tools, and walk through a step-by-step decision process—so you can rest easy knowing your data is protected.

Table of Contents

1. Understanding Your Backup Needs
2. Types of Backups: Which One Fits Your Workflow?
3. Key Features to Look for in a Linux Backup Solution
4. Popular Linux Backup Tools: Pros, Cons, and Use Cases
5. Step-by-Step: How to Choose Your Backup Solution
6. Best Practices for Linux Server Backups
7. Conclusion
8. References

1. Understanding Your Backup Needs

Before diving into tools, you must first define what you need to back up, how critical it is, and how quickly you need to recover it. Answering these questions will narrow down your options.

1.1 What Data Are You Protecting?

Not all data is created equal. Start by categorizing your server’s data:

• Critical data: Databases (MySQL, PostgreSQL), user data (/home), application configurations (/etc), or customer records. Loss here could halt operations.
• Non-critical data: Logs (/var/log), cached files, or temporary directories. Loss here is inconvenient but not catastrophic.
• System state: The entire OS, including kernel, drivers, and installed packages (useful for disaster recovery).

Example: A small business server might prioritize its PostgreSQL database and customer files, while a developer’s server might focus on project code and Docker containers.

1.2 How Much Data Do You Have?

Storage size dictates tool choice. A 10GB blog database has different needs than a 10TB media server. Tools like BorgBackup excel at deduplicating large datasets, while simpler tools (e.g., rsync) may struggle with scale.

1.3 What Are Your RTO and RPO?

• Recovery Time Objective (RTO): How long can your server be down before operations are disrupted? A e-commerce site might need RTO < 1 hour; a personal blog could tolerate 24 hours.
• Recovery Point Objective (RPO): How much data can you afford to lose? A financial system might require RPO = 5 minutes (near real-time backups), while a static website could use RPO = 1 day (daily backups).

1.4 Where Will You Store Backups?

• Local storage: External HDDs, NAS devices, or another server on-site. Fast recovery but vulnerable to physical disasters (e.g., fire, theft).
• Offsite/cloud storage: AWS S3, Backblaze B2, or a remote server. Protects against local disasters but may have slower recovery (due to bandwidth).
• Hybrid: A mix of local and offsite (e.g., daily local backups + weekly cloud syncs).

1.5 Compliance and Security Requirements

If you handle sensitive data (e.g., healthcare, finance), compliance standards (HIPAA, GDPR) may mandate:

• Encryption (at rest and in transit).
• Immutable backups (to prevent ransomware deletion).
• Audit logs for backup activity.

2. Types of Backups: Which One Fits Your Workflow?

Backup solutions use different strategies to balance speed, storage, and recovery ease. Here’s how they stack up:

2.1 Full Backups

What: Copies all selected data every time.
Pros: Simplest recovery (one file to restore).
Cons: Slow (copies everything) and storage-heavy (duplicates unchanged data).
Best for: Small datasets, initial backups, or systems with strict RTOs (since recovery is fast).

2.2 Incremental Backups

What: Copies only data changed since the last backup (full or incremental).
Pros: Fast backups and minimal storage (only new/changed data).
Cons: Recovery is slow: you need the full backup + all incremental backups since then.
Best for: Large datasets with frequent changes (e.g., active databases) and low RPOs.

2.3 Differential Backups

What: Copies data changed since the last full backup.
Pros: Faster recovery than incremental (full + latest differential).
Cons: Slower than incremental over time (backs up more data as changes accumulate).
Best for: Balancing backup speed and recovery simplicity (e.g., weekly full + daily differential).

2.4 Snapshot Backups

What: Captures the state of a filesystem at a point in time (e.g., LVM snapshots, ZFS zvols).
Pros: Near-instantaneous (no data copying upfront); ideal for live systems (e.g., databases).
Cons: Snapshots are not backups—they’re stored on the same disk, so disk failure destroys both data and snapshots. Always pair with a secondary backup.

2.5 Cloud-Native Backups

What: Backups stored in the cloud (e.g., AWS S3, Google Cloud Storage) with tools like rclone or cloud provider APIs.
Pros: Scalable, offsite, and often managed (e.g., AWS Glacier for long-term archiving).
Cons: Cost (bandwidth + storage fees) and latency for large restores.

Comparison Table

3. Key Features to Look for in a Linux Backup Solution

Not all tools are created equal. Prioritize these features based on your needs:

3.1 Reliability

The tool must consistently complete backups without corruption. Look for:

• Checksums (e.g., SHA256) to verify data integrity.
• Crash recovery (resumes interrupted backups).
• A track record (avoid unmaintained “hobby” tools for critical data).

3.2 Deduplication and Compression

• Deduplication: Eliminates redundant data (e.g., 10 copies of the same PDF are stored once). Critical for large datasets (e.g., media libraries).
• Compression: Reduces backup size (e.g., gzip, LZ4). Tools like BorgBackup and Restic excel here.

3.3 Encryption

Sensitive data (e.g., user passwords) must be encrypted:

• At rest: Backups stored on disks/cloud are unreadable without a key.
• In transit: Data transferred to offsite storage is encrypted (e.g., TLS).
  Tools like Restic and BorgBackup encrypt by default; avoid tools with weak encryption (e.g., DES).

3.4 Automation

Manual backups are error-prone. Look for:

• Scheduling (e.g., cron jobs, systemd timers).
• Event triggers (e.g., backup after a database dump).
• Retention policies (auto-delete old backups to save space).

3.5 Ease of Use

• CLI vs. GUI: Linux admins often prefer CLI tools (e.g., borg, restic) for scripting, but GUIs (e.g., Webmin for Amanda) simplify management for teams.
• Documentation: Clear guides for setup, recovery, and troubleshooting.

3.6 Scalability

As your data grows, the tool should scale:

• Support for large files (e.g., 4GB+).
• Parallel processing (back up multiple directories at once).
• Integration with cloud storage (e.g., S3, Backblaze B2) for infinite capacity.

3.7 Compatibility

Ensure the tool works with your:

• Filesystem (ext4, XFS, ZFS).
• Storage targets (local disks, NAS, cloud).
• Server architecture (x86, ARM, Docker/Kubernetes).

4. Popular Linux Backup Tools: Pros, Cons, and Use Cases

Linux has no shortage of backup tools. Here’s how to pick the right one for your scenario:

4.1 BorgBackup (Borg)

Type: Deduplicating, incremental backup tool.
Key Features: Deduplication, compression, AES-256 encryption, client-server support.
Use Case: Large datasets (e.g., 1TB+), developers, or anyone needing space-efficient backups.
Pros: Open-source, fast, and highly efficient (deduplication reduces storage by 50-90%).
Cons: CLI-only (no official GUI); steeper learning curve for beginners.
Example Command:

borg create --compression zstd /backup/server::$(date +%F) /home /etc /var/lib/postgresql  

4.2 Restic

Type: Secure, deduplicating backup tool.
Key Features: Encryption, deduplication, cloud support (S3, B2), cross-platform (Linux/macOS/Windows).
Use Case: Users prioritizing security and cloud integration (e.g., backing up to AWS S3).
Pros: Simpler CLI than Borg; native cloud support; checksums for integrity.
Cons: Less mature than Borg (fewer plugins); slower for very large datasets.
Example Command:

restic -r s3:s3.amazonaws.com/my-backups init  # Initialize repo  
restic -r s3:s3.amazonaws.com/my-backups backup /home  

4.3 rsync

Type: File synchronization tool (not a “backup” tool, but widely used for backups).
Key Features: Incremental transfers, compression, SSH support.
Use Case: Simple, lightweight backups (e.g., syncing a blog’s /var/www to a NAS).
Pros: Preinstalled on most Linux distros; simple syntax; fast for small datasets.
Cons: No deduplication/encryption (requires extra tools like ssh + gpg); not ideal for large-scale backups.
Example Command:

rsync -avz /home/user/ [email protected]:/backup/home/  # Sync to remote server  

4.4 Timeshift

Type: System snapshot tool (like Windows System Restore).
Key Features: Creates restore points for the OS, supports Btrfs/LVM snapshots.
Use Case: Desktop Linux or single-server disaster recovery (e.g., restoring after a bad update).
Pros: GUI/CLI options; simple recovery; lightweight.
Cons: Not for user data (use alongside borg for files); limited to local storage.

4.5 Amanda (Advanced Maryland Automatic Network Disk Archiver)

Type: Enterprise-grade network backup suite.
Key Features: Client-server architecture, supports multiple OSes, tape/cloud storage, reporting.
Use Case: Large organizations with multiple servers (e.g., a company with 50+ Linux workstations).
Pros: Scalable; centralized management; audit logs for compliance.
Cons: Complex setup; overkill for small environments.

4.6 Rclone

Type: Cloud storage sync tool.
Key Features: Supports 40+ cloud providers (S3, Google Drive, Dropbox); encryption; chunked uploads.
Use Case: Syncing local backups to the cloud (e.g., daily borg backup → weekly rclone to Backblaze B2).
Pros: Universal cloud support; fast transfers; scriptable.
Cons: Not a backup tool alone (use with borg/restic for versioning).

Tool Selection Cheat Sheet

5. Step-by-Step: How to Choose Your Backup Solution

Follow this workflow to select and implement your tool:

Step 1: Define Your Requirements

Use Section 1 to document:

• Critical data (e.g., /var/lib/mysql, /home).
• Data size (e.g., 500GB).
• RTO/RPO (e.g., RTO=1 hour, RPO=1 day).
• Storage targets (e.g., local NAS + AWS S3).

Step 2: Shortlist Tools

Use Section 4 to list 2-3 tools that match your needs. For example:

• Scenario: 2TB media server, RPO=1 day, offsite storage.
• Shortlist: BorgBackup (deduplication) + rclone (cloud sync).

Step 3: Test the Tool

Never deploy a tool without testing:

• Backup test: Run a full backup and check size/speed.
• Recovery test: Restore a file/directory to verify integrity.
• Edge cases: Test interrupted backups, corrupted files, or network outages.

Step 4: Evaluate Cost

• Open-source tools: Free (e.g., Borg, Restic) but require admin time.
• Paid tools: Enterprise support (e.g., Veeam for Linux) but cost $$$.
• Cloud storage: Factor in bandwidth (e.g., AWS S3 egress fees).

Step 5: Check Support and Community

• Active forums (e.g., Reddit r/linuxquestions, Borg GitHub).
• Regular updates (avoid tools with 2+ years of inactivity).

Step 6: Implement and Monitor

• Automate backups with cron or systemd timers.
• Set up alerts (e.g., email/Slack notifications for failed backups).
• Logs: Store backup logs in /var/log/backups/ and audit monthly.

6. Best Practices for Linux Server Backups

Even the best tool fails without good habits:

6.1 Follow the 3-2-1 Rule

• 3 copies of data: Original + 2 backups.
• 2 storage types: Local (HDD) + cloud (S3) or tape.
• 1 offsite copy: Protects against fires, floods, or theft.

6.2 Test Backups Regularly

A backup that can’t be restored is useless. Test recovery:

• Monthly: Restore a random file and verify it opens.
• Quarterly: Full system restore to a test server.

6.3 Encrypt Everything

Use tools like borg or restic to encrypt backups. Store encryption keys offline (e.g., a hardware wallet) to avoid lockouts.

6.4 Automate and Monitor

• Use cron to schedule backups (e.g., 0 2 * * * /usr/local/bin/backup-script.sh).
• Monitor logs with tools like Prometheus + Grafana or simple scripts (e.g., grep "ERROR" /var/log/backups/borg.log | mail -s "Backup Failed" [email protected]).

6.5 Prune Old Backups

Use retention policies to avoid storage bloat:

• Example: Keep daily backups for 7 days, weekly for 4 weeks, monthly for 6 months.
  Borg/Restic have built-in prune commands (e.g., borg prune --keep-daily=7 /backup/repo).

7. Conclusion

Choosing the right Linux server backup solution isn’t about picking the “best” tool—it’s about aligning tools with your unique needs. Start by defining your data, RTO/RPO, and storage targets, then evaluate tools based on reliability, encryption, and scalability.

Remember: The best backup solution is one you test regularly and update as your server’s needs evolve. With the right strategy, you can turn data loss from a disaster into a minor inconvenience.

8. References

• BorgBackup Official Documentation: https://borgbackup.readthedocs.io
• Restic Official Documentation: https://restic.net
• Amanda Backup Project: https://www.amanda.org
• “RTO and RPO Best Practices” – NIST Special Publication 800-34: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf
• 3-2-1 Backup Rule – Backblaze: https://www.backblaze.com/blog/the-3-2-1-backup-strategy/