Off-Site VPS Backups with restic and Borg: An Append-Only Setup, and What Replaced MinIO

If your servers and their only backup share one provider account, one stolen password or one fire can take both. Off-site VPS backups are copies of that data kept on another machine, in another city, under credentials the original servers never hold. With restic or BorgBackup, a second VPS can collect encrypted, deduplicated copies every night, and the setup takes about an hour. Knowing they will come back is harder, and only a restore can tell you. A backup you have never restored is a hope.

Bottom line first: keep three copies of your data, one of them in another city on a server the protected machines cannot delete from (the 3-2-1-1-0 rule). Use restic if any machine runs Windows or you want S3 storage, and Borg 1.4 if everything is Linux. Make the backup server append-only and clean it up from a login production never sees. Restore something every month, and rebuild a whole server every quarter with a stopwatch.

What is the 3-2-1-1-0 backup rule?

The 3-2-1-1-0 backup rule means keeping three copies of your data on two different types of storage, with one copy off-site and one copy offline or immutable, and confirming through test restores that the backups have zero errors. It extends the classic 3-2-1 rule to cover ransomware and backups that silently stopped working.

1. Three copies: the live data plus two backups. The original counts.
2. Two types of storage, so one kind of failure cannot reach every copy.
3. One copy off-site.
4. One copy offline or immutable: nothing on the network can change or delete it.
5. Zero errors when the backups are checked and restored.

Veeam added the last 1 and the 0 to the old rule. Below, one append-only backup server in another city is both the off-site and the immutable copy, and your host's backup of production is the third. CISA's #StopRansomware Guide says it in one line: keep offline, encrypted backups and test them regularly.

Five rules that matter more than the tool

1. Off-site means another building and other keys

In March 2021 a fire destroyed OVHcloud's SBG2 data centre in Strasbourg, and customers whose backups sat on the same site lost both. In May 2024 a provisioning error at Google Cloud deleted the private cloud of UniSuper, an Australian pension fund, in both of its regions; UniSuper recovered because it also kept backups with another provider. Same building or same account is not off-site.

2. The protected server must not be able to delete its backups

In a 2024 Sophos survey of 2,974 IT and cybersecurity professionals at organisations hit by ransomware, 94% said attackers tried to compromise their backups, and 57% of those attempts succeeded. Victims with compromised backups paid far more often: 67%, against 36%. Backups that survive do the work: in Sophos's State of Ransomware 2026, backups were how the data came back in 66% of cases where it had been encrypted, 12 points more than a year earlier. The 2026 Verizon Data Breach Investigations Report, published in May, found ransomware in 48% of all breaches, and about 96% of the ransomware victims whose size was known had fewer than 1,000 employees. The weak spot is usually a backup key that can also delete. The fix is append-only access: a client can add new backups but cannot delete or overwrite old ones.

3. Encrypt on the client, keep the password elsewhere

restic and Borg encrypt before data leaves the machine, so the backup server only holds ciphertext; under GDPR Article 34, a leak of properly encrypted data can even spare you from notifying every affected person. The catch is printed by restic itself: "Losing your password means that your data is irrecoverably lost". Keep the password in a password manager and on paper.

4. A mirror is not a backup

rsync and rclone sync make the copy match the source, so after ransomware the next run copies the encrypted files over the good ones. A backup keeps history: last night's version and last month's, side by side.

5. Restore something every month

Drives fail at a steady rate (Backblaze measured an annualized failure rate of 1.36% across 344,196 drives in 2025), and scripts fail more quietly. Neither shows up in a green "backup completed" line, only when you restore. GDPR Article 32 lists the ability to restore personal data in a timely manner, and regular testing of your safeguards, among the measures expected where the risk calls for them; Kosovo's data protection law (No. 06/L-082) follows the same model.

Restic vs Borg vs rsync and rclone: which backup tool should you use?

restic and Borg both use deduplication: they split files into chunks by content and store each unique chunk once, so the hundredth nightly backup adds only what changed.

Pick restic unless every machine runs Linux and you prefer SSH. It runs natively on Windows, macOS and Linux, and the current release is 0.19.1 from July 2026. restic 0.19.0, out in June, loads the index of a big repository much faster, has prune repack small pack files by default, and adds restore --ownership-by-name for restoring onto a machine whose user IDs differ. Its rough edges: no configuration file, so you write a systemd unit like the one below, and prune still locks the repository while it works.

Borg 1.4 (1.4.5 since July 2026) suits an all-Linux fleet with one SSH backup server. It also runs the daily backups of Nextcloud All-in-One, which can write to a remote Borg server like this one. Borg 2.0 is still beta: the 25th beta came out on 27 September 2026, the project still says betas are not for production, and 2.0 drops append-only mode for a no-delete permission, so the Borg setup further down is for 1.4.

rsync and rclone are supporting tools: rsync for a plain copy anyone can open, rclone for pulling OneDrive or Google Drive data onto your server so restic can version it. If rsync runs anywhere, update it. rsync 3.5.0, released on 13 August 2026, fixed 33 security issues, one of them a way out of the folder that rrsync locks a key into, and Debian 13 got it as a security update on 28 September. Give rrsync -no-overwrite too: when we tried it, -wo -no-del alone still let a client replace an existing file with new content.

Where the backups land, and what happened to MinIO

For restic, the best target is rest-server, a small HTTP server from the restic project. With --append-only it refuses every delete except lock files, and with --private-repos each login sees only its own repository. Plain SFTP works too, but then the key can delete, which breaks rule 2.

Tools that only speak S3 need an object store, and older tutorials say "install MinIO". Not any more. MinIO stripped the admin features out of its community edition's web console in May 2025 and stopped publishing binaries and Docker images in October 2025; the last community release fixed CVE-2025-62506, rated CVSS 8.1. Maintenance mode came in December, and on 12 February 2026 its GitHub README declared the repository no longer maintained, pointing users to AIStor, its proprietary product, which has a free single-node edition and a paid Enterprise edition. On 25 April 2026 the repository itself was archived and is now read-only. If you already run MinIO, a community fork renamed SILO in August 2026 still publishes AGPLv3 builds that keep MinIO's API and on-disk format; for a new backup target, look at the two below.

Garage is a single Rust binary that needs 1 GB of RAM and 16 GB of disk. Since version 2.3 in April 2026, garage server --single-node sets up a one-machine store in one go, but the documentation still warns against single-node production use, and its S3 compatibility page lists no versioning and no Object Lock (the S3 feature that refuses to delete or overwrite an object until its retention date passes). It has no TLS of its own either, so put it behind a reverse proxy with automatic SSL. SeaweedFS does offer Object Lock, but users have reported retention not being enforced in some versions: lock an object, try deleting that version, and trust it only if the delete fails. restic doesn't lean on Object Lock anyway, since it deletes its own lock files and prune removes data directly. For restic, immutability comes from an append-only server.

Why the backup server should be your own VPS

Hosted sync services decide your recycle-bin window for you. With off-site VPS backups on a server of your own, you set the retention and the host never sees unencrypted data. Your host's backup still matters, but it lives with the same provider and account: a fine second line for "put the server back as it was on Sunday", not an independent copy.

A backup server from RS Computers can sit in Amsterdam, Dublin or Prishtina. The plans page has the same plans and prices in all three cities. What matters for this job is disk and traffic. NVMe keeps prune and check short, and traffic is unmetered (1 Gb/s on VPS plans, 10 Gb/s on VDS plans), so pulling a whole repository back on a bad day never runs into a quota. When the repository outgrows the disk, upgrade the plan from the client area; it takes a short reboot on the same server. Our free weekly backup, restorable from the client area, covers the backup VPS too. Put that server in a different city from production; Amsterdam and Dublin make a natural pair.

How much disk does a backup server need?

Size by disk: what you back up after deduplication and compression, a year of changes, and free space for prune to work in. rest-server itself needs almost no memory. We gave one a 2 GB first backup of random, incompressible data on a test VDS of ours with 8 vCPUs and 16 GB of RAM, sent from a client on the same machine. It finished in about eight seconds, faster than a 1 Gb/s port could carry it, and rest-server never went above 23 MB of RAM. The restic client on the sending side peaked at about 360 MB.

Setting up off-site VPS backups with restic, step by step

New to the command line? Start with our guide to learning Linux on a lab VPS. Below, BACKUP_HOST is a DNS name pointing at a fresh Debian 13 backup VPS, BACKUP_IP its IPv4 address, and web1 the first client. Every step was tested on Debian 13, so use it for the backup VPS. Ubuntu 24.04 has no rest-server package (Ubuntu 26.04 LTS, out since April, has 0.14.0), and its restic 0.16.4 works as a client but lacks --stdin-from-command.

1. Install rest-server on the backup VPS

One apt command brings in rest-server, restic for later maintenance, the htpasswd tool and OpenSSL.

# as root, on the backup VPS
apt update
apt install -y restic-rest-server restic apache2-utils openssl
restic-rest-server --version

The last command should print a line starting restic-rest-server version restic-rest-server 0.13.0. The service stays idle until step 4 gives it a folder.

2. Storage folder and one login per machine

Next come a folder owned by the service's own user, a random password and the first login, web1.

# as root, on the backup VPS
install -d -m 0750 -o restic-rest-server -g restic-rest-server /srv/restic
openssl rand -hex 16
htpasswd -B /etc/restic-rest-server/users.htpasswd web1

Paste the 32-character string twice when asked, keep it for step 7, and look for Adding password for user web1. Never add -c here: it starts a new file and wipes every existing login.

3. TLS certificate

Without TLS the logins travel in clear text, so make a self-signed certificate, valid for ten years, that covers both the name and the IP.

# as root, on the backup VPS
cd /etc/restic-rest-server
openssl req -newkey rsa:2048 -nodes -x509 -days 3650 -subj "/CN=BACKUP_HOST" -keyout private_key -out public_key -addext "subjectAltName = DNS:BACKUP_HOST,IP:BACKUP_IP"
chown root:restic-rest-server private_key public_key
chmod 0640 private_key
chmod 0644 public_key
ls -l

ls -l should show private_key as -rw-r----- with the group restic-rest-server.

4. Configure rest-server

Debian's settings file gets replaced by three lines: port, folder and options.

# as root, on the backup VPS
cat > /etc/default/restic-rest-server <<'EOF'
LISTEN=:8000
BACKUP_DIR=/srv/restic
ARGS="--htpasswd-file /etc/restic-rest-server/users.htpasswd --append-only --private-repos --tls --tls-cert /etc/restic-rest-server/public_key --tls-key /etc/restic-rest-server/private_key"
EOF
cat /etc/default/restic-rest-server

The last command prints the three lines back. --private-repos keeps the web1 login inside /srv/restic/web1.

5. Firewall first, then start

Open SSH, let port 8000 in only from your client's IP, and only then start rest-server and read its log.

# as root, on the backup VPS
apt install -y ufw
ufw allow 22/tcp
ufw allow from CLIENT_IP to any port 8000 proto tcp
ufw --force enable
systemctl enable restic-rest-server
systemctl restart restic-rest-server
systemctl status restic-rest-server --no-pager
journalctl -u restic-rest-server -n 20 --no-pager

Repeat the ufw allow from line per client; for laptops without a fixed address, use ufw allow 8000/tcp. The status should say active (running) and the log should mention Data directory: /srv/restic and TLS enabled. If the status says inactive (dead) (Result: exec-condition) instead, BACKUP_DIR is not set: check step 4.

6. Prepare the client

First print the server's certificate so you can copy it.

# as root, on the backup VPS
cat /etc/restic-rest-server/public_key

Copy everything from the BEGIN CERTIFICATE line to the END CERTIFICATE line. Then switch to web1: install restic, create the repository password, print it, and open an empty certificate file.

# as root, on web1
apt install -y restic openssl
install -d -m 0700 /etc/restic
(umask 077; openssl rand -base64 32 > /etc/restic/password)
cat /etc/restic/password
nano /etc/restic/rest-server.crt

Store the printed password in your password manager and on paper first. Then paste the certificate into nano and save with Ctrl+O, Enter, Ctrl+X.

7. Create the repository

Replace BACKUP_HOST and WEB1_PASSWORD before you paste. The block writes the settings file that both you and systemd read, then creates the repository.

# as root, on web1
install -m 0600 /dev/null /etc/restic/env
cat > /etc/restic/env <<'EOF'
RESTIC_REPOSITORY=rest:https://BACKUP_HOST:8000/web1/
RESTIC_PASSWORD_FILE=/etc/restic/password
RESTIC_REST_USERNAME=web1
RESTIC_REST_PASSWORD=WEB1_PASSWORD
RESTIC_CACERT=/etc/restic/rest-server.crt
RESTIC_CACHE_DIR=/var/cache/restic
EOF
set -a; . /etc/restic/env; set +a
restic init

You should see created restic repository and the password warning. If you see x509: certificate signed by unknown authority, RESTIC_CACERT does not point at the certificate from step 6; cannot parse root certificate means it was pasted incompletely, and certificate is valid for ..., not ... means the URL uses a name the certificate does not cover. Fix that instead of using --insecure-tls. 401 Unauthorized means the login or its password is wrong.

8. First backup, then the database

The first run covers the usual folders (drop /var/www if there are no websites), then lists the result and checks the repository.

# as root, on web1
set -a; . /etc/restic/env; set +a
restic backup --one-file-system --exclude-caches /etc /home /root /var/www
restic snapshots
restic check

Look for snapshot ... saved (restic's word for one backup run) and, from check, no errors were found. A folder that does not exist shows up as /var/www does not exist, skipping. Debian's restic 0.18.0 then exits with 0, but restic 0.19 and newer save the backup and exit with code 3, which systemd counts as a failed night, so list only folders you really have.

Databases need a dump, not their raw files. restic 0.17 and later runs the dump itself and saves nothing if it fails, unlike piping into --stdin. The example saves a MariaDB or MySQL database called shop, the kind a WooCommerce or PrestaShop store runs on.

# as root, on web1
set -a; . /etc/restic/env; set +a
restic backup --stdin-filename shop.sql --stdin-from-command -- mysqldump --single-transaction shop

restic snapshots now lists a second snapshot holding shop.sql. For PostgreSQL, put runuser -u postgres -- pg_dump shop after the --; our PostgreSQL, MySQL and Redis guide covers the databases themselves.

9. Schedule it with a systemd timer

Two small unit files do the scheduling: a one-shot service that runs the backup, and a timer that starts it around 02:30 each night, with a random delay so clients don't all arrive at once.

# as root, on web1
cat > /etc/systemd/system/restic-backup.service <<'EOF'
[Unit]
Description=restic backup to the backup VPS
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
CacheDirectory=restic
ExecStart=/usr/bin/restic backup --one-file-system --exclude-caches /etc /home /root /var/www
Nice=10
IOSchedulingClass=idle
EOF
cat > /etc/systemd/system/restic-backup.timer <<'EOF'
[Unit]
Description=Nightly restic backup

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

[Install]
WantedBy=timers.target
EOF
systemctl daemon-reload
systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

list-timers shows the next run. Persistent=true makes a machine that was off at 02:30 catch up after boot. To include the dump, add the step 8 command as a second ExecStart= line, starting with /usr/bin/restic. To test it without waiting for the night, start the service by hand:

# as root, on web1
systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager

Near the end, the journal should show snapshot ... saved and then Finished restic-backup.service. If it says unable to locate cache directory, /etc/restic/env is missing its RESTIC_CACHE_DIR line; the backup still runs, only slower, without restic's cache.

Office PCs and laptops: backing up Windows to your own server

Picture a small architecture studio with eight Windows PCs. Drawings and Outlook mailboxes stay open all day, and one bad attachment can encrypt the shared drive. Give each PC its own login (step 2); append-only means an infected PC cannot erase anyone's history. winget, Microsoft's package manager, ships with Windows 10 and 11 and the latest Windows Server, and the same steps fit a Windows VPS you use over Remote Desktop. Open PowerShell as administrator and install restic with it:

# as the Administrator user, in PowerShell
winget install --exact --id restic.restic --scope Machine

In a new administrator window, restic version should report 0.19.1 or newer. The next block makes C:\restic, readable only by administrators and the system account, puts a random repository password in it, prints the password and opens Notepad for the certificate.

# as the Administrator user, in PowerShell
New-Item -ItemType Directory -Path C:\restic
icacls C:\restic /inheritance:r /grant:r "*S-1-5-32-544:(OI)(CI)F" "*S-1-5-18:(OI)(CI)F"
$b = New-Object byte[] 32; [Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($b)
[Convert]::ToBase64String($b) | Set-Content C:\restic\password.txt
Get-Content C:\restic\password.txt
notepad C:\restic\rest-server.crt

icacls should report Successfully processed 1 files. Store the printed password like the one for web1, paste the certificate from step 6 into Notepad (answer Yes if it offers to create the file) and save. On an older Windows Server without winget, download the Windows zip from restic's GitHub releases page, save the .exe inside it as C:\restic\restic.exe and type that full path wherever the commands below say restic. Then create the repository and take the first backup.

# as the Administrator user, in PowerShell
$env:RESTIC_REPOSITORY = "rest:https://BACKUP_HOST:8000/office-pc1/"
$env:RESTIC_PASSWORD_FILE = "C:\restic\password.txt"
$env:RESTIC_REST_USERNAME = "office-pc1"
$env:RESTIC_REST_PASSWORD = "OFFICE_PC1_PASSWORD"
$env:RESTIC_CACERT = "C:\restic\rest-server.crt"
restic init
restic backup --use-fs-snapshot C:\Users

--use-fs-snapshot uses Volume Shadow Copy, so open files are read consistently. To automate it, save these lines without restic init as C:\restic\backup.ps1 and run powershell.exe -ExecutionPolicy Bypass -File C:\restic\backup.ps1 daily from Task Scheduler with "Run with highest privileges" and, for laptops, "Run task as soon as possible after a scheduled start is missed". Macs use brew install restic; Linux laptops reuse steps 6 to 9.

Retention with restic forget and prune: who may delete

Append-only clients cannot clean up, so someone else must. forget drops snapshots by policy and prune deletes the data nothing references any more, locking the repository while it runs. Use plain --keep-within here. restic's documentation warns that an attacker who can only add can plant fake snapshots dated just after your real ones, so any rule that keeps one snapshot per day, week or month (--keep-daily 7, and the --keep-within-daily family too) keeps the fakes and drops the real backups. --keep-within keeps everything inside its window, real and fake. Run this monthly on the backup VPS as the service's user, never as root, and type the repository password when asked so it is never stored there.

# as root, on the backup VPS (restic itself runs as the restic-rest-server user)
runuser -u restic-rest-server -- restic -r /srv/restic/web1 --cache-dir /var/tmp/restic-admin forget --keep-within 1y --prune
runuser -u restic-rest-server -- restic -r /srv/restic/web1 --cache-dir /var/tmp/restic-admin check

Add --dry-run to the first line to preview it. The rule keeps every snapshot from the year before the newest one and removes anything older; with nightly backups that is about 365 snapshots, and deduplication means each one only costs what changed that day. check should end with no errors were found. If you see repository is already locked, a backup is probably still running; let it finish.

Borg's append-only mode, set with command="borg serve --append-only --restrict-to-path /srv/borg/web1",restrict in front of the client's key in authorized_keys, has a sharper trap. Deletes sent by a compromised client are only marked and can be rolled back, until anything writes to the repository with full rights, whether a prune, a delete, a compact or even a new backup from an admin machine; then they are permanent. Read the transaction log and run borg check --verify-data before any maintenance.

The monthly restore drill

The drill is a short script. It restores a file from the newest snapshot, compares it with the original, reads back a twelfth of the stored data and times the lot.

# as root, on web1
cat > /usr/local/sbin/restic-drill <<'EOF'
#!/bin/sh
set -eu
set -a; . /etc/restic/env; set +a
start=$(date +%s)
dir=$(mktemp -d /var/tmp/restore-drill.XXXXXX)
restic snapshots --latest 1
restic restore latest --path /etc --target "$dir" --include /etc/hostname
diff /etc/hostname "$dir/etc/hostname"
restic check --read-data-subset="$(date +%-m)/12"
rm -rf "$dir"
echo "RESTORE_OK in $(( $(date +%s) - start )) seconds"
EOF
chmod 0700 /usr/local/sbin/restic-drill
restic-drill

If the newest snapshot is not from last night, your timer is broken and you found out cheaply. Any error stops the script; success ends with RESTORE_OK in and the seconds taken. --path /etc makes the restore use the newest file backup, not a database dump saved after it. The subset follows the month number, so every byte in the repository is read back once a year; plain restic check only looks at structure. Then restore one document on each Windows PC, run the retention commands above, and note the date and timing in a log kept off the servers.

Once a quarter: rebuild from nothing

On a scratch machine, set up /etc/restic with the password from your password manager, not from the old server. Restore into /srv/restore, put the files in place, import the dump and click through the site. The time from "server gone" to "site works" is your recovery time objective (RTO); the age of the newest snapshot is your recovery point objective (RPO), the work you would lose. Write both numbers in the drill log; next quarter you will see whether they improved.

Who notices a failed night, and who backs up the backup server?

restic exits non-zero on any problem, including code 3 (snapshot saved, some files unreadable), and systemd marks the run as failed. Nobody reads that unless it goes somewhere you will see it, ideally a dead man's switch that alerts when no successful backup has arrived for 26 hours; our guide to monitoring with Uptime Kuma and Grafana helps here. The backup VPS needs updates like any other server: run apt update && apt upgrade, then systemctl restart restic-rest-server. Debian 13 keeps restic at 0.18.0 with security fixes only. As for the backup's own backup, the free weekly backup of the whole server covers the repository, and a copy of /etc/default/restic-rest-server and /etc/restic-rest-server/ kept off that server lets you rebuild the service with the same logins and the certificate the clients already trust.

What append-only does not protect against

Append-only stops a compromised client. It does nothing against someone who gets root on the backup VPS itself, so lock that machine down too.

• Log in with SSH keys only, and share none of them with the servers it protects. Our Debian 13 image ships with root password logins switched on, so turn them off once your key works; week 2 of our Linux lab guide shows how. Password guessing starts within minutes of a new server going online, and this server holds the history of every machine you back up.
• Keep TLS on and one login per machine with --private-repos.
• Ports published by Docker bypass ufw, so bind containers to 127.0.0.1; our Docker on a VPS guide shows how in a Compose file.
• Keep Garage's ports 3901 and 3903 closed; start SeaweedFS's weed mini with -ip.bind=127.0.0.1.

Frequently asked questions

Should I use restic or Borg?

restic if any machine runs Windows or you want S3-compatible storage; Borg 1.4 if everything is Linux and you are happy with SSH. Speed rarely decides it, because on a VPS the network is usually the limit.

Is rsync a backup tool or just a sync tool?

On its own, a sync tool: deletions and encrypted files reach the copy on the next run. Hard-linked daily copies with --link-dest add history, but not encryption or deduplication, so use it for a plain second copy beside a real backup.

Is MinIO still free and open source?

The code is still AGPLv3, but official binaries and Docker images stopped in October 2025, the repository was marked as no longer maintained on 12 February 2026, and it was archived read-only on 25 April 2026. For a new self-hosted S3 target, test Garage or SeaweedFS instead.

Are my hosting provider's backups enough?

No, and that includes ours. A provider's backup sits with the same provider and account, so it covers mistakes on the server better than a stolen account or a site-wide disaster. Keep the free weekly backup RS Computers includes with every VPS as the second line behind your own append-only copy in another city.

How often should I test restoring a backup?

Monthly for a file and part of the repository, quarterly for a whole server, and again after every change to the backup setup.

Can RS Computers set up the backup server and the first clients?

Yes. Message us on Telegram or email info@rscomputers-ks.com with how many machines you want to protect and roughly how much data they hold, and we will suggest a plan and quote the setup.

Start with the server you would hate to rebuild

Don't protect everything on day one. Order a small VPS on our VPS and VDS plans page in a city where your servers are not, and protect the one server you could least rebuild from memory. Run restic-drill the same evening, put the password on paper, and add the next machine next week. A month from now, run the drill again and compare the seconds.

← All articles