So realistically speaking, is maybe a super low risk. The risk here would be if the main backup would fail at the exact same time than the second backup, so as to the exact same time as the main production environment fail as well. This virtual repo here is the second destination for off-site storage. The first backup destination is on a good performance iSCSI storage and it's all build in accordance to Veeam best practices. This virtual repository stored on a virtual VMFS is our SECOND backup destination, not the main one. 10666.html) about storing backup on a VM and I must admit that the bottom-line of this discussion is all about risk management. I also red the entire thread you provided ( vmware-vsphere-f24/don-t-store-backups.
In my understanding a "Backup Copy Job" from Veeam is a very simple block-copy job that doesn't requires much processing over the host & target so it should be only affected by network speed IMO? Isn't it? I really don't understand how it could be that slow. Everything over a 10 GBPS network link, all over the local LAN. so my 24 TB backup job copy should roughly take over 100 HOURS to complete. When launching my initial Backup Copy Job, I was very shocked to find a stable but VERY POOR 53 MB/s processing speed.
All VM's and server in the environment are all connected together using 10 GBPS network switch/links. The repository on this target server is a Ubuntu Linux VM with a single 35 TB repository on it.
Then I created a simple "Backup Copy Job" from this backup job onto a second repository, which is physically located on a second server (physical server) with an internal SAS RAID array (60 TB) also running latest ESXi 7.3. I created my initial (Full) backup job successfully on a QNAP Enterprise NAS connected over 10 GPBS iSCSi directly on the Veeam server VM and then take the full initial backup (24 TB size) in a stunning 40 hours at average 250 MB/s processing speed. I just recreated a fresh new Veeam B&R setup in my new production server environment.
0 kommentar(er)
