Offsite backup for a homelab: the third copy

A backup in the fireproof safe next to the server is a lovely idea, right up to the day the whole room is the problem. The third copy belongs somewhere else, and "somewhere else" has more options than most guides admit.

The short answer

An offsite copy is a copy that does not share the building, the power line or the login of your original [17]. For a homelab you have four realistic routes: a second site of your own, a rented storage box you reach over SFTP, S3-compatible object storage, or a consumer cloud drive reached through rclone. Pick by five criteria: the protocol your backup tool speaks, encryption before upload, the cost of storing and of restoring, protection against deletion, and how long the first upload takes. Our assessment: with restic or Borg, a storage box or an S3 bucket is the simplest fit. "Unlimited computer backup" products are built for desktops and are not the tool for a server or a NAS [8][9].

How it works

1. What "offsite" has to mean. The German BSI baseline for backup concepts says that backup media must be kept physically apart from the systems they protect, and should be in a different fire compartment [17]. The same document says that mirroring data through RAID does not count as a backup, because the mirror changes at the same moment as the original and cannot protect against overwriting or malware [17]. If you use online storage, it lists what to settle in the contract: where the data is stored, service levels, authentication, encryption on the storage and on the way there [17]. This guide builds on the 3-2-1 rule from our backup basics page. Here we only decide where the "1" goes.
2. Encrypt before the data leaves the house. restic encrypts everything it stores with AES-256 in counter mode and authenticates it with Poly1305-AES, and derives the keys from your password with scrypt [16]. That happens on your machine, so the provider only ever sees ciphertext. The same applies to Borg, which our restic-or-Borg guide covers. For tools without built-in encryption, rclone's crypt remote wraps any other remote and encrypts content (NaCl SecretBox) and, by default, file names [13]. The consequence is easy to miss: if the tool encrypts, you do not need a provider's "zero-knowledge" add-on. pCloud, for example, sells its client-side encryption as a separate, separately priced product next to the storage plans [10]. The flip side is the key. restic states that a lost password means irrecoverably lost data [14], and rclone's crypt needs its password and configuration [13]. Store them apart from the repository and apart from the machine you are backing up.
3. Target type 1: a second site of your own. There are four kinds of target, and each trades effort against cost and control. This one means a relative's flat, an office or a friend's garage. restic can write to a directory over SFTP, or to a REST server you run there [14]. You pay no storage fee, but you own the disk, the power, the router and the upload line at both ends. It also needs someone to plug the box back in after a power cut.
4. Target type 2: a storage box over SSH. Hetzner's Storage Box is one example. Its product page lists SFTP, SCP, rsync, BorgBackup, restic, rclone, WebDAV and SMB, unlimited traffic, snapshots, a choice of Germany or Finland as location, no minimum contract and immediate cancellation [1]. Hetzner's own documentation says restic works natively over SFTP and also through its rclone backend, and names Borg versions 1.1, 1.2 and 1.4 [3]. Two details matter. The disks sit in a RAID array on a single host server, and the data is not mirrored onto other servers [1][2]. That suits a third copy and is thin as your only copy. Snapshots are stored on the box and use up its capacity [2].
5. Target type 3: S3-compatible object storage. Backblaze B2 is one example. restic documents any S3-compatible service through s3:https://server:port/bucket and recommends B2's S3 interface over its native B2 backend [14]. B2 keeps old file versions "hidden" by default, so restic's documentation suggests the lifecycle rule "Keep only the last version of the file" to free the space [14]. B2 also offers Object Lock, which stops files being changed or deleted for 1 to 3,000 days. Once you enable it on a bucket, you cannot switch it off again [6]. Backblaze warns that with backup software you should set the retention in the software and not as a bucket default, because the combination can lead to unpredictable data loss [7].
6. Target type 4: a consumer cloud drive. pCloud is one example. rclone supports it through an OAuth token and notes that deleted files go to the trash for a time that depends on your subscription [12]. restic can use any rclone remote [14]. pCloud lists subscriptions and one-time lifetime plans [11]. We found no pCloud documentation that describes server backups with restic. The combination rests on rclone's backend, which makes it workable for small data sets and a weaker choice for a repository you must restore under pressure.
7. Computer-backup products are a different category. Backblaze Computer Backup does not back up network drives, shares or NAS devices, and says so in its documentation [8]. It also lists Linux, BSD and Unix as unsupported, as well as Windows Server of any variety [9]. For a NAS, Backblaze points to B2, with built-in options for Synology, QNAP and TrueNAS [8]. A note on money, as the criteria come first: if the site ever links to a partner program for Backblaze, the commission applies to Computer Backup only, not to B2 and not to NAS backups. It does not change this assessment.
8. Costs scale with data volume, and so does the restore. Use this formula: monthly cost = stored terabytes × price per terabyte + restore traffic + extras. Examples with the prices on the providers' pages on 24 Oct 2026 are in the table below the list. The figures are list prices, not offers. Hetzner's prices exclude VAT [1], the B2 rate on that page is for the US West region [5], and the two currencies are not converted here. A restore of 1 TB from 1 TB stored stays inside B2's free allowance. Egress beyond that allowance costs $0.01 per GB, roughly $10 per extra terabyte [5]. pCloud's plans differ too much to reduce to one line, so check its current price page [11]. In every case, add the price of a test restore to your budget (step 10).
9. The first upload is the real bill. Upload time = data volume ÷ upload speed. One terabyte is 8 × 10¹² bits. At an assumed 50 Mbit/s of upstream that takes 44 hours at full line rate, and real transfers are slower. Plan for days, not minutes. Throttle the job so it does not choke your other traffic: rclone-based restic setups accept a bandwidth limit through the RCLONE_BWLIMIT variable [14]. If the line is too slow, seed the first copy at the second site, or start with the data you cannot recreate.
10. Test the restore, then test it on the offsite copy. restic check verifies the structure of a repository. --read-data reads every pack file and therefore downloads the whole repository, which can cost bandwidth and time. --read-data-subset checks a part per run, for example 10% or 1/5 [15]. A passing check shows the repository is intact. It does not show that you can restore what you need. Restore into an empty directory on a second machine with only the password you stored separately, and write down how long it took.

Prices on the providers' pages, 24 Oct 2026 (the same figures as in step 8):

A homelab example

This is how a setup could look. It is an example, not a report on our systems, and we make no statement about which backup target we use. Assume a local restic repository at /mnt/backup/restic-lokal and a Hetzner Storage Box with a sub-account for backups.

First, an SSH alias in ~/.ssh/config. The Storage Box accepts SFTP on port 22 and, once SSH support is enabled, on port 23. From outside Hetzner's network, such as your home line, you also have to enable "External Reachability" in the same settings dialog [3]. Hetzner's community tutorial for restic uses port 23 and an OpenSSH-format key [3][4]:

Host offsite-box
  Hostname u123456.your-storagebox.de
  Port 23
  User u123456
  IdentityFile ~/.ssh/restic_offsite
  ServerAliveInterval 60
  ServerAliveCountMax 240

Then create the remote repository with the same chunker settings as the local one and copy the snapshots over. restic needs the password of both repositories [15]:

restic -r sftp:offsite-box:./restic-offsite init --from-repo /mnt/backup/restic-lokal --copy-chunker-params
restic -r sftp:offsite-box:./restic-offsite copy --from-repo /mnt/backup/restic-lokal

For an S3 bucket the same idea looks like this. The endpoint and bucket name come from your provider's console, and restic expects path-style URLs for non-Amazon services [14]:

export AWS_ACCESS_KEY_ID=<key-id>
export AWS_SECRET_ACCESS_KEY=<secret>
restic -r s3:https://<s3-endpoint-of-your-bucket>/<bucket> init

Check part of the offsite repository after every copy, and run one full restore test per quarter:

restic -r sftp:offsite-box:./restic-offsite check --read-data-subset=5%
restic -r sftp:offsite-box:./restic-offsite restore latest --target /tmp/restore-offsite

Where does the free alternative fit? For a restic or Borg user in Germany with a few terabytes, a storage box has a flat price, no traffic charges and an SFTP target that both tools support natively [1][3]. We see no reason to push you towards a provider with a partner program when the one without fits better. B2 fits when you need an S3 interface, Object Lock or a NAS app that speaks S3. A cloud drive like pCloud fits when you already pay for it and keep the data set small.

Checklist

• Decide what must survive a fire in the house, and list those directories first.
• Check that the offsite target is in another building and on another login than the original.
• Confirm that your backup tool encrypts before upload, or add rclone crypt in front of the remote.
• Store the repository password, and any rclone password, apart from the repository and apart from the backed-up host.
• Compare targets by price per terabyte, restore traffic, minimum contract and snapshot or lock features, using the provider's own page and its date.
• Calculate the first upload with your real upstream speed, and throttle the job.
• Turn on a lifecycle or retention rule only after you have read how it interacts with your backup software.
• Run check with --read-data-subset after every copy, and a full restore on a second machine every quarter.
• Write down date, duration and result of each restore test.