BorgBackup for Linux Servers

By Kokil Thapa | Last reviewed: September 2026

Production Linux servers fail in predictable ways. Disks die, packages break during upgrades, and a mistyped rm -rf can erase a live site in seconds. BorgBackup for Linux servers solves that with encrypted, deduplicated snapshots you can verify and restore quickly. I rely on Borg on Ubuntu hosts that run Linux system administration workloads for clients in Nepal and abroad. This guide walks through install, repository setup, automation, and recovery—the same pattern I use before touching production Laravel or WordPress deployments.

What is BorgBackup and why should Linux server admins use it?

BorgBackup is a free, open-source backup tool built for Unix-like systems. It chunks files, deduplicates identical data across archives, compresses the result, and encrypts everything at rest. That design cuts storage use sharply compared with naive full copies.

On a real client project running multiple legal-tech portals on one EC2 instance, daily tarballs consumed disk space within weeks. Switching to Borg dropped backup size because shared Blade templates and uploaded PDFs deduplicated across sites. The same pattern applies to Ubuntu server backup strategies for any multi-app host.

Borg fits servers that need point-in-time recovery without paying for enterprise backup appliances. It works on Ubuntu 22.04 and 24.04, Debian, Rocky Linux, and other distros with packages or pip installs. Pair it with off-site sync for a practical 3-2-1 approach described in our automated server backups complete setup article.

Key strengths for web hosts include incremental speed, integrity checks via authenticated encryption, and mountable archives through FUSE. Weaknesses matter too: Borg is file-level, not a block-level VM snapshot tool. Database consistency still needs logical dumps alongside file backups.

Core BorgBackup concepts

• Repository — a directory or remote path holding all archives and deduplicated chunks.
• Archive — a named snapshot created by borg create, such as web01-2026-09-12.
• Passphrase — unlocks encrypted repos; store it outside the server you back up.
• Prune — deletes old archives by retention rules without breaking deduplication.
• Compact — reclaims space after pruning removes unreferenced chunks.

How do you install BorgBackup on Ubuntu and Debian Linux servers?

Install Borg from your distribution package manager when possible. Pin a known version on production boxes so automation scripts do not break silently after an unattended upgrade.

Package install on Ubuntu 24.04

sudo apt update
sudo apt install -y borgbackup borgbackup-fuse
borg --version

Ubuntu 22.04 and Debian 12 ship Borg 1.2.x in their repos. That release line is stable for daily server backups. If you need a newer feature, use pip inside a virtualenv rather than mixing system Python packages blindly.

Optional pip install in a virtualenv

sudo apt install -y python3-venv python3-dev libssl-dev liblz4-dev libzstd-dev
python3 -m venv /opt/borg-venv
/opt/borg-venv/bin/pip install --upgrade pip borgbackup
ln -sf /opt/borg-venv/bin/borg /usr/local/bin/borg
borg --version

After install, confirm FUSE support if you plan to browse archives with borg mount. The borgbackup-fuse package on Debian-family systems provides the helper. On headless servers, FUSE is optional because borg extract handles most restores.

Before your first backup, read the official install notes at BorgBackup installation documentation. They list platform-specific dependencies that prevent cryptic compile errors on minimal cloud images.

How do you create and configure an encrypted BorgBackup repository?

Repository creation is a one-time step per backup destination. Choose encryption mode carefully. repokey-blake2 is the common default: the key material lives inside the repo, and your passphrase unlocks it.

Initialize a local repository

sudo mkdir -p /backup/borg-repos/web01
sudo chown root:root /backup/borg-repos/web01
sudo chmod 700 /backup/borg-repos/web01

export BORG_PASSPHRASE='use-a-long-random-passphrase'
export BORG_RSH='ssh -i /root/.ssh/backup_key'

sudo borg init --encryption=repokey-blake2 /backup/borg-repos/web01

Generate passphrases with a local tool like the password generator and store them in a password manager or sealed envelope. Never commit passphrases to Git. On sister sites I maintain with Deployer 7 and GitLab CI, backup credentials live in root-only env files outside the web root.

Create your first archive

export BORG_PASSPHRASE='use-a-long-random-passphrase'
export BORG_REPO='/backup/borg-repos/web01'

sudo borg create \
  --verbose \
  --stats \
  --compression lz4 \
  --exclude-caches \
  --exclude '/var/www/*/storage/logs/*' \
  --exclude '/var/www/*/node_modules' \
  --exclude '/tmp/*' \
  ::'{hostname}-{now:%Y-%m-%d-%H%M}' \
  /etc \
  /var/www \
  /home/deploy

The {hostname} and {now} placeholders expand at runtime. Exclusions matter on Laravel apps: skip node_modules, cache dirs, and session temp paths you can rebuild. Keep .env files backed up—they hold database credentials your restore depends on.

Remote repository over SSH

Off-site copies protect against datacenter loss or ransomware that encrypts local disks. Point Borg at a dedicated backup user on another VPS or NAS.

export BORG_REPO='ssh://borg@backup.example.com:22/~/repos/web01'
export BORG_RSH='ssh -i /root/.ssh/borg_backup -o StrictHostKeyChecking=accept-new'

borg init --encryption=repokey-blake2 $BORG_REPO
borg create --stats $BORG_REPO::'{hostname}-{now}' /var/www /etc

Harden the backup SSH account: key-only auth, no shell beyond borg serve, and firewall rules limiting source IPs. Our SSH hardening guide covers the same principles you should apply to backup traffic.

Prune and compact on a schedule

borg prune \
  --verbose \
  --list \
  --keep-daily=7 \
  --keep-weekly=4 \
  --keep-monthly=6 \
  $BORG_REPO

borg compact $BORG_REPO

Prune rules should match your recovery objectives. Seven dailies plus four weeklies gives roughly five weeks of granular rollback. Monthly archives stretch retention without unbounded disk growth. Run borg compact after prune on busy repos to reclaim chunk storage.

How do you automate BorgBackup with systemd timers on Linux?

Cron works, but systemd timers give you journald logs, dependency ordering, and failure notifications. I prefer timers on Ubuntu servers that already use systemd for PHP-FPM and queue workers.

Store secrets safely

sudo install -m 600 /dev/null /root/.borg-env
sudo nano /root/.borg-env

File contents:

BORG_PASSPHRASE=your-long-passphrase-here
BORG_REPO=/backup/borg-repos/web01
BORG_RSH=ssh -i /root/.ssh/borg_backup

Backup script at /usr/local/bin/borg-backup.sh

#!/bin/bash
set -euo pipefail
source /root/.borg-env

LOG_PREFIX="[borg-backup]"

echo "$LOG_PREFIX starting $(date -Is)"

borg create \
  --stats \
  --compression lz4 \
  --exclude-caches \
  ::'{hostname}-{now:%Y-%m-%d-%H%M}' \
  /etc /var/www /home/deploy

borg prune \
  --keep-daily=7 \
  --keep-weekly=4 \
  --keep-monthly=6

borg compact
borg check --verify-data

echo "$LOG_PREFIX finished $(date -Is)"

sudo chmod 750 /usr/local/bin/borg-backup.sh

Wire the script into systemd following our systemd service management guide. Create a service unit and a daily timer. Enable the timer with systemctl enable --now borg-backup.timer.

Database files need separate handling. MySQL and PostgreSQL must be dumped before Borg reads data directories, or you risk inconsistent pages on restore. Automate logical dumps first, then include the dump directory in your Borg path list. See automate database backups on Linux for mysqldump and pg_dump patterns that pair well with Borg.

Monitoring backup success

Check timer status weekly:

systemctl list-timers borg-backup.timer
journalctl -u borg-backup.service --since "7 days ago"

Integrate alerts with your existing stack. Netdata, Nagios, or a simple cron mail to root all work. A silent failed backup is worse than no backup—you assume protection that does not exist. Combine this with broader monitoring from our Netdata monitoring guide.

BorgBackup vs rsync: which backup approach fits Linux servers best?

Teams often compare Borg with rsync or rclone mirror jobs. Each tool solves a different layer of the backup problem. Borg excels at versioned, encrypted history. Rsync excels at live directory sync to a warm standby.

Many production setups use both. Borg holds encrypted history; rsync keeps a near-live copy on a secondary VPS. Our rsync vs rclone comparison covers transport details when off-site sync is the bottleneck.

For Nepal-based businesses on budget VPS plans, a second small instance in another region costs roughly Rs 1,500–3,000/month (~USD 11–22). That is cheap insurance compared with rebuilding a booking portal or law-firm client document store from scratch.

How do you restore files and full sites from BorgBackup archives?

Restores fail in production when nobody has practiced them. Schedule a monthly restore drill to a staging directory. Document the exact commands your team runs at 2 a.m. when the homepage is down.

List and inspect archives

source /root/.borg-env
borg list $BORG_REPO
borg list $BORG_REPO::web01-2026-09-11-0200 --short

Extract a single file

borg extract --verbose $BORG_REPO::web01-2026-09-11-0200 \
  var/www/example.com/.env

Borg recreates the path relative to your current working directory. Change into / or a temp folder before extracting to avoid cluttering the wrong location.

Mount an archive read-only with FUSE

mkdir -p /mnt/borg-mount
borg mount $BORG_REPO::web01-2026-09-11-0200 /mnt/borg-mount
ls /mnt/borg-mount/var/www/
borg umount /mnt/borg-mount

FUSE mounts are handy for comparing two versions or copying a handful of files. Unmount cleanly before running the next backup job.

Full site recovery outline

1. Provision a clean Ubuntu server using our Ubuntu server setup guide.
2. Install Borg and restore /etc, web roots, and home directories from the latest archive.
3. Restore database dumps from the same backup window—not live datadir copies.
4. Fix ownership: chown -R www-data:www-data /var/www/site per Linux file permissions conventions.
5. Reload PHP-FPM and verify TLS certs still match the hostname.
6. Run application smoke tests before switching DNS.

On legal-tech portals I have shipped, document uploads live under storage/app. Confirm Spatie Media Library paths restore completely before you announce recovery to the client. Partial restores erode trust faster than brief downtime.

Integrity verification

Run borg check --verify-data quarterly on repos that matter. It reads chunks and confirms checksums. The command takes time on large repos, so schedule it off-peak. Official guidance lives at BorgBackup quick start documentation.

What security and permission practices protect BorgBackup repositories?

Backups contain everything attackers want: database credentials, API keys, client documents, and TLS private keys. Treat repos as crown jewels.

• Restrict repo directories to root or a dedicated borg user with mode 700.
• Never store passphrases on the same volume as the only repo copy.
• Use separate SSH keys for backup traffic; rotate them yearly.
• Block backup server inbound SSH except from known production IPs.
• Align with broader hardening from Ubuntu web server hardening and server security in Nepal.

Ransomware actors hunt backup paths. Hide repo locations, disable web-served directories under /backup, and keep an off-site copy an attacker cannot reach from the compromised app user. Read the project security notes at borgbackup.org for encryption model details.

When clients need ongoing backup monitoring and restore support, that falls under support and maintenance services rather than a one-time install. Sites like Adventure Third Pole Trek depend on nightly data safety because bookings and supplier records cannot be recreated from memory.

Key Takeaways

• Initialize one encrypted Borg repo per server or logical site group, then schedule daily borg create with explicit exclusions.
• Pair file backups with logical database dumps so MySQL and PostgreSQL restore cleanly.
• Automate prune, compact, and check via systemd timers; alert on failure instead of assuming success.
• Keep a remote SSH repo in another region for true off-site recovery against disk or datacenter loss.
• Run a monthly test restore to staging and document commands before an emergency.
• Lock down repo permissions and passphrases—the backup is as sensitive as production itself.

People Also Ask

Does BorgBackup work with Laravel and WordPress file layouts?

Yes. Include /var/www, custom Nginx or Apache configs under /etc, and deployment user home dirs. Exclude cache, node_modules, and regenerable log files. Always back up .env and upload directories. WordPress sites on PHP 8.3+ hosts follow the same pattern with wp-content/uploads as a critical path.

Can BorgBackup run on low-memory VPS instances?

Borg runs fine on 1–2 GB RAM VPS plans common for small business sites in Nepal. Large first backups may spike CPU and I/O. Schedule jobs during off-peak hours. Enable lz4 compression for speed over maximum ratio on constrained boxes.

How much disk space do Borg archives consume?

Deduplication makes steady-state growth slower than raw data size. A site changing 200 MB daily might add far less after dedup. Monitor repo size with borg info. Plan headroom for retention windows and compact cycles.

Is BorgBackup enough for full disaster recovery?

Borg covers file-level recovery well. It does not replace infrastructure-as-code, DNS documentation, or database replication. Combine Borg with documented rebuild steps, secondary servers, and provider snapshots for complete coverage.

Build reliable backups before you need them

BorgBackup for Linux servers gives you encrypted history, efficient storage, and fast file-level recovery without proprietary agents. Install it early, automate prune and check, push archives off-site, and prove restores on a schedule. That is the difference between a bad afternoon and a lost business.

Need help designing backup strategy for a production Laravel stack, WooCommerce store, or multi-site EC2 host? Review our Linux administration services, browse the portfolio for deployed examples, or contact us to audit your current setup before the next outage finds the gaps.