As part of an article series dedicated to the Wasabi cloud and how to leverage its object storage with Veeam Backup & Replication, this one covers the steps on how to configure a Wasabi Veeam job. The previous articles already discussed:
- creating a Wasabi account
- creating a Veeam Repository with Object storage with Wasabi
- extending a Scale Out Backup Repository (SOBR) to the cloud
In this instance the focus is on the actual Veeam Backup job which will automatically move data on the cloud tier. A good backup strategy includes the 3-2-1 rule: 3 copies of the data, stored on 2 different media, 1 should be offsite. In this case the offsite copy is in the cloud. Great thing is, Veeam allows to restore any file (with a granularity down to the item version) directly from the cloud. Even better Wasabi cloud doesn’t charge for egress fees nor for ingress. In addition, fully supports immutable storage. The 3-2-1 rule couldn’t be any easier and convenient than this combination!
A typical scenario could be where production data is protected on fast storage on-premises. Let’s say “tier-1” storage. A Backup Copy job then copies this data to a secondary location. Ideally a DR site and this could be the “tier-2” storage. What if data ages on the secondary location or outgrows capacity compared to current requirements? This is where the scalability and efficiency of the object storage comes into play showing the benefits of a virtually infinite storage. Veeam allows a seamless integration and management of the cloud storage when configuring a Veeam backup copy job.
How to configure a Wasabi Veeam job
The current wizard for the Backup Copy Job shows the main configuration steps. As per usual a name and a description for this particular job. Based on the frequency of backups it is also possible to adjust the polling time which Veeam Backup server will use to detect new or updated backup copy files.
Next is to select in the list of object the Backup jobs or VMs or Backup files that should be included in this configuration. In addition, the ability to add exclusions about specific VMs or virtual disks and even the option to select the source of data for the Backup Copy job: any repository or specific ones.
In the target section the Backup Repository is the one created in the previous article. At this point is possible to select the number of restore point (for a simple retention) and additionally enable the number of restore points as full backups for archival purposes (for advanced retention) or GrandFather-Father-Son scenario. As soon as these backup chains are sealed, these will be automatically moved to the Wasabi cloud based on Veeam SOBR configuration settings.
In the next section the ability to use a “direct” link to the storage or using the WAN Accelerator. For this instance a direct connection can be used as Veeam Backup Server already has the Wasabi S3 APIs to directly access the storage.
One more setting is the option to specify the time window when the Backup Copy job should run copying data to a DR site and then moving older or stale data to the cloud for longer retention.
A final screen to confirm the settings and enable the wasabi veeam job configuration.
From a Veeam perspective the job runs as per usual copying the data to the DR site or tier-2 location.
Based on Veeam SOBR retention policy, it is possible to see which backups are still on the tier-2 storage and which ones are already on tier-3 on the wasabi cloud.
Veeam provides full flexibility and should a backup and its increments be available on the tier-2 again, it’s a matter of selecting the pertinent one and choose the option “Copy to Performance tier”. Conversely for backup files available on tier-2 it is possible to move them to tier-3 in the wasabi cloud with the option “Copy to Capacity tier”.