How to Set Up Cloud Backup: 13 Steps, 90 Min [2026] – Tech Insider Ireland | #ransomware | #cybercrime

Most people who think they have a cloud backup actually have cloud sync. Dropbox, Google Drive and OneDrive copy files up as they change, which means a ransomware attack or an accidental mass-delete gets copied to the cloud just as fast as a new holiday photo does. Sophos found that 51% of US organisations surveyed for its State of Ransomware in the US 2025 report had been hit by ransomware in the previous year, and by 2026 the share of victims who leaned on backups to recover had climbed to 66%, up from 54% the year before, according to the State of Ransomware 2026 report. Backups only help if the copy sitting in the cloud can’t be reached, altered or deleted by whatever compromised the original.

This tutorial builds a cloud backup setup that solves that problem directly. It combines restic, client-side encrypted and deduplicated backup software, with rclone, the tool that talks to more than 70 cloud storage backends, to push encrypted, versioned snapshots to a destination of your choice. That destination might be Backblaze B2, Wasabi, or a cold-storage tier like AWS S3 Glacier Deep Archive. By the end you will have automated backups running on a schedule, a tested restore process, monitoring that alerts you when a job silently fails, and a second remote for genuine 3-2-1 redundancy. Total setup time runs about 90 minutes across 13 steps, most of it background time while the first backup uploads.

What You’ll Build

By the last step, a single scheduled job on your machine will run every night, encrypt a snapshot of the folders you choose, and push only the changed data blocks to a cloud bucket you control. A separate monitoring ping will tell you the moment that job stops running, rather than leaving you to discover a silent failure the day you actually need a restore. A second, independent cloud remote will hold a mirrored copy of every snapshot, so no single account, region, or API key failure can take out your only backup.

None of this requires enterprise software or a dedicated backup server. Everything here runs from two open-source command-line tools, a cron entry or systemd timer, and whichever cloud storage account you choose in Step 2. The full setup, including both the primary and secondary remotes, comes together in the single consolidated script published later in this guide.

How restic and rclone Work Together Under the Hood

It helps to understand what each tool is actually doing before typing commands into a terminal. restic is the backup engine. It reads your files, splits them into content-defined chunks, deduplicates those chunks against everything already in the repository, encrypts what’s left with AES-256, and writes the result as a new snapshot. rclone is the transport layer. It knows how to speak to more than 70 different storage APIs, from Backblaze B2 and Wasabi to Google Cloud Storage and Azure Blob, and it presents all of them to other programs through one consistent interface.

When restic is pointed at a rclone: repository path, it doesn’t call the cloud API directly. Instead it spawns rclone serve restic as a short-lived child process and the two exchange data over Restic’s own REST protocol through stdin and stdout, with no network port ever opened on the machine. That detail matters for anyone running this behind a restrictive firewall or on a machine with no inbound access at all, since nothing needs to listen for connections. It also explains why the same restic commands in this guide work unmodified against any backend rclone supports: restic never talks to Backblaze, Wasabi, or S3 directly, it only ever talks to rclone.

The practical upshot is a clean separation of concerns. If you switch cloud providers later, you reconfigure rclone and change one repository string, restic’s encryption, deduplication and snapshot history behave identically regardless of what sits underneath.

Why “Backup” and “Cloud Sync” Are Not the Same Thing

A sync tool watches a folder and mirrors every change to the cloud, and it does that job well. The trouble starts because sync has no real concept of history. Delete a file locally and most sync clients delete the cloud copy too, sometimes within seconds. Encrypt a folder with ransomware and the sync client dutifully uploads the encrypted version over the good one. A real backup tool keeps a chain of versioned snapshots instead, so last Tuesday’s clean copy still exists even after this morning’s disaster.

The industry shorthand for a resilient setup is the 3-2-1 rule: keep three copies of your data, on two different types of storage, with one copy off-site. A local NAS plus a synced cloud drive satisfies almost none of that, because the “off-site” copy shares the same live, mutable state as the original. restic and rclone get you closer to true 3-2-1 because every backup run creates a new, immutable snapshot layered on deduplicated data blocks, not a live mirror that an attacker can wipe in one pass.

There is also a cost dimension worth knowing before you commit. Sync services price around convenience, generous storage caps and per-user seats, while object storage aimed at backups prices around raw gigabytes moved and stored. That difference matters once you are backing up a home lab, a small studio’s project files, or a handful of servers rather than one laptop’s Documents folder. None of this means sync tools are useless, plenty of setups will keep using Dropbox for day-to-day collaboration. The point is narrower: don’t mistake that convenience layer for the safety net that survives a ransomware event, a mistyped delete command, or a locked account. That safety net is what the rest of this guide builds, one step at a time.

Prerequisites: What You Need Before You Start

Get these in place before Step 1. Version numbers below reflect the latest stable releases as of August 2026.

• restic v0.19.1 or later: the encrypted backup engine, confirmed via the official GitHub releases page
• rclone v1.75.0 or later: the cloud storage connector, confirmed via rclone.org
• A Linux or macOS machine: Ubuntu 22.04/24.04, Debian 12, or macOS 14 or later all work fine, and Windows users can run the same commands inside WSL2
• An account with at least one rclone-supported storage backend: Backblaze B2, Wasabi, AWS S3, Google Cloud Storage and roughly 70 others are supported out of the box
• GnuPG (gpg): used later to encrypt the rclone configuration file itself
• cron or systemd: most Linux distributions ship both by default
• sudo or root access: needed for the systemd timer and the RAM-disk mount step
• About 90 minutes: roughly 30 minutes of hands-on setup, plus background time for the first large backup to upload

Choosing a Cloud Backup Destination: Backblaze B2 vs Wasabi vs iDrive vs S3 Glacier

restic and rclone don’t care which cloud you pick, they just need an API endpoint and a set of credentials. That freedom means the choice comes down to price, egress policy, and how often you actually expect to restore data. The table below lines up four realistic cloud backup options for 2026.

Pricing sourced from Backblaze’s pricing page, the B2 Reserve page, Wasabi’s pricing page, iDrive’s pricing page, and AWS’s S3 Glacier pricing page.

Backblaze B2 is the default recommendation for most restic users because its pricing is simple and its documentation for the rclone and restic combination is mature. Wasabi’s flat per-TB rate with no egress fee suits anyone who expects to pull large restores back down periodically, since a full restore from B2 or S3 adds download charges on top of storage. iDrive packages its own client and dashboard, a reasonable trade if you would rather not touch a terminal at all, though it locks you into iDrive’s own backup format instead of the open restic repository format used in this guide. Glacier Deep Archive is the cheapest storage on this list by a wide margin, but retrieval takes hours and costs extra, which makes it a fit only for a secondary, rarely-touched copy rather than a primary backup you might need at short notice.

This guide uses Backblaze B2 for the primary examples, since its API works cleanly through rclone’s b2 backend, but every command below works the same against any other backend name.

Step 1: Install restic and rclone

restic is a robust backup solution for incremental, encrypted, mountable(!) backups to local and remote storage.

Cloudron docs contributor, documentation author (docs.cloudron.io)

Both tools ship as single static binaries, so installation is quick on any platform.

# Debian/Ubuntu
sudo apt update && sudo apt install restic

# macOS (Homebrew)
brew install restic

# Verify installation
restic version
# restic 0.19.1 compiled with go1.24.2 on linux/amd64

# Official install script (Linux/macOS)
curl https://rclone.org/install.sh | sudo bash

# Verify installation
rclone version
# rclone v1.75.0
# - os/version: ubuntu 24.04
# - os/kernel: 6.8.0-71-generic
# - go/version: go1.24.2

If restic version doesn’t report 0.19.1 or newer, grab the latest binary release straight from the GitHub releases page instead of relying on a distro package, since Ubuntu’s and Debian’s default repositories often lag several versions behind.

Step 2: Create a Cloud Storage Account and Generate API Keys

Sign up with your chosen provider (Backblaze B2’s free tier includes 10GB, enough to test this entire tutorial without paying anything) and create a private bucket dedicated to backups. Generate an application key scoped to just that bucket, with read, write and delete permissions, rather than reusing a master account key for everything. Keep the key ID and application key somewhere safe outside the machine you are backing up, ideally a password manager. You will paste them into rclone in the next step and nowhere else.

Pick the bucket’s region deliberately rather than accepting whatever default the signup flow suggests. Backblaze, Wasabi and AWS all offer EU-based regions, and choosing one keeps this decision simple later when GDPR data-residency questions come up for Irish and EU users, covered in more detail toward the end of this guide.

Step 3: Configure the rclone Remote

Run rclone config and walk through its interactive prompts once per backend.

rclone config

n) New remote
name> b2-backup
Storage> b2
account> 
key> 
hard_delete> true
y) Yes this is OK

# Confirm the remote can see your bucket
rclone lsd b2-backup:
#           -1 2026-08-01 09:14:22        -1 my-restic-repo

Answer hard_delete as true for B2 remotes, since restic manages its own retention policy and doesn’t need rclone’s default trash behaviour layered underneath it. Don’t move on until rclone lsd returns your bucket without an error.

Step 4: Initialize Your Encrypted restic Repository

Every restic repository is encrypted client-side with a password you choose. Set three environment variables once, then initialize the repository.

export RCLONE_CONFIG=/home/youruser/.config/rclone/rclone.conf
export RESTIC_REPOSITORY=rclone:b2-backup:my-restic-repo
export RESTIC_PASSWORD="use a long random passphrase here"

restic init --repository-version 2

# created restic repository a1b2c3d4e5 at rclone:b2-backup:my-restic-repo
#
# Please note that knowledge of your password is required to access
# the repository. Losing your password means that your data is
# irrecoverably lost.

If you forget it, your backups will be irretrievable and there is no reset process.

George Redinger, tutorial author (gist.github.com)

restic never transmits this password anywhere, which is exactly why nobody can recover it for you. Store it in a password manager or a physical safe immediately, not just in a terminal window you’ll close in ten minutes. The –repository-version 2 flag turns on compression, which typically shrinks storage and transfer costs for text-heavy and document-heavy backups.

Step 5: Run Your First Backup

Point restic at whatever directories matter most first.

restic backup /home/youruser/Documents /home/youruser/Projects --tag manual-first-run

# open repository
# repository a1b2c3d4 opened (version 2, compression level auto)
# scan [/home/youruser/Documents /home/youruser/Projects]
# scanned 4,812 files in 0:04
# [0:58] 100.00%  1.284 GiB / 1.284 GiB  4812 / 4812 items
# duration: 0:58
# snapshot 7f3e9a21 saved

The first run is the slow one, since restic has to read and upload every file. Subsequent runs only transfer changed data blocks, typically finishing in seconds to a few minutes depending on how much actually changed since the last snapshot. Check restic snapshots at any point to see the full list of saved snapshots and their IDs.

Step 6: Define What Gets Backed Up (and What Doesn’t)

Backing up node_modules folders, browser caches and virtual machine disk images wastes storage and egress budget without adding real safety. Create an exclude file once and reuse it on every run.

# ~/.config/restic/excludes.txt
node_modules/
.cache/
*.tmp
*.log
.DS_Store
Downloads/

# Use it on every backup from now on
restic backup /home/youruser --exclude-file=/home/youruser/.config/restic/excludes.txt

Revisit this list whenever a new noisy directory shows up in restic stats –mode raw-data, which breaks down exactly where your repository’s storage is going.

Step 7: Set a Retention and Pruning Policy

Without a retention policy, every backup run stays in the repository forever, which is safe but expensive. restic forget applies a policy, and pairing it with –prune actually reclaims the freed storage space afterward.

restic forget --keep-last 7 --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --keep-yearly 3 --prune

A reasonable starting policy keeps every daily snapshot for two weeks, weekly snapshots for two months, and monthly snapshots for a year. Adjust the numbers to match how far back you would realistically need to roll back, and how much storage cost you are comfortable carrying.

Step 8: Automate Backups With Cron or systemd Timers

Manual backups get skipped. Pick one scheduler and let it run daily without you.

# crontab -e
0 2 * * * /usr/local/bin/backup-wrapper.sh >> /var/log/restic-backup.log 2>&1

On modern distros, a systemd timer is the better choice: it logs to journalctl automatically and can catch up on a machine that was asleep at 2am, which plain cron cannot.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=restic backup to cloud

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-wrapper.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run restic backup daily at 02:00

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

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

Step 9: Harden the Setup by Encrypting the rclone Config Itself

The rclone.conf file holds plaintext API keys with full read, write and delete access to your backup bucket. Anyone who reads that file can read, or wipe, every backup you have made.

For restic to work, the rclone configuration file must not be encrypted.

Restic forum participant, community contributor (forum.restic.net)

That’s the catch: restic needs to read rclone.conf in plaintext at run time, so you can’t just leave it gpg-encrypted on disk permanently. The workaround, documented on the restic community forum, is to keep the encrypted file at rest and decrypt it into RAM only for the duration of each backup run.

Create USB-stick containing an encrypted rclone.conf and a shell script (let’s call it do.sh) to decrypt to RAM and perform the backup, containing all the restic calls needed

Restic forum participant, community contributor (forum.restic.net)

# Encrypt the config once, then delete the plaintext copy
gpg --symmetric --cipher-algo AES256 -o /root/rclone.conf.gpg /root/.config/rclone/rclone.conf
shred -u /root/.config/rclone/rclone.conf

#!/usr/bin/env bash
# backup-wrapper.sh
set -euo pipefail

RAMDISK=$(mktemp -d)
mount -t tmpfs -o size=4m,mode=0700 tmpfs "$RAMDISK"
trap 'umount "$RAMDISK"; rmdir "$RAMDISK"' EXIT

gpg --quiet --batch --passphrase-file /root/.backup-passphrase \
  -o "$RAMDISK/rclone.conf" -d /root/rclone.conf.gpg

export RCLONE_CONFIG="$RAMDISK/rclone.conf"
export RESTIC_REPOSITORY="rclone:b2-backup:my-restic-repo"
export RESTIC_PASSWORD_FILE="/root/.restic-passphrase"

restic backup /home /etc --exclude-file=/root/.config/restic/excludes.txt --tag automated
restic forget --keep-last 7 --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

This wrapper script is also the natural place to hang the monitoring ping from Step 11, which is exactly what the complete script later in this guide does.

Step 10: Verify Backup Integrity With restic check

A backup nobody has verified is a guess dressed up as a plan. restic check confirms the repository’s internal structure is intact without necessarily downloading every byte.

restic check --read-data-subset=10%

# using temporary cache in /tmp/restic-check-cache-812
# create exclusive lock for repository
# load indexes
# check all packs
# check snapshots, trees and blobs
# [0:12] 100.00%  312 / 312 snapshots
# no errors were found

Running the full data check, without the –read-data-subset flag, once a month is worth the egress cost on most plans, since it catches silent corruption before you actually need the data back.

Step 11: Add Monitoring and Failure Alerts

A cron job that fails silently is worse than no backup at all, because it creates false confidence. A dead-man’s-switch style ping service closes that gap cheaply.

restic backup /home /etc --exclude-file=/root/.config/restic/excludes.txt --tag automated \
  && curl -fsS -m 10 --retry 3 https://hc-ping.com/your-unique-check-id \
  || curl -fsS -m 10 --retry 3 https://hc-ping.com/your-unique-check-id/fail

A service like healthchecks.io sends an alert only when the expected ping doesn’t arrive on schedule. That means a crashed script, a full disk or a revoked API key all get flagged automatically, instead of discovered three months later during an actual emergency.

Step 12: Test a Full Restore (the Step Everyone Skips)

# Restore to a scratch directory, never on top of production data
restic restore latest --target /tmp/restore-test --tag automated

# Or restore a single file
restic restore latest --target /tmp/restore-test --include /home/youruser/Documents/contract.pdf
diff -r /tmp/restore-test/home/youruser/Documents /home/youruser/Documents

This is the step most setups skip entirely. A backup job that reports success every night for a year but has never actually been restored is a hypothesis, not a safety net. Put a recurring reminder in a calendar, quarterly at minimum, to restore a real file and confirm it opens correctly.

Step 13: Add a Second Remote for True 3-2-1 Redundancy

One remote, however solid, is still one point of failure: one account that can be suspended, one region that can go dark, one API key that can be revoked by mistake. A second, independent remote closes that gap.

# Add a second remote (e.g. Wasabi) with rclone config, then:
restic -r rclone:wasabi-backup:my-restic-repo-mirror init --repository-version 2
restic copy --from-repo rclone:b2-backup:my-restic-repo --repo rclone:wasabi-backup:my-restic-repo-mirror

restic copy re-encrypts snapshots with the destination repository’s own password, so a compromise of one repository’s password doesn’t automatically expose the other. For a genuinely resilient setup, this second remote is what turns “encrypted backup” into an actual 3-2-1 strategy rather than encrypted backup with one point of failure.

The Complete Backup Script: Putting It All Together

Every step above lives inside a single script below, ready to drop into cron or a systemd service. It decrypts the rclone config to RAM, runs the backup, applies retention, spot-checks integrity, and pings a monitor on success or failure.

#!/usr/bin/env bash
# cloud-backup.sh - full automated encrypted cloud backup run
set -euo pipefail

# --- config ---
BACKUP_PATHS=(/home /etc)
EXCLUDE_FILE=/root/.config/restic/excludes.txt
RCLONE_CONF_ENC=/root/rclone.conf.gpg
GPG_PASSPHRASE_FILE=/root/.backup-passphrase
RESTIC_REPOSITORY="rclone:b2-backup:my-restic-repo"
RESTIC_PASSWORD_FILE=/root/.restic-passphrase
HEALTHCHECK_URL="https://hc-ping.com/your-unique-check-id"

# --- decrypt rclone config to a RAM-only tmpfs ---
RAMDISK=$(mktemp -d)
mount -t tmpfs -o size=4m,mode=0700 tmpfs "$RAMDISK"
trap 'umount "$RAMDISK" && rmdir "$RAMDISK"' EXIT

gpg --quiet --batch --yes --passphrase-file "$GPG_PASSPHRASE_FILE" \
  -o "$RAMDISK/rclone.conf" -d "$RCLONE_CONF_ENC"

export RCLONE_CONFIG="$RAMDISK/rclone.conf"
export RESTIC_REPOSITORY
export RESTIC_PASSWORD_FILE

# --- run backup, retention, and an integrity spot-check ---
if restic backup "${BACKUP_PATHS[@]}" \
    --exclude-file="$EXCLUDE_FILE" \
    --tag automated \
    && restic forget --keep-last 7 --keep-daily 14 --keep-weekly 8 \
         --keep-monthly 12 --keep-yearly 3 --prune \
    && restic check --read-data-subset=5%
then
  curl -fsS -m 15 --retry 3 "$HEALTHCHECK_URL" >/dev/null
else
  curl -fsS -m 15 --retry 3 "$HEALTHCHECK_URL/fail" >/dev/null
  exit 1
fi

Save it as /usr/local/bin/backup-wrapper.sh, chmod +x it, and point either the cron entry or the systemd service from Step 8 at that path. That’s a complete, working, encrypted cloud backup pipeline in under 40 lines.

Common Pitfalls When Setting Up Cloud Backup

• Confusing cloud sync with cloud backup. Dropbox, OneDrive and Google Drive propagate deletions and ransomware-encrypted files to the cloud copy just as fast as they sync a new photo.
• No off-site copy of the restic password. If the only copy of the repository passphrase lives on the machine being backed up, one ransomware event or one dead disk takes out both the data and the ability to ever decrypt the backup.
• One remote, one account, one point of failure. A suspended provider account, a compromised API key, or a regional outage takes down the entire backup if there’s no second, independent remote.
• Never running a restore drill. A backup that reports success every night for a year but has never been restored is a guess, not a safety net.
• Retention set to –keep-last only. Without daily, weekly and monthly tiers, an attacker or a bad script with a two-week head start can quietly corrupt every recent snapshot before anyone notices.
• Leaving rclone.conf world-readable. That plaintext file holds live API keys, anyone who can read it can read, or delete, every backup it points to.
• Ignoring egress costs when planning a restore test. Pulling a multi-terabyte dataset back down from a provider that charges per gigabyte for downloads can cost more than a full year of storage, which is why the cost table later in this guide breaks out download pricing separately.

Troubleshooting: 8 Cloud Backup Errors and How to Fix Them

The cron-versus-manual mismatch is the single most common complaint on the restic and rclone forums, and it’s almost always the same root cause: a script that works fine in an interactive shell relies on environment variables or a PATH entry that cron’s minimal environment never sets. Hardcode full paths (/usr/bin/restic, not restic) inside any script triggered by cron or systemd.

Advanced Tips for Production-Grade Cloud Backup

In order to setup a secure backup solution that cannot be modified, restic can be used in combination with rclone to make use of its append-only feature run on a restricted remote system.

ArchWiki contributor, wiki contributor (wiki.archlinux.org)

• Turn on Object Lock at the bucket level (Backblaze B2 Object Lock or S3 Object Lock) so that even a compromised API key can’t delete or overwrite existing snapshots within the lock window, which directly blocks a ransomware actor from wiping backups before demanding payment.
• Restrict a remote to append-only using the pattern documented on the ArchWiki above, so a compromised backup host can add new snapshots but never delete old ones.
• Tag snapshots per host or dataset when several machines share one repository, so a forget/prune policy can target one machine’s snapshots without touching another’s.
• Add pre-backup hooks for databases (pg_dump or mysqldump) so backups capture a consistent export instead of a half-written database file mid-transaction.
• Throttle bandwidth during business hours with –limit-upload, and schedule the heavy initial seed backup overnight instead.
• Raise –read-concurrency on NVMe-backed hosts for faster backups, paired with ionice -c3 so backup I/O doesn’t compete with production workloads.

Cloud Backup, Ransomware and GDPR in 2026

The numbers below explain why an encrypted, off-site, tested backup has stopped being optional for anyone running a business.

Source: Sophos State of Ransomware in the US 2025 and Sophos State of Ransomware 2026. The backup-recovery rate climbing from 54% to 66% in a single year says less about ransomware getting weaker and more about organisations finally treating restore-tested backups as core infrastructure rather than an afterthought.

For Irish and EU businesses, there’s a compliance angle too. Backups containing personal data are still personal data under GDPR, so moving that data to a storage region outside the European Economic Area requires a valid transfer mechanism, typically an adequacy decision or Standard Contractual Clauses, as outlined by the European Data Protection Board’s guidance on international transfers. The practical fix is simpler than the legal reading: pick an EU-region bucket or endpoint (Backblaze offers an EU region, Wasabi has eu-central endpoints, and AWS’s eu-west-1 sits in Ireland) and the transfer-mechanism question mostly disappears.

Cost Estimate: What This Actually Costs Per Month

Storage vendors quote per-gigabyte rates that are hard to picture until they’re applied to a real dataset. The table below estimates monthly storage cost at Backblaze B2’s $0.005/GB/mo rate for three common dataset sizes, assuming restic’s deduplication and compression trim the raw size by roughly 20%, a conservative figure for a mix of documents, code and photos.

These figures cover storage only. Add a few cents a month for API transaction fees, and budget extra for the month you actually run a large restore, since download egress is where cloud backup bills usually surprise people. Wasabi’s flat $7.99/TB/mo rate with no egress charge can work out cheaper than B2 specifically for anyone who expects to run restore tests often, even though its headline storage price is higher.

Frequently Asked Questions

Is rclone alone enough for cloud backup, or do I need restic too?

rclone alone can sync or copy files to the cloud, but it doesn’t version snapshots or encrypt data client-side by default. restic adds encryption, deduplication and a proper snapshot history on top, which is what actually makes the result a backup rather than a mirror.

How much does this setup cost per month for a typical home or small-office dataset?

At Backblaze B2’s $0.005/GB/mo rate, backing up 500GB of deduplicated, compressed data runs around $2.50 a month for storage, plus a few cents in transaction fees. A second remote for full 3-2-1 redundancy roughly doubles that figure.

What encryption does restic use, and is it safe by default?

restic encrypts all data and metadata client-side with AES-256 before anything leaves your machine, using keys derived from the repository password. The cloud provider only ever sees encrypted blobs, never plaintext file contents or names.

Can ransomware reach cloud backups too?

Yes, if the credentials used to write backups also have delete permissions and those credentials live on the infected machine. Object Lock or an append-only remote, both covered in the advanced tips section above, close that specific gap.

How is this different from just using Backblaze’s or iDrive’s own backup app?

Packaged apps are easier to set up but lock your backups into that vendor’s proprietary format. A restic repository is an open format you can restore with any machine that has restic installed, against any of the roughly 70 backends rclone supports, without depending on one company’s app staying in business.

Do I need accounts with more than one cloud storage provider?

Not for a basic setup, one provider is enough to get encrypted, automated backups running. A second provider, as built in Step 13, is what upgrades the setup to genuine 3-2-1 redundancy rather than a single well-protected copy.

Is a restic-and-rclone setup GDPR-compliant for an Irish business?

The tooling itself is compliant since data is encrypted before it leaves your systems, but compliance also depends on where your chosen provider physically stores the data. Picking an EU-region bucket sidesteps most international-transfer questions entirely.

What happens if I lose the restic repository password?

The data becomes permanently unreadable. restic has no password reset or backdoor by design, since that’s exactly what keeps the encryption meaningful. Store the password in at least two separate places, such as a password manager and a printed copy in a safe.

Should I still keep a local backup as well as a cloud one?

Yes. The 3-2-1 rule calls for three copies on two different media, and a local restic repository on an external drive restores far faster than pulling everything back down over the internet, which matters when the goal is getting back to work quickly rather than only surviving a disaster.

Related Coverage