Adding a cloud repository to Veeam Backup & Replication is a ten-minute task. Getting the first full copy of a multi-terabyte estate through your uplink without anyone noticing takes a little planning — and that planning is the whole job.
The pattern you want is a backup copy job reading from your existing on-premises repository, not a second primary backup job pointed at the cloud. Two reasons: your production workloads are only touched once, and the copy job maintains its own retention chain offsite, which is what the third leg of 3-2-1 actually requires.
Local restores keep coming from local disk at local speed. The cloud copy is there for the day the building, the array or the domain is the problem.
Work out the real number before you start: total protected data, minus what compression and deduplication will remove, over the bandwidth you are actually willing to give the job. A 3 TiB estate on a 200 Mbps window is roughly four nights of transfer — fine if you planned for it, alarming if you did not.
Two levers make that number smaller. Scope the first job to the workloads that genuinely need offsite protection rather than everything at once, and check whether seeding is available for very large first fulls. Subsequent runs move only incremental changes, which is usually a small fraction of the first.
Set a bandwidth rule with a schedule: full rate overnight and at weekends, a modest cap during business hours. Veeam's traffic rules apply per source-target pair, so the copy job can be limited without touching local backup performance.
Enable WAN acceleration if you have it licensed and the change rate justifies the cache. If not, the combination of compression and incremental-forever is usually enough for a nightly copy of a normal estate.
Turn on job-level encryption and store the password somewhere that survives the site — a password in a vault on the server you are protecting is not a plan. Use credentials for the cloud repository that exist nowhere else in your environment, so a compromise of the production domain does not hand over the offsite copy.
The gateway connection is initiated outbound from your side, so there is no inbound rule to open and no backup infrastructure exposed to the internet.
Decide the offsite chain separately from the local one. Local retention is optimised for fast recent restores; offsite retention is optimised for surviving a long-dwell attack and for whatever the auditor asks for. A common shape is a short local chain plus weekly, monthly and yearly GFS points in the cloud, with an immutability window at least as long as the shortest GFS interval.
When the first full completes, do three things. Check the chain reports as healthy and complete. Run a restore from the cloud copy — one file and one whole VM — and time both. Then enable recovery verification on a schedule so this is checked without anyone remembering to.
Only after a successful restore from the offsite copy is the third leg of 3-2-1 real. Until then it is a transfer that finished.
Antyxsoft provides the Veeam cloud repository — encrypted transport, throttling, GFS retention and per-job immutability in EU data centres — as a target your existing Veeam console can add today: see how Veeam backup and DRaaS works.