Immutable Backup: Shielding Your VPS from Ransomware Using BorgBackup and Rclone Append-Only

The Escalating Threat of Ransomware on Virtual Private Servers

In the modern digital landscape, Virtual Private Servers (VPS) serve as the backbone for countless business operations, hosting everything from critical web applications to proprietary databases. However, this centralization of valuable corporate data makes VPS instances a prime target for cybercriminals. Among the myriad of digital threats, ransomware remains the most destructive. Traditional backup strategies are no longer sufficient; sophisticated modern malware specifically targets secondary storage and backup repositories to prevent organizations from restoring their infrastructure without paying a hefty ransom.

To counter this threat, modern enterprise security architectures are shifting toward a zero-trust backup model. The gold standard of this approach is Immutable Backup—a data preservation technique where backups, once written, cannot be modified, overwritten, or deleted for a predetermined retention period, even if an attacker gains root administrative access to the primary server. This guide provides a comprehensive, technical blueprint for implementing an absolute immutable backup pipeline on your VPS by combining two powerful open-source utilities: BorgBackup and Rclone configured in Append-Only mode.

Understanding the Architectural Components

Before diving into the technical deployment, it is vital to understand why the combination of BorgBackup and Rclone creates such an resilient defense mechanism against ransomware operations.

1. BorgBackup: Deduplication and Local Security

BorgBackup (commonly referred to as Borg) is a space-efficient, authenticated, and encrypted deduplicating backup program. Instead of copying entire files every time a backup runs, Borg analyzes data at the chunk level, only storing unique modifications. This drastically reduces storage consumption and bandwidth requirements. Crucially, Borg supports a native --append-only mode. When a local repository is initialized with this flag, older backup snapshots (archives) are structurally locked; new data can be added, but existing blocks cannot be altered or purged by local processes.

2. Rclone with Append-Only Cloud Storage

While Borg secures the data locally, a robust disaster recovery plan requires offsite replication. Rclone is a versatile command-line program used to manage and sync files to cloud object storage (such as AWS S3, Backblaze B2, or Wasabi). By leveraging cloud-side object locking or strict IAM policies alongside Rclone’s configuration, we can establish an offsite bucket that accepts new data uploads but categorically rejects requests to delete or modify historical objects. Even if a malicious actor gains full control of the primary VPS, they lack the cryptographic permissions to wipe the remote cloud backups.

Step-by-Step Implementation Guide

The following technical breakdown details how to initialize, configure, and automate this ransomware-proof pipeline on a standard Linux environment.

Step 1: Installing the Necessary Dependencies

First, update your package repository and install BorgBackup and Rclone. Most modern enterprise distributions include these in their default package managers.

# On Debian/Ubuntu systems
sudo apt update && sudo apt install borgbackup rclone -y

# On RHEL/Rocky Linux systems
sudo dnf install epel-release -y
sudo dnf install borgbackup rclone -y

Step 2: Initializing the Secure Borg Repository

We will set up a local directory dedicated to storing our Borg archives. For optimal protection against local manipulation, we initialize this repository with encryption and enforce the append-only restriction.

Choose a secure passphrase and store it safely in your password manager, or export it as an environment variable during automated scripts:

export BORG_PASSPHRASE="YourSuperSecurePassphraseHere"

Initialize the repository using the authenticated encryption mode:

borg init --encryption=repokey /var/backups/borg-repo

To restrict the repository to append-only mode locally, edit the Borg configuration file or enforce it through your backup script using the append-only environment flags, ensuring that accidental or malicious borg delete or borg prune commands are rejected by the binaries.

Step 3: Configuring the Cloud Destination via Rclone

Next, configure Rclone to connect to your remote cloud provider. Run the interactive setup tool:

rclone config

Follow the prompts to create a new remote (e.g., named remote-s3). To achieve true immutability, you should configure your cloud storage bucket with Object Lock enabled in compliance mode, or provision an IAM user API key that possesses only PutObject and ListBucket privileges, explicitly denying DeleteObject permissions.

Step 4: Creating the Backup and Sync Automation Script

To tie these components together smoothly, we use a shell script that executes the local deduplicated backup and securely pushes the changes to the immutable cloud storage layer.

Security Best Practice: Ensure this script is owned by the root user and restricted with restrictive file permissions (e.g., chmod 700) to prevent unauthorized users from viewing the repository passphrases.

Create a script at /usr/local/bin/immutable-backup.sh with the following content structure:

#!/bin/bash
# Set critical environment variables
export BORG_PASSPHRASE="YourSuperSecurePassphraseHere"
REPOSITORY="/var/backups/borg-repo"
ARCHIVE_NAME="vps-backup-$(date +'%Y-%m-%d-%H%M%S')"

echo "Starting local deduplicated backup via Borg..."
borg create --stats --progress $REPOSITORY::$ARCHIVE_NAME /var/www /etc /var/log

echo "Syncing repository to immutable cloud storage..."
# We use 'copy' instead of 'sync' to ensure remote files are never deleted
rclone copy $REPOSITORY remote-s3:your-immutable-bucket/borg-repo --immutable

echo "Backup routine successfully completed."

Verifying Immutability and Disaster Recovery

A backup strategy is only as good as its recovery path. To verify that your system is truly protected against ransomware, you must simulate an adversarial attack scenario.

Test Case 1: Local Deletion Attempt. Simulate a compromised root account attempting to erase historical snapshots using borg delete. Because of the append-only architecture, the metadata indices will block the operation or isolate the changes into a new append-only transaction log without dropping underlying blocks.
Test Case 2: Cloud Destruction Attempt. Attempt to manually delete objects from the Rclone remote bucket using the configured API keys. The cloud provider's Object Lock policy or restricted IAM rule will throw an Access Denied error, preserving your historical archives safely out of reach.

Restoring Data from the Immutable Store

If your VPS is completely compromised or encrypted by ransomware, provision a fresh, clean OS instance. Install Borg and Rclone, pull down the untouched repository from your cloud provider, and mount or extract the archive using your cryptographic passphrase:

# Download the repository from the cloud
rclone copy remote-s3:your-immutable-bucket/borg-repo /var/backups/borg-repo

# Mount the repository to inspect and restore files
mkdir /mnt/recovery
borg mount /var/backups/borg-repo /mnt/recovery

# Alternatively, extract a specific archive directly
borg extract /var/backups/borg-repo::vps-backup-2026-05-30-111802

Conclusion: Enterprise-Grade Peace of Mind

By blending the rapid, local deduplication capabilities of BorgBackup with the unalterable destination controls provided by Rclone and Append-Only cloud storage, you establish a multi-layered defensive wall. Your business gains the capability to withstand catastrophic infrastructure compromises without ever succumbing to extortion demands. Implement this setup today, automate it via systemd timers or cron jobs, and ensure your enterprise data remains resilient against evolving cyber threats.