In this instance, I’ve selected 28 restore points to keep on disk, this will enable us to meet our 4-week imaginary retention requirement. We selected the Veeam backup repository that we created earlier followed by defining the number of restore points that we require. We add the VMs that we want to protect into the backup job. To get started, We create a new Veeam backup job and named it appropriately. We can use synthetic or active fulls here, though I’d just use active full for keeping it simple. Ideally, when designing our backup job, to minimise bandwidth, we should configure a forward incremental backup job with a retention period sufficient enough to meet our requirements while minimising the number of active fulls created. Meaning lots of new files that would need to be synced, this is something we are trying to avoid.īy avoiding unnecessary full backup files it will help us minimise our storage bill and importantly ease congestion on the WAN link. With a backup job, we would need to consider that reverse incremental should not be used, leveraging reverse incremental would result in a new full backup file being created each time the backup runs, it also creates a new reverse incremental file for the previous restore point.
With the above in mind, we need to decide whether we should configure backup job (primary backup target) or a backup copy job (secondary backup target).
This is in contrast to other solutions such as Microsoft StorSimple which leverages a ‘volume-container’ global block-level dedupe which means even if Veeam sends multiple full backups files to a backup repository, the StorSimple will only upload changed/unique blocks due to its block-level dedupe capability. Both Synology CloudSync and Backblaze B2 offer no data deduplication, meaning if we create several full Veeam backups files to our Synology CloudSync backup repository, each Veeam full backup file will be uploaded, in full.
0 kommentar(er)
