• EN
Solved

Veeam Backup and Replication + Synology (File System)

NemanjaJanicic
Userlevel 7
Badge +1

Hello Veeam community,

Is there any best practices when implementing these two into work?

Currently we have it setup as a SMB share folders and Veeam is sending backups to it.
I did a little bit of research and saw that people are using ISCSI and connecting Synology drive to Windows Server and using it like that. As I can see they are using ReFS File System.

What would be the best optimization when we have Veeam + Synology in our Environment.
Veeam B&R and our main Synology are located in the same location within same subnet.

After that main Backup is done we have a Backup Copy Job trough IPSec to our Branch Office where we also have Synology NAS with SMB share.


With ISCSI I saw that people are using FastClone and I’m not familiar with it at all. What is the use of it?


Any advices are welcomed 😀

icon

Best answer by coolsport00 16 August 2023, 13:59

View original

12 comments

K
Badge

Hi! 

In general, SMB is not something we recommend, using iSCSI or NFS gives better results. FastClone is a Windows feature(also available with Linux on xfs), which allows us to create “spaceless” synthetic full backup, resulting in capacity savings and can be achieved with iSCSI. So iSCSI brings 2 advantages here: capacity savings and more reliable backups.

 

NemanjaJanicic
Userlevel 7
Badge +1

Hi @Kira,

Can you please inform me what are the disadvantages if any with using iSCSI directly connected to Veeam B&R. 
My concern is what is the case when our Veeam B&R Server goes down what happens with our backups that are located on that iSCSI mounted drive?

Another question is what would be the best case for Backup-Copy Job.
Currently we are using WAN Accelerator in High Bandwith mode and sending it via IPSec to Synology SMB Shares.

Thank you for your reply 

coolsport00
Userlevel 7
Badge +17

@NemanjaJanicic - where you really see advantages of FastClone is for synthetic operations, as Kira mentioned. It essentially uses pointers to source data so synthetic operations (Synth Fulls, Forever Fwd merge operations, etc) are super fast to complete, as opposed to several mins to hrs. XFS in Linux is similar to ReFS, but is more mature.

For your BUC job, you have about the best setup you can. You have a WAN accelerator, and you’re using High Bandwidth Mode. Both are the best Veeam can offer. The only bottlenecks would be first and foremost your WAN connection (network/Internet) speed to your Copy site, and Accelerator CPU/RAM resources.

As far as iSCSI...are you using your Synology directly connected to your VBR server? If possible, I recommend using a separate server, physical if you can but a VM works too, as your Repo; you didn’t explicitly mention, but also a separate Proxy server. If you do connect your Repo directly to VBR and you lose your VBR, no worries. You hopefully create config backups (directed to some other storage off your VBR server I hope?). What you can then do is create a new VBR server, restore from configs, then point your iSCSI Repo/Storage to your new/rebuilt server to get your backups back.

Shane Williford - Veeam VMCA/VMCE | Veeam Legend | VUG Leader | VCP-DCV | Twitter: @coolsport00
coolsport00
Userlevel 7
Badge +17

You can read more about FastClone with Veeam here. It’s also known as Block Cloning via Microsoft. They discuss it as well here. Hopefully those resources help you out.

Shane Williford - Veeam VMCA/VMCE | Veeam Legend | VUG Leader | VCP-DCV | Twitter: @coolsport00
NemanjaJanicic
Userlevel 7
Badge +1

Hello @coolsport00 😃

Synology is not connected directly to the VBR server. It’s connected trough network. They are located on the same subnet and also in the same location at main office.

At the moment for testing I created an iSCSI LUN on Synology, Add it to the VBR via iSCSI initiator and format it as ReFS. So best option would be to create a separate VM / Physical server and assign the LUN via iSCSI to it and then Add that Server as Backup Repository to VBR?

 


For the Proxy settings I didn’t configure anything, don’t know if there is need to optimize this also?

 

coolsport00
Userlevel 7
Badge +17

“So best option would be to create a separate VM / Physical server and assign the LUN via iSCSI to it and then Add that Server as Backup Repository to VBR?”

Yep; that’s how I’d do it.

As far as Proxy….yes, it would also be better to offload your data moving processes off the VBR server as well. If no physical server available, a simple VM or 2 for hotadd operation is sufficient. I can achieve up to 1GB read speeds at times with hotadd. You can review here and here on the value of separate Proxies.

Shane Williford - Veeam VMCA/VMCE | Veeam Legend | VUG Leader | VCP-DCV | Twitter: @coolsport00
NemanjaJanicic
Userlevel 7
Badge +1

Thank you for this explanations and help. 
I will go trough documentation and test backups with implementing 1 / 2 Backup Proxies for the source and remote sites.


Proxies works on a similar base as WAN Accelerators?
We need to have source and destination WAN Accelerators as it should be for the proxies.



 

NemanjaJanicic
Userlevel 7
Badge +1

@coolsport00  
Can you please give me more details on how to propper configure Proxies for mine situation at the moment.

Proxy would be needed for backups that are on the same site?
I need to add a server as an off-host proxy and then add that proxy to the Backup Job that I created?

Also What I need to do with Gateway Servers on the Backup Repositories.
All those stuff are little bit confusing to me.
Do I need Proxy and Gateway Server combine or

coolsport00
Userlevel 7
Badge +17

@NemanjaJanicic - are you using HyperV or VMware?

Shane Williford - Veeam VMCA/VMCE | Veeam Legend | VUG Leader | VCP-DCV | Twitter: @coolsport00
NemanjaJanicic
Userlevel 7
Badge +1

@coolsport00 We are using Hyper-V.

Two sites with Synology.
One is Located where VBR is and one is trough IPSEC to other location.

coolsport00
Userlevel 7
Badge +17

Ah, ok. I’m not too much of an expert with Hyper-V, but it is mostly the same as VMW. So yes, for Off-host, you deploy a 2nd server to take over data moving processing. On-host simply means all the processing is done on the same HV host as the VMs are running on that you’re backing up. If you have 2 sites, then yes...a Proxy at each location. You can find more info on off-host Proxy here. And don’t forget..the User Guide is your friend! 😊

No, you shouldn’t need a GW server. Reason is because GW servers are for when you are directing backups directly to a storage device (i.e. Data Domain, etc), which Veeam cannot install services/components on. You are essentially creating a Volume on your Synology and assigning the Volume to a Windows server, which is your Repo. So Veeam installs the required components to the Repo (Windows) server you attached the Volume to. You can read more on what specifically GW servers do here & Repos here.

Hope that helps.

Shane Williford - Veeam VMCA/VMCE | Veeam Legend | VUG Leader | VCP-DCV | Twitter: @coolsport00
dloseke
Userlevel 7
Badge +6

Just my 2 cents...I would not recommend using ReFS with a NAS.  I don’t feel that ReFS is stable enough to avoid corruption because the NAS generally does not have a battery backed cache like you would have in a standard server with a RAID controller.  In the event of a power disruption or another interruption in the data flow, if Windows thinks it has written data to the NAS but it hasn’t yet and the interruption occurs, you can result in ReFS volume corruption.  I have several folks running ReFS with a NAS, and it’s been fine for the most part, but it’s certainly possible and is no longer my general practice.  My recommendation instead would be to use a linux-based repository server and utilize XFS, or if Windows is a requirement, use NTFS.  

If ISCSI wasn’t a possibility, I generally use NFS over SMB, but the only place I have NFS running is in my homelab, but it’s been rock solid.

Derek M. Loseke, Senior Systems Engineer | Veeam Legend 2022-2023 | VMSP/VMTSP | VCP6-DCV | VSP/VTSP | CCNA | https://technotesanddadjokes.com | @dloseke

Comment


Terms & Conditions