Backup copy to 3rd repository for GFS

[zadrian]

Currently I am using VBR 9.5u4 on 2 Veeam servers (HQ & Site-1).
- Veeam-HQ backup VMs to a Synology NAS (SSDs).
- In Site1, the ESXi servers uses SSDs and also another Synology NAS (SATA HDD) as backup repository.
- Veeam-Site1 is mainly a proxy and WAN Accelerator with no jobs.

Backup jobs (reverse increment) start at 10pm with backup copy interval daily at 11pm. Then the replication jobs are inserted as "scripts run after backup copy job" (source from Site-1 NAS to ESXi-site1). The replication job can take as long as 10 hours (weekdays) 35 hours (weekends) to complete. Mainly as I have Backup copy GFS (7 retention with 4 weekly, 2 monthly & 2 Quarterly on first Saturday).

The Replica(s) uses approx 2.2TB (On ESXi) while the backup copy uses 18TB.

Main bottleneck I believe is the transferring of data from NAS at site-1 to ESXi-site1 during the replication process especially when backup copy is running and worse if GFS is creating another full backup on Saturdays (which delays Sunday & Monday night jobs).

I have budget to increase the ESXi-site1 storage (not a lot, to max of approx 8TB storage using SSDs). So is there a way to use such that :
- ESXi-site1 can hold the replica(s) using approx 2.2TB & Veeam-Site1 with 5TB of "backup copy retention"
- NAS at Site-1 to hold only the GFS data

[ejenner]

Did you say your replication jobs kick off as a post-backup script file?

Maybe get rid of the script and make that process into a full Veeam job instead.

Then set where you want the files stored to make best use of the storage you have available.

[zadrian]

The replication jobs are a veeam job just that I used the command line (at job summary, you can see the command line), as recommended in another post, to use the job script so they can start once the backup job completes instead of a fixed schedule....which gets missed if the backup copy takes too long....esp on saturdays due to GFS (creating full backups on as per GFS).

[foggy]

You cannot store regular backup copy chain and GFS restore points on different repositories (if that is what you are after). What are the bottleneck stats for replication jobs?

[zadrian]

There are a few bottlenecks (kindly note that my replication jobs start after completion of backup copy), And I have like 5 huge VMs that maybe doing several tasks at same time (transfer, "backup copy tasks", GFS tasks, replication).
- Probably due to WAN accelerator, only 1 Backup copy transfer runs (it says WAN accelerator busy)....I do not really mind this as I have limited bandwidth.
- After the "backup copy" transfer completes, Backup copy will begin the "reverse increment" jobs while another VM's "backup copy" transfer starts (as mentioned above, it says WAN accelerator busy so only 1 transfer at a time).
- On Saturdays the "backup copy" GFS will create another synthetic full backup (2 copies of synthetic full) after the transfer from HQ-Site1 completes. This may take hours (NAS using SATA HDD).
- After the 2x synthetic full backup is created, replication starts (this may start even like 24-30 hours later) which reads from the NAS and creates to ESXi.

So the main bottleneck is on the NAS as 4 main jobs....
1 writing of Backup Copy data
2 creating 1st Backup copy synthetic full backup
3 creating the Backup copy GFS synthetic full backup
4 reading for the replication process.

So I thought if I can put step 1 & 2 using SSDs (on local ESXi via Veeam server as backup repository), it could speed things up a lot....then using the cheaper SATA NAS as GFS storage.