3-2-1 backup with immutable copies: ransomware protection step by step

What you will set up

Attackers who get into a network usually try to delete or encrypt the backups before they encrypt the servers. A backup that a stolen administrator account can delete is therefore not enough. This guide builds a layered setup with BackupZit: a primary backup on local storage, a copy in another place, and storage where backups cannot be destroyed before a set period ends, even with the storage credentials. BackupZit is free and open source (AGPLv3); everything below is part of the free product.

• The 3-2-1 rule
• 1. Primary storage
• 2. Immutable storage
• 3. Encryption
• 4. Job and retention
• 5. Off-site copy
• 6. Restore tests
• 7. Alerts and detection
• 8. Protect the console
• After an attack
• Limits

The 3-2-1 rule, and 3-2-1-1-0

The 3-2-1 rule: keep 3 copies of your data, on 2 different media, 1 of them off-site. The extension 3-2-1-1-0 adds 1 copy that is immutable or offline and 0 errors when the backups are verified. In BackupZit:

You need a BackupZit console with agents on the machines you protect; the guides for Proxmox VE, Hyper-V and Windows disk images show those first steps.

Step 1 — Primary storage for fast restores

In the console open Storage → Add storage target. For the first copy pick storage on the local network, so backups and restores run at full speed: an SMB share on a file server or NAS, or a Linux server or NAS over SFTP (its host key is pinned). Give the target its own account that can only write into the backup folder, and do not join the backup storage to the Windows domain.

When you save, the console tests the target right away — a wrong password, host key or share shows now, not at the first backup. Test connection in the storage list repeats the test.

Step 2 — Add immutable storage

BackupZit has two kinds of storage where backups cannot be deleted or overwritten before their period ends. Ideally it is off-site too, so one target covers both.

Option A: S3 with Object Lock

1. Create the bucket with Object Lock enabled — on AWS, Wasabi and Backblaze B2 an option when creating the bucket, on MinIO mc mb --with-lock.
2. Add a lifecycle rule that deletes noncurrent versions after one day (MinIO: mc ilm rule add --noncurrent-expire-days 1 --expire-delete-marker). Deleting a locked backup only adds a delete marker; the rule frees the space once the locks end.
3. In the console add a target of type S3 compatible (AWS, Wasabi, Backblaze B2, MinIO, …) with endpoint, bucket and an access key for that bucket.
4. Tick Immutable backups (S3 Object Lock, compliance mode) for … days (30 by default) and choose a period at least as long as the retention you want protected.

Every file the agents write is then locked in compliance mode for that period plus one day: nobody — not an attacker with the keys, not the bucket owner — can delete or overwrite it before then. Data that a new backup reuses from older ones gets its lock extended, so every restore point is protected for the full period. On immutable storage the connection test only signs in and lists, and it checks that the bucket really has Object Lock.

Option B: hardened repository on your own Linux server

A dedicated Linux server runs backupzit-repo (deb and rpm packages are attached to every GitHub release):

apt install ./backupzit-repo_*.deb       # or: dnf install ./backupzit-repo-*.rpm
vi /etc/backupzit-repo/repo.env          # BACKUPZIT_REPO_LOCK_DAYS=30
systemctl start backupzit-repo
backupzit-repo add-key office-console    # shows the access key once
backupzit-repo fingerprint               # certificate fingerprint

In the console add a target of type Hardened repository (backupzit-repo on Linux, immutable) with the server address (port 8500 by default), the access key and the fingerprint.

• Agents and the console can only add files; existing files are never overwritten.
• Every file gets the immutable attribute (chattr +i) for the period set on that server, plus one day. Not even root can delete it without removing the attribute first.
• Deletes from clients — retention, or an attacker with the access key — only hide files until their period ends.
• The period is set only on the repository server; the console and agents cannot change it.

After setup, disable SSH and other remote access on that server and protect its local console, iDRAC/iLO or hypervisor access: the protection is only as strong as its root account.

Step 3 — Encryption and the recovery key

Leave Encrypt backups (AES-256) on (the default). File contents, names, folder structure and snapshot lists are encrypted with AES-256-GCM before they leave the agent, and every change to the data is detected. Immutability stops deletion, encryption stops reading — you want both.

For each encrypted target the console shows a Recovery key and offers a recovery sheet. Keep it offline and separate from the backups: with the key, the storage location and its credentials you can restore even without the console; without the key, nobody can read the backups — including BackupZit support.

Step 4 — Backup job and retention

Create the job under Backup jobs with the primary storage from step 1. Under Keep backups set the newest N plus daily, weekly and monthly restore points — for example 3 recent, 7 daily, 4 weekly and 6 monthly keep about half a year with around 20 restore points. Deduplication stores unchanged data only once.

Recovery point objective (RPO), hours says how old the newest good backup may get, e.g. 26 for a daily job. A job that misses it is shown on the dashboard and reported, which also catches an agent offline for days or a schedule removed by mistake.

Step 5 — Off-site copy with a backup copy job

Create a second job and choose Backup copy. Under Copy the backups of select the job from step 4, and as Storage target the immutable or off-site target from step 2.

• The agent of the source job copies the existing backups; the protected machine is not read again.
• Only data not yet at the destination is sent, re-encrypted with the destination's key.
• After each backup of the source job (the default) keeps the copy current; a normal schedule works too, e.g. once a night for a slow line.
• The copy has its own retention, e.g. 7 daily on the NAS and 12 monthly in the cloud. Each restore point is locked for N days after it was created, so with a 30-day lock older monthly points are no longer protected; a longer lock keeps more of them, and more data.

File and VM backups (Proxmox VE, Hyper-V, VMware) are restored from the copy like from the original; copies of disk images with the command-line agent. Copy now starts a copy at once.

Step 6 — Restore tests and data checks

A backup is only proven when it has been restored. Under Settings → Restore tests:

• Test every job's newest backup automatically (weekly by default): a random sample of files from the newest backup is restored into a temporary folder, verified byte by byte against the stored checksums and deleted; for disk images, random blocks are verified. This exercises storage access, credentials, the key and the data.
• Check the stored data (monthly by default): every piece of data in each repository is read and verified, which finds a failing NAS disk or bit rot early. On S3 and Azure it runs only with Also on cloud storage (S3, Azure) on — it downloads everything, mind the download costs.
• Proxmox VM jobs can add a boot test that starts each VM from the backup with its network disconnected.

Test restore and Check data on a job's page start them at once. Results appear in Activity and Reports; a failed test sends an alert like any failure.

Step 7 — Alerts and ransomware detection

An off-site copy that has failed for weeks is no copy. Set up Settings → Email notifications (check with Send test email) and keep Failures on: one email per failed run with the reason — backups, copies, restores and restore tests — plus an optional daily report. Settings → Chat & webhooks sends the same to Slack, Microsoft Teams or any HTTP endpoint. On the dashboard, Needs attention lists failed jobs, missed schedules and RPOs, offline agents and storage that is 90 % full or will be full within 30 days.

Every backup is also compared with its job's recent history. It is marked suspicious when far more files changed than usual, new data no longer compresses (encrypted files look random), the number of files dropped by a third or more, or the amount of new data jumped. BackupZit then sends an alert, lists it under suspicious backups to review and pauses the job's retention (Retention is paused), so the last clean backups are not deleted even if damaged ones keep coming. After checking the machine, click Reviewed — resume retention.

Step 8 — Protect the console

Immutable storage protects the backups; the console still decides what is backed up and kept. Under Settings → Sign-in & security require two-factor authentication for administrators and turn on Four-eyes approval: deleting jobs or storage targets, shortening retention, resuming retention after a suspicious backup and turning the approval off then need a second user. Keep the console on the internal network, do not publish port 8443 to the internet, and use a VPN for remote administration. With Settings → Console backup the console also backs itself up every day to a network storage target.

After an attack

If backups were deleted or overwritten, read the storage as it was before — read-only, on S3 with Object Lock and on the hardened repository:

backupzit-agent snapshots --repo <repository> --as-of 2026-10-01T14:30
backupzit-agent restore   --repo <repository> --as-of 2026-10-01T14:30 --target D:\Restore latest

On a hardened repository the administrator can also bring hidden files back, so backups continue normally:

backupzit-repo status
backupzit-repo undelete --since 2026-10-01T14:00

Limits to know

• Immutability lasts only for the lock period. A deleted backup is really removed once its period ends, so choose the period with how long an attack might go unnoticed in mind.
• A hardened repository is only as safe as its root account and its console, iDRAC/iLO or hypervisor access.
• SMB, SFTP and local disks have no immutability of their own; combine them with an immutable or offline copy.
• Locked data takes space until its lock ends, even after deletion; without the lifecycle rule S3 space is not freed.
• Immutability does not clean data: files encrypted before the backup are backed up encrypted. Restore from a point before the attack — detection keeps those by pausing retention.
• Without the recovery key, encrypted backups cannot be read by anyone.
• Four-eyes approval covers the console; administrator groups in Active Directory or Entra ID must be protected there.

Next steps

Download BackupZit, see the ransomware protection features and all storage targets, or read the chapters Storage targets and Ransomware protection in the user guide in the console. How BackupZit itself is built and released is on the security page. Setting up the jobs is covered in the guides for Proxmox VE, Hyper-V, Microsoft 365 and Windows bare-metal restore. Questions are welcome in GitHub Discussions; companies can get commercial support from MaxZit.