Backup off site speed ISCSI

[N2IS]

Hello, I've come to ask for help here as a last hope.
I am facing a problem of slowness when saving my vm. My configuration is the following, Veeam BR is installed on a HyperV, I backup the machines contained on this HyperV to a Remote NAS. I have a site-to-site VPN between the NAS and the HyperV allowing me to connect the NAS iscsi drive directly to the HyperV. Backups of my data during full backups sometimes take more than 80 hours and sometimes fail, the speed is usually 2 or 3 MB/s.

Thank you in advance for your help,

[jorgedlcruz]

Hello,
As a rule of thumb, we would recommend in these scenarios to work with our Support Engineers, so please reach out to Support and share the Case ID here, so we can take a look and not duplicate efforts.

Backup from Site A to Site B would always be tricky depending on the speed, which you haven't specified.

If you are sending Backups to another Site for Security, my recommendation will be to purchase (if possible) a NAS for Site A, do a local Backup to that NAS, and then a Backup Copy to the second site. Hoping you can enable their Linux Immutability, or even TrueNAS with minIO or something similar so the second copy is immutable.

But as said, please open a support ticket.

[N2IS]

Hi, and thank you for your answer.

I can't open a case because i'm trying Veeam BR and juste have a trial license. I wish to buy a real license, but at least if Veeam can meet my needs.
So i don't know what to do...

[jorgedlcruz]

I see,
You can start opening a support case with a trial key as per our Policy. Veeam definitely helps, but without knowing the current speed between sites, etc. It is difficult to say, and still, an iSCSI presented over VPN to a server, would not be the best approach.

My recommendation after years of deployments, from very small to Enterprise ones. Start with at least another NAS on the local site, do a backup there, and use the NAS at the remote site for backup copies.

[Mildur]

Connecting iscsi to a backup repo server over VPN is definitely not recommended. What‘s your bandwidth between the two sites?

If you can‘t use FastClone, then for each synthetic fullbackup veeam requires to transfer blocks from previous backups from the remote nas to the backup repository server on the primary site, builds a new fullbackup, and then transfer the entire size back to the remote nas.
Same goes for healthcheck. The size of an entire fullbackup needs to be transferred over the VPN link to the repo server to run the healthcheck.

You can deploy a machine (windows or linux) on the remote site and connect the NAS to that machine. Add that machine as a repository server and the traffic will stay locally at the remote site for most of the tasks. Only incremental backup data will be send.
Or buy a linux hardware server with internal disks and use it as a linux hardened repository.

I had similar issues with my customers with a low bandwidth when I was working for a service provider. Solution was always to put a machine at the remote location to manage the backup storage locally.

[N2IS]

I see,
You can start opening a support case with a trial key as per our Policy. Veeam definitely helps, but without knowing the current speed between sites, etc. It is difficult to say, and still, an iSCSI presented over VPN to a server, would not be the best approach.

My recommendation after years of deployments, from very small to Enterprise ones. Start with at least another NAS on the local site, do a backup there, and use the NAS at the remote site for backup copies.

Well, i understand. I will try to summarize as well my infrastructure. I had a distant site, wich there is an HyperV whos backing locally into a NAS with Veeam BR and then i try to backup this HyperV to a distant site (me) into a NAS wich i connected to the HyperV with an ISCSI connection over a site-to-site VPN. So, how can i use both nas with Veeam to do the two backups task ?

[N2IS]

Connecting iscsi to a backup repo server over VPN is definitely not recommended. What‘s your bandwidth between the two sites?

If you can‘t use FastClone, then for each synthetic fullbackup veeam requires to transfer blocks from previous backups from the remote nas to the backup repository server on the primary site, builds a new fullbackup, and then transfer the entire size back to the remote nas.
Same goes for healthcheck. The size of an entire fullbackup needs to be transferred over the VPN link to the repo server to run the healthcheck.

You can deploy a machine (windows or linux) on the remote site and connect the NAS to that machine. Add that machine as a repository server and the traffic will stay locally at the remote site for most of the tasks. Only incremental backup data will be send.
Or buy a linux hardware server with internal disks and use it as a linux hardened repository.

I had similar issues with my customers with a low bandwidth when I was working for a service provider. Solution was always to put a machine at the remote location to manage the backup storage locally.

Bandwith is approximatly the same between both site wich is 100Mbs fiber. I see, when you say "most of the tasks" its like for the healthcheck or synthectic but the speed of the full backup to the "remote machine" will be slowly too ?

[Mildur]

If you are going to use a remote machine, the data send over the vpn connection from the proxy on the Hyper-V server to the remote machine depends on the used full backup type.
- An active full backup will transfer the size of the entire fullbackup to the remote machine.
- A synthetic full backup will only transfer incremental data to the remote machine. The remote machine will then use this data and the data already stored in the remote site to build a new synthetic full.

[N2IS]

Well i understand. But as first, if there is no data the first backup jobs will automatically be an active full and the we can continue with a synthetic full periodically. So my question is, that is the risk of not doing anymore active full after the first one ? What are your advice ?

Thanks,

[foggy]

Active fulls are not required provided you test your backups. Here's another good reading on a similar matter.