DPTCloud
Back to articles
Technology Insight

Architecting an Automated, End-to-End Encrypted 3-2-1 Distributed Backup System with BorgBackup and Linux VPS

May 27, 2026

Introduction: The Cost of Vulnerability in the Digital Era

In the modern enterprise landscape, data is arguably an organization’s most valuable asset. Yet, many businesses remain dangerously exposed to catastrophic data loss events. From targeted ransomware strains and hardware failures to human error and localized physical disasters, the threats to operational continuity are omnipresent. Relying on basic, manual, or localized backup routines is no longer just a technical oversight; it is a profound business risk.

To mitigate these hazards, IT leaders and system architects consistently point to the 3-2-1 backup strategy as the industry gold standard. However, implementing this model traditionally meant balancing high enterprise software licensing fees against complex, fragmented configurations. This comprehensive guide outlines how to bridge that gap. By combining the enterprise-grade efficiency of BorgBackup (Borg), the security of end-to-end encryption (E2EE), and the affordability of distributed Virtual Private Servers (VPS), we will construct a fully automated, resilient backup pipeline engineered to protect your critical infrastructure.

---

Demystifying the Architecture: The 3-2-1 Principle Enhanced by Borg

Before diving into configuration files, it is vital to understand the structural blueprint of our architecture. The 3-2-1 rule dictates that an organization must:

  • Maintain at least three (3) copies of data (the primary production data and at least two distinct backups).
  • Store these copies on two (2) different types of media (e.g., local NVMe arrays, internal NAS, or block storage).
  • Keep at least one (1) copy offsite (geographically separated from the primary infrastructure).

While the strategy is conceptually straightforward, execution is where efficiency often breaks down. Large datasets require massive bandwidth, storage costs can scale exponentially, and exposure during transit or at rest poses severe security risks. This is precisely where BorgBackup becomes invaluable.

Why BorgBackup?

BorgBackup is an open-source, deduplicating backup program written in Python and C. It solves the core dilemmas of distributed backups through three pillars:

  1. Authenticated End-to-End Encryption: Data is encrypted on the client side before it ever leaves your local network. The remote storage provider (the VPS) only ever sees encrypted chunks, establishing a zero-trust model.
  2. Deduplication at the Chunk Level: Borg splits files into variable-length chunks. Only modified or unique chunks are added to the repository. This dramatically reduces storage consumption and slashes bandwidth usage, making frequent offsite syncing highly feasible.
  3. Data Integrity and Speed: Using cryptographic hashes (HMAC-SHA256) to verify integrity and leveraging highly optimized C code, Borg executes rapid backup sequences while ensuring files can be reliably restored without corruption.
---

Phase 1: Environment Setup and Key Prerequisites

To implement this architecture, we will utilize a local production server (holding the active data) and two geographically isolated Linux VPS instances serving as storage nodes. This satisfies both the distributed and offsite components of our strategy.

System Requirements

  • Local Production Server: Linux environment (Ubuntu 22.04 LTS/24.04 LTS recommended) containing the source directories.
  • Offsite VPS Node A (The Primary Remote Target): A secure Linux VPS equipped with sufficient storage blocks. For optimal cost efficiency, storage-optimized VPS providers are highly recommended.
  • Offsite VPS Node B (The Secondary/DR Target): Located in an entirely separate geographical region or under a different cloud provider to eliminate single-point-of-failure risks.

Installing BorgBackup

Borg must be installed on both the client (production server) and the backup servers (VPS targets). Execute the following commands across all systems to ensure version parity:

sudo apt update && sudo apt install -y borgbackup

Verify the installation by running borg --version to ensure the binaries are active and ready.

---

Phase 2: Secure Initialization and Repository Creation

Security is the foundation of this setup. Communication between the production server and the VPS targets will be facilitated entirely over SSH, secured by cryptographic key pairs. Root logins should be strictly restricted; instead, create a dedicated, unprivileged borg user on each VPS.

Establishing SSH Trust

On your local production server, generate a dedicated SSH key pair for the automated process:

ssh-keygen -t ed25519 -f ~/.ssh/id_borg_automation -N ""

Append the public key (id_borg_automation.pub) to the ~/.ssh/authorized_keys file of the borg user on both VPS targets. To maximize security, restrict the SSH key execution rights by prepending the forced-command parameters inside the authorized_keys file, limiting the key strictly to executing Borg processes.

Initializing Encrypted Repositories

With SSH communication established, initialize the remote repositories from the production server. We will employ the repokey-blake2 encryption mode, which embeds the encryption key inside the repository passphrase-protected header, using BLAKE2 for lightning-fast cryptographic hashing.

# Initializing Repository on VPS Node A
borg init --encryption=repokey-blake2 [email protected]:/var/backup/prod_repo

# Initializing Repository on VPS Node B
borg init --encryption=repokey-blake2 [email protected]:/var/backup/prod_repo
Critical Warning: During initialization, you will be prompted to enter a repository passphrase. Record this passphrase securely in an external password manager. If you lose this passphrase and your local system fails, your encrypted offsite backups will be permanently unrecoverable. Additionally, export the repository keys using the borg key export command and save them in a secure physical or secondary digital location.
---

Phase 3: Crafting the Automation and Retention Script

To eliminate reliance on manual intervention, we must write a robust shell script that handles the end-to-end backup sequence, monitors exit codes, prunes obsolete archives according to a strict retention policy, and optimizes the repository through compaction.

Create a script named /usr/local/bin/borg_backup.sh on the production server:

#!/bin/bash
# Enterprise BorgBackup Automation Script

# Environment Variables
export BORG_PASSPHRASE="your_secure_passphrase_here"
export BORG_RSH="ssh -i /root/.ssh/id_borg_automation -o StrictHostKeyChecking=accept-new"

# Source Paths
SOURCE_DIRS="/var/www /etc /home/database_dumps"

# Targets
TARGET_A="[email protected]:/var/backup/prod_repo"
TARGET_B="[email protected]:/var/backup/prod_repo"

# Metadata
ARCHIVE_NAME="$(hostname)-$(date +%Y-%m-%d_%H%M%S)"

echo "=== Starting Backup Process: $(date) ==="

# --- Backup to Node A ---
echo "Archiving to Remote Target A..."
borg create --stats --progress $TARGET_A::$ARCHIVE_NAME $SOURCE_DIRS
if [ $? -eq 0 ] || [ $? -eq 1 ]; then
    echo "Target A Backup Successful. Pruning old archives..."
    borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 $TARGET_A
    borg compact $TARGET_A
else
    echo "CRITICAL: Backup to Target A failed!" >&2
fi

# --- Backup to Node B (Redundancy Layer) ---
echo "Archiving to Remote Target B..."
borg create --stats --progress $TARGET_B::$ARCHIVE_NAME $SOURCE_DIRS
if [ $? -eq 0 ] || [ $? -eq 1 ]; then
    echo "Target B Backup Successful. Pruning old archives..."
    borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 $TARGET_B
    borg compact $TARGET_B
else
    echo "CRITICAL: Backup to Target B failed!" >&2
fi

echo "=== Backup Process Completed: $(date) ==="

Make the script executable and restrict permissions so that unauthorized system users cannot view the plaintext passphrase inside:

sudo chmod 700 /usr/local/bin/borg_backup.sh

Analyzing the Retention and Pruning Policy

The borg prune flags implemented in our script provide automated lifecycle management. The settings --keep-daily=7 --keep-weekly=4 --keep-monthly=6 guarantee that your system retains a granular history:

  • Every incremental backup for the last 7 days.
  • One weekly snapshot for the last 4 weeks.
  • One monthly snapshot for the trailing 6 months.

Old, redundant chunks are flagged automatically, and the borg compact command frees up that physical storage space on the remote Linux VPS instances, preventing runaway infrastructure costs.

---

Phase 4: Scheduling and Systemd Integration

To ensure this routine executes flawlessly without manual oversight, we will hook our script into systemd timers. Systemd timers provide far more detailed logging, failure alerting, and deterministic execution control than traditional cron jobs.

Creating the Systemd Service File

Define the service execution blueprint by creating /etc/systemd/system/borg-backup.service:

[Unit]
Description=Automated BorgBackup Service
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/borg_backup.sh
User=root
StandardOutput=journal
StandardError=journal

Creating the Systemd Timer File

Schedule the task by creating /etc/systemd/system/borg-backup.timer. This configuration fires the backup script every night at 02:00 AM, a period typically characterized by low production workloads.

[Unit]
Description=Run BorgBackup Daily at 2 AM

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

Enable and start the timer using the systemctl command suite:

sudo systemctl daemon-reload
sudo systemctl enable --now borg-backup.timer

You can check the status of your newly deployed backup schedule at any time by executing: systemctl status borg-backup.timer.

---

Phase 5: Disaster Recovery and Verification Workflows

A backup pipeline is only as good as its proven recovery capability. Administrators must periodically test the restoration process to ensure keys, passwords, and data integrity remain functional under disaster conditions.

Listing Available Archives

To view the comprehensive historical line of snapshots available in your remote distributed cluster, query the VPS target repositories:

borg list [email protected]:/var/backup/prod_repo

Executing a Full or Partial Extraction

In a recovery scenario, navigate to a clean staging directory. Avoid restoring files directly over active configuration zones unless intentionally performing a full system rollback. To extract a specific archive from the distributed node, run:

# Navigate to secure restore path
cd /mnt/recovery_zone

# Extract the specific archive locally
borg extract [email protected]:/var/backup/prod_repo::your-hostname-2026-05-27_020000

If you only require a specific directory or file, append the path relative to the archive root to the end of the extraction command. This granular restoration eliminates the need to download gigabytes of irrelevant data, drastically lowering recovery time objectives (RTO).

---

Conclusion: Unlocking Enterprise-Grade Resilience on a Budget

By leveraging open-source software and commoditized Linux VPS infrastructure, we have successfully architected a zero-trust, automated, highly distributed 3-2-1 backup cluster. Your infrastructure now benefits from data deduplication, military-grade end-to-end encryption, and geographical redundancy—features that normally demand premium enterprise software budgets.

As your operations expand, this setup effortlessly scales alongside them. Simply allocate additional storage blocks to your Linux VPS instances, update the source paths in your automation script, and continue operating with the peace of mind that your business infrastructure is thoroughly protected against catastrophic data loss.

Architecting an Automated, End-to-End Encrypted 3-2-1 Distributed Backup System with BorgBackup and Linux VPS | DPTCloud