A working 3-2-1 backup setup with Veeam | Antyxsoft Cloud

This is the configuration we recommend to customers running Veeam against our object storage: three copies, two media, one offsite, one immutable, zero errors on test restore. It is deliberately unexciting. Backup infrastructure should be the least creative part of your estate.

The shape of it

Local repository on fast disk for operational restores. Capacity tier in S3-compatible object storage for offsite, with object lock enabled. Backups copy to the capacity tier immediately and stay on local disk until it fills.

That gives you the fast path for the common case — someone deleted a VM, restore it in minutes from local disk — and the durable path for the case that matters, where the site or the environment is gone.

Local repository

Give the local repository dedicated spindles or volumes, not a share on the production array. A backup repository on the same storage as the thing it protects satisfies the "three copies" rule and none of its intent.

Two settings that matter here:

• Per-machine backup files — on. Restores read one chain instead of a shared file, and retention processing is far less painful.
• Limit concurrent tasks — set it to roughly the number of CPU cores available to the proxy. Unlimited is how a backup window turns into a production incident.

Object storage as the capacity tier

Add the bucket as an S3-compatible object storage repository, then attach it as the capacity extent of a scale-out backup repository.

Endpoint:    https://s3.eu-central.antyxsoft.cloud
Region:      eu-central
Bucket:      backups-prod
Folder:      veeam/site-a
Immutability: enabled, 30 days

Use a dedicated access key with write and list permissions on that bucket only. Not the key your applications use, and not one stored anywhere a compromised production host can read. The value of the offsite copy is entirely determined by how hard it is to delete from inside the environment being protected.

On the scale-out repository, enable Copy mode rather than only Move. Copy puts the restore point in object storage as soon as it is created; move waits until the local file ages out. If the site burns down at 04:00, copy mode means last night's backup is already safe.

Immutability and retention arithmetic

This is where most configurations quietly go wrong. Immutability locks a block for a fixed period; retention wants to delete blocks on a schedule. If the immutability window is longer than the retention period, blocks pile up and you pay for storage you thought you had released.

The rule: immutability period ≤ retention period, and leave headroom. With 30 restore points on daily backups you have roughly 30 days of retention, so a 21 to 25 day immutability window is comfortable. Thirty days of immutability against thirty days of retention will drift into permanent growth the first time a job runs late.

Also budget for the block generation behaviour: with immutability, Veeam extends the lock on blocks still referenced by newer restore points, so the effective footprint is larger than a naive sum of the daily deltas. Plan for 1.3 to 1.5 times the number a spreadsheet suggests.

Job configuration

Backup mode:        Incremental with synthetic fulls
Synthetic full:     Saturday
Retention:          30 restore points
GFS:                4 weekly, 12 monthly, 3 yearly
Compression:        Optimal
Storage optim.:     Local target (1 MB blocks)
Encryption:         enabled, key in your password manager
Health check:       monthly
Guest processing:   enabled, application-aware

Application-aware processing is not optional for anything with a database. Without it you are backing up a running data directory, which restores into recovery mode and sometimes into corruption. With it, Veeam quiesces the database and truncates logs properly.

On encryption: store the password somewhere that survives the loss of the Veeam server, and test that you can decrypt with it. An encrypted backup whose key lived only in the destroyed environment is an expensive collection of random bytes.

The one setting people forget

Enable the periodic health check on the job. It reads the backup files back and verifies checksums, which is how you find silent corruption before a restore does. It costs IO one night a month.

Pair it with SureBackup if you have the capacity to run it: it boots the backed-up machines in an isolated network and runs verification tests against them. This is the only mechanism in the stack that actually proves the restore works rather than proving the file is readable.

Verifying the whole thing

Quarterly, run a restore that nobody has rehearsed for, and time it end to end:

1. Pick a real production VM at random.
2. Restore it from the object storage tier, not local disk — that is the path you will use in the real incident.
3. Bring it up in an isolated network.
4. Log in, run a query, confirm the data matches the restore point.
5. Write down the elapsed time.

That last number is your real RTO for that system. If it disagrees with the one in your DR document, the document is wrong.

What this costs

For a typical 5 TB estate with 30 days of daily retention and GFS on top, expect somewhere around 8 to 12 TB in the capacity tier after compression and dedupe, depending on change rate. The local tier holds whatever fits — a week is plenty.

Restores from object storage are reads; check how your provider prices them. Ours does not charge for restore traffic, which is the entire point of keeping the offsite copy somewhere that does not bill you for needing it.