Immutable Append-Only Backups with BorgBackup & Restic: Why Root Access Shouldn't Let Attackers Delete Backups

The Fatal Flaw in Standard Linux Backup Architecture

Every system administrator understands the textbook 3-2-1 backup rule: maintain three copies of data on two different media types with at least one offsite copy. Yet across modern enterprise ransomware incidents, victimized companies discover that their offsite backups were wiped hours before the primary database was encrypted.

The vulnerability lies in symmetrical administrative trust. When an automated backup script on a production Debian server connects to an offsite NFS share, S3 bucket, or SFTP server using root credentials that possess full write and delete permissions, that machine is an existential liability. The second an attacker or malicious insider obtains root privileges on the web server, they inspect /root/.bash_history or /etc/cron.daily/backup.sh, extract the remote storage API keys, and issue an immediate delete command.

SYMMETRIC BACKUP TRUST VS. IMMUTABLE APPEND-ONLY REPO

• VULNERABLE (SYMMETRIC ACCESS): [Production Server] → Root Attacker Obtains Credentials
• DELETE ALL HISTORICAL ARCHIVES
• Offsite Backup Storage: Storage Wiped (Company Ruined)
• SECURE (APPEND-ONLY ASYMMETRIC ENFORCEMENT): [Production Server] → Can PUSH New Blocks Only
• Attempts to Delete Historical Data?
• HTTP 403 / REJECTED
• Immutable Backup Repo: Historical Snapshots Untouched!

At Webxtek, we design backup topologies under the assumption that every production node will eventually experience a perimeter breach. By decoupling write access from deletion privileges through our technical consulting and managed hosting platforms, we guarantee uncompromised recovery capabilities.

Content-Defined Chunking: How Borg and Restic Deduplicate Terabytes

Traditional archival tools like tar and rsync operate on whole files or fixed-size blocks. If a 50GB PostgreSQL database has 2MB of rows updated near the beginning of its data file, whole-file backups must re-upload the entire 50GB.

Both BorgBackup and Restic solve this problem using Content-Defined Chunking (CDC) via Rabin-Karp or FastCDC rolling hashes. Files are segmented into dynamic chunks whose boundaries are determined by content rather than fixed offsets.

CONTENT-DEFINED CHUNKING (FASTCDC) IN ACTION

• FILE VERSION 1: [ Chunk A: 4MB ] [ Chunk B: 3.2MB ] [ Chunk C: 5.1MB ] [ Chunk D: 2.8MB ]
• FILE VERSION 2 (200KB Inserted Between Chunk B and C): [ Chunk A: 4MB ] [ Chunk B: 3.2MB ] [ Chunk E: 200KB ] [ Chunk C: 5.1MB ] [ Chunk D: 2.8MB ]
• (Already in Repo: NOT Re-uploaded!) (Already in Repo: NOT Re-uploaded!)

Only Chunk E (the newly inserted data) is compressed, encrypted client-side with authenticated AES-256 or ChaCha20-Poly1305, and transmitted across the network. A daily snapshot that previously required hours of bandwidth is completed in seconds, consuming negligible storage space.

Configuring BorgBackup in Append-Only Mode over SSH

BorgBackup includes native support for append-only repositories. By combining SSH forced commands in the backup server’s authorized_keys file with Borg’s --append-only switch, the production client is physically restricted from deleting archives.

On the dedicated backup target server, create an isolated user and configure /home/borgbackup/.ssh/authorized_keys:

command="borg serve --append-only --restrict-to-repository /var/backups/prod-repo",no-port-forwarding,no-X11-forwarding,no-pty,no-agent-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... client-backup-key

On the production server, initialize the repository and execute automated backups:

# Initialize encrypted Borg repository with Blake2 authenticated encryption
export BORG_PASSPHRASE="super-secure-production-passphrase"
export BORG_REPO="borgbackup@backup.internal:/var/backups/prod-repo"

borg init --encryption=repokey-blake2

# Create a new production snapshot
borg create --verbose --stats --progress \
  ::"prod-{now:%Y-%m-%d_%H:%M}" \
  /etc /var/www /var/lib/postgresql/data

BORG APPEND-ONLY INTEGRITY ENFORCEMENT

• Production Client (Root Attacker)
• Runs: borg delete ::prod-2026-10-18
• SSH Forced Command Wrapper (Backup Server)
• Intercepts Borg Protocol
• Detects Non-Append Operation on Append-Only Repo
• Logs Security Alert & Terminates SSH Connection: (Historical Archive Intact)

Pruning expired archives (e.g., keeping 7 daily, 4 weekly, and 12 monthly backups) is performed by an independent cron task running locally on the backup server itself—never from the production machine.

Restic REST Server: True HTTP-Level Immutability

For cloud-native deployments and multi-server fleets, Restic combined with restic-rest-server provides lightning-fast performance and clean append-only locks over TLS.

The Restic REST server binary (available on GitHub) features an explicit --append-only flag. When enabled, the HTTP server accepts POST requests to create new data blobs and index files, but immediately rejects DELETE or PUT calls attempting to modify existing objects.

# Launch restic-server with append-only security enforced
./restic-server --path /mnt/backup-vault --append-only --tls-cert cert.pem --tls-key key.pem

Configure your production nodes to back up directly to the REST endpoint:

# Set repository environment variables
export RESTIC_REPOSITORY="rest:https://backup-user:secret-pass@vault.internal:8000/"
export RESTIC_PASSWORD="encryption-key-for-chunks"

# Execute incremental snapshot
restic backup /var/www/vhosts /etc/nginx --exclude="*.log"

# Verify repository integrity without downloading full blobs
restic check

Even if an intruder executes restic forget --prune on the compromised production host, the server answers with HTTP 403 Access Denied. Your historical restore points remain completely untouchable.

Automated Recovery Testing and Cold Storage Tiering

A backup that has never been tested in a bare-metal disaster recovery simulation is merely an unverified hypothesis. Following security recommendations from OWASP, automated recovery drills should execute weekly in an ephemeral staging container:

# Mount the latest snapshot as a read-only FUSE filesystem for integrity validation
restic mount /mnt/restic-mount &
ls -la /mnt/restic-mount/snapshots/latest/var/www

To achieve ultimate air-gapped protection against coordinated insider sabotage, pair your append-only Borg or Restic cluster with automated offsite synchronization to tape media or cloud object locks with S3 Object Lock in Compliance Mode.

Investing in robust routine maintenance and immutable backup architecture ensures that when ransomware strikes, your downtime is measured in minutes, not bankrupting weeks.

In practice, we apply these exact architectural standards across specialized sectors including cloud computing & iaas providers and b2b cybersecurity & corporate intelligence. Whether you are modernizing core workflows through managed hosting for websites and apps and technical consulting before you build, connecting sector-specific requirements to disciplined execution is what turns technical theory into compounding commercial advantage.