Comprehensive data protection for all workloads
Post Reply
cbc-tgschultz
Enthusiast
Posts: 65
Liked: 11 times
Joined: May 13, 2016 1:48 pm
Full Name: Tanner Schultz
Contact:

Offsite Copy Suggestions

Post by cbc-tgschultz »

Our environment setup is like this:

Local:
4-node vSphere cluster, ~90 VMs
2-node Hyper-V cluster, 3 VMs
all nodes connected between each other and to ISCSI storage (Nimble array) via 10Gb/s ethernet.
Veeam B&R Server runs on vSphere cluster, is NOT configured as a proxy
Local Veeam proxy is a VM on that same cluster
Primary Veeam Backups are stored on a relatively slow Synology NAS connected via 1Gb/s

At the DR location:
Connected via cable modem at ~15Mb/s (from Local to DR) x 5Mb/s
1 ESX6 server
1 HyperV server
both backed by a mix of local storage, an old MD3000, and a Synology NAS
DR Veeam Proxy runs on ESX6 server
Replication is performed nightly for most VMs, weekly or others

At the offsite backup location:
Connected via 100Mb/s fiber
1 Synology array identical to the one at the local site

Our local backups, after working out some performance issues seemingly caused, in part, by increased resource utilization in v9, work really well and easily finish overnight, even on weekends when we run active fulls.
Our replications finish overnight in roughly 4 - 5 hours.
Our offsite backup copy jobs used to complete in about a week, but now are failing to merge in anything close to what could be considered reasonable.

So, the merge process is too slow to allow offsite copy jobs to be useful to us. The storage is too slow, and the bandwidth is just not good enough to do 'real' backups to that site w/ active fulls.

Based on this, my plan is to place an ESX server at the offsite location and do replication, like we do for DR, but with a really long snapshot chain to meet our retention needs. Or possibly doing backups using a different product from those replicated VMs (we don't have a Veeam license for that ESX server). I realize there may be other issues with this arrangement, notably that I'll need a HyperV server as well.

Before I do any of that, however, I thought I'd drop in and see if there's something I'm missing. Is there a feature or option I haven't considered that could make our offsite backup more reasonable? Is there an alternative to the ludicrously slow merge process I'm not aware of?

Something to note: We have Standard, not Enterprise, so anything involving per-VM and/or WAN acceleration is not going to happen.
nmdange
Veteran
Posts: 527
Liked: 142 times
Joined: Aug 20, 2015 9:30 pm
Contact:

Re: Offsite Copy Suggestions

Post by nmdange »

I've seen a lot of other users have issues when trying to use a NAS as a backup target. I would seriously consider replacing those with a physical server running Windows with local disks either internal to the server chassis or connected via a SAS JBOD.
cbc-tgschultz
Enthusiast
Posts: 65
Liked: 11 times
Joined: May 13, 2016 1:48 pm
Full Name: Tanner Schultz
Contact:

Re: Offsite Copy Suggestions

Post by cbc-tgschultz »

Yeah, I'm not going to get approval for all the money it would cost to replace our 90TB NAS with a similarly sized SAS JBOD setup. That is a completely unrealistic alternative for us.
nmdange
Veteran
Posts: 527
Liked: 142 times
Joined: Aug 20, 2015 9:30 pm
Contact:

Re: Offsite Copy Suggestions

Post by nmdange »

Placing a gateway server in the offsite backup location may help with the merge performance
https://helpcenter.veeam.com/backup/hyp ... erver.html

You could probably pull the drives out of the Synology unit and re-use them but I realize that's probably not realistic for you either. What can I say, I really dislike NAS devices :)
cbc-tgschultz
Enthusiast
Posts: 65
Liked: 11 times
Joined: May 13, 2016 1:48 pm
Full Name: Tanner Schultz
Contact:

Re: Offsite Copy Suggestions

Post by cbc-tgschultz »

I don't believe there'd be any performance improvement to doing that, given that the disks are SATA and relatively slow. It is an inexpensive solution to be sure, but until recently it has at least been effective. Believe me, I'd love to replace all my NASs with Nimble ISCSI arrays, but it isn't going to happen and I have to make do with what I've got. Besides, the one locally performs really great, largely because it does active fulls and doesn't have to merge anything.

It seems to me that the gateway is part of the backup proxy in this scenario, so it would work a lot like our replication setup to DR currently works. It is worth trying, but I am not convinced that there will be any performance improvement in the merges because I believe the problem is the sheer size of the merges and the slowness of random I/O. From experience I know that our DR environment, which uses replication instead of backup copy, doesn't suffer from this problem.

Which is a bit curious isn't it? The way replication works is pretty similar to forever-forward incremental, yet our backup copy jobs take 10 times as long on a connection almost 7 times faster, not even including the merge time.
Thernlund
Enthusiast
Posts: 29
Liked: 3 times
Joined: Sep 09, 2015 12:02 am
Full Name: Terry Hernlund
Contact:

Re: Offsite Copy Suggestions

Post by Thernlund »

I'm using a Synology box connected via iSCSI on a direct patch as a primary backup target. It's pretty fast it seems to me. Or at least when the bottleneck is detected it come in last. So while it may be relatively slow, it's not the slowest piece.

Your remote backup copy... that's a box you own located at a co-lo someplace? Is there a reason to not use a Veeam cloud provider for that instead of your own box? Cloud Connect is available in Standard.

Granted, I just made a number of assumptions there. So maybe I'm not on the right page here.
nmdange
Veteran
Posts: 527
Liked: 142 times
Joined: Aug 20, 2015 9:30 pm
Contact:

Re: Offsite Copy Suggestions

Post by nmdange »

If it is the merge that is slow, having a gateway server local to the NAS would prevent the merge processing from having to traverse the 100mbps link.

How many disks do you have in the Synology and what RAID level? I'm using local drives attached via an LSI MegaRAID controller but they're all 4TB 7.2kRPM SATA drives in RAID50 (84 drives total) and everything is pretty fast including merges.
cbc-tgschultz
Enthusiast
Posts: 65
Liked: 11 times
Joined: May 13, 2016 1:48 pm
Full Name: Tanner Schultz
Contact:

Re: Offsite Copy Suggestions

Post by cbc-tgschultz »

The remote NAS is at one of our branch offices, some 700 miles away. We are not using a Veeam cloud provider because, frankly, they are significantly more expensive and we're having a hard time seeing what the benefit is given that our 100Mb/s link would still be a bottleneck. I've been interested in a Veeam cloud DR solution, but that's far too expensive as well. Short version: if it costs money, especially if it is a recurring cost, I don't have the budget for it. Now, we could turn this into a debate about whether or not it is my fault I can't convince the higher-ups that business continuity is worth the cost, but that's a waste of our time since it won't result in anything, so I'd rather not.

The remote NAS is configured as a Linux Repository. It is my understanding, and perhaps I am incorrect in this, that the Linux agent does whatever it is that the gateway/proxy would be doing in regards to the merge operation, keeping data manipulation local instead of using the 100Mb/s link. I don't believe data is being exchanged between here and there during the merge, but I haven't actually looked that closely. Granted, the Synology device (and therefore the Linux Agent) has very limited memory to work with (2GB), and v9 does seem to have a higher resource burden, so adding a gateway could speed up the merge, but I know that when our primary backups were configured for Synthetic fulls on an identical NAS they were intolerably slow.

The NAS has 10 8TB 5400RPM SATA disks in SHR-2DR (RAID6). These are SMR disks, which worked fine for the better part of a year but have started having issues ever since DSM 6, so we are slowly replacing them with the significantly more expensive NAS-approved equivalents.

To put in perspective: until recently it took about 3 days to transfer the backup copy data, then another day or 2 to merge. This was acceptable enough for us. After DSM6 and Veeam v9, it now takes 2-3 days to transfer and I have yet to see a merge actually finish. They usually error out (agent closed exception) somewhere around the 48 hour mark.

Given that our DR replication happens over a 15Mb/s link and only takes 4 hours and change, I'm pretty unimpressed with Backup Copy regardless of our merge issues. That's why my plan is to add 2 servers (because I need a separate one for Hyper-V, which I would have liked to avoid but Veeam still can't replicate VMs cross-platform), which we have laying around, and make it into another replication site. If I'm really lucky, I'll be able to talk my boss into getting the additional two licenses to perform backups from the replication targets, allowing me to use the same weekly active full strategy I use here. If not, I'll have to just rely on a really long chain of snapshots.
Thernlund
Enthusiast
Posts: 29
Liked: 3 times
Joined: Sep 09, 2015 12:02 am
Full Name: Terry Hernlund
Contact:

Re: Offsite Copy Suggestions

Post by Thernlund »

My Cloud Connect provider is $600/mo for 6TB and my data is protected by men with machine guns. No joke, I've seen them. ;-)

You mentioned that the merge takes forever. To my knowledge, the merge doesn't happen over the pipe with Cloud Connect, it happens at the provider. So your link speed wouldn't matter in that regard. My backup copy only take a few hours, with the merge taking about 90 minutes every night over a 40mbps link. And that's without WAN acceleration.

You never said how much data you were backing up though (or I missed it).

Your solution appears to me to have a pretty high cost in time and equipment. Buying and maintaining your own gear, cost of the dedicated bandwidth (it is dedicated, right?), your time in configuring, maintaining, and troubleshooting... Just the issues you're having right now are expensive, and possibly insurmountable. All I can see reading your posts is dollar signs (as an IT manager I guess I'm conditioned like that). It seems to me all told CC would be worth while. Doesn't sound like your management is interested in that discussion though, sooo... *shrug* You very well may end up having to live with it.

Those 5400rpm drives stand out to me as a problem. Combine with SMR? Baaad bad bad juju. It's going to have extremely poor IO performance. Given that a merge is a ton of random IO, that very well may be the heart of the problem. Personally I'd try to accelerate the replacement time table as much as possible. 10k or better drives.

But that said, I'll reiterate... this is not at all ideal; A real square-peg-round-hole situation. :-(

Sorry I can't be more help.
cbc-tgschultz
Enthusiast
Posts: 65
Liked: 11 times
Joined: May 13, 2016 1:48 pm
Full Name: Tanner Schultz
Contact:

Re: Offsite Copy Suggestions

Post by cbc-tgschultz »

I don't even think 6TB would cover a single full backup of our production environment. $600/mo is about twice what we pay for the 100Mb/s business class internet at the branch location (which also provides phone service). As I said, I'm pretty sure the merge already doesn't use any bandwidth in my configuration, so again, nothing to be gained from cloud connect.

So yeah, i guess if you're backing up a paltry amount of data, don't have to keep it very long, and are loose with the purse strings then the cost might look pretty good. That's not going to fly here.

I'm aware SMR has problems. I said as much. At the time, it was the only way to get what I needed within my budget. And it worked well enough for about a year. I have to live in the real world here where people aren't as willing as you are to write checks. Of course it isn't ideal. My god your job must be easy if you always get to work with ideals!
nmdange
Veteran
Posts: 527
Liked: 142 times
Joined: Aug 20, 2015 9:30 pm
Contact:

Re: Offsite Copy Suggestions

Post by nmdange »

Yeah definitely agree on the SMR being part of the problem, especially with RAID 6. RAID 5 takes a hit with writes to calculate parity, and RAID 6 has a bigger hit to calculate double parity. SMR has a similar hit to writes because it has to read multiple sectors to rewrite them since they are stored as "shingles" on top of each other on the disk platters.

I would say 7.2k RPM non-SMR drives should be sufficient. 10k drives are way too expensive to use for backup storage in my opinion. Right now my typical backup repository consists of 21x4TB drives in RAID 50 (plus a couple hotspares) which yields 44TB useable space.

Since it's not a particularly large environment, I would definitely look at how much Veeam Cloud Connect would be, or something like Azure Site Recovery.
Thernlund
Enthusiast
Posts: 29
Liked: 3 times
Joined: Sep 09, 2015 12:02 am
Full Name: Terry Hernlund
Contact:

Re: Offsite Copy Suggestions

Post by Thernlund »

cbc-tgschultz wrote:I have to live in the real world here where people aren't as willing as you are to write checks. Of course it isn't ideal. My god your job must be easy if you always get to work with ideals!
You don't have to get snotty about it bud. If you or your organization doesn't want to do things the right way, there will be problems. And I'm not the one having the problems here am I?

If you're paying $300/mo for purported "business-class" internet, I think I'm seeing another part of the problem. Sounds like Cogent. :roll:

Hey man... sorry I bothered you.
cbc-tgschultz
Enthusiast
Posts: 65
Liked: 11 times
Joined: May 13, 2016 1:48 pm
Full Name: Tanner Schultz
Contact:

Re: Offsite Copy Suggestions

Post by cbc-tgschultz »

Even if I could get my boss to shell out for cloud connect, there's still a fundamental problem: It takes several days to transfer a backup copy over 100Mb/s. This has nothing to do with disk speeds, because I can see Veeam eating up all the bandwidth, and it is pre-merge. Why Backup Copy jobs need to transfer so much more data than replications I don't know for certain, but it has soured me somewhat on the whole concept of offsite Backup Copy jobs.

Granted, that's not really a huge limitation for us because we are used to it, but it will be really hard to justify a recurring cost of that magnitude vs moving a few servers that are gathering dust and having me spend a few days configuring stuff.

As I keep repeating about the SMR drives: yes, I'm aware they have performance issues. But they also worked well for a year, and are still doing well for primary backups. The 8TB non-SMR disks are a bit over 1.5x as much, so while I got approval to replace failed disks with them, there's not likely to be a wholesale replacement any time soon.

It's pretty clear to me from the discussion so far that, given the limitations I'm working under, my plan is probably not going to be improved upon without adding significant cost. I was hopeful there was something I was missing.

Thanks for your input anyways.

Addendum:
Actually, Thernlund, I'd rate that $300 business class connection better than the $XXk business class connection we get here at corporate. It's had less downtime for sure. Whether that means they're a great ISP or ours is a really crappy one I can't say. And I specifically tried not to get into a discussion about whether or not we should spend a bunch of money on something because I already knew that wasn't going to happen, yet you went there anyway. I apologize for letting it get to me.
skrause
Veteran
Posts: 487
Liked: 105 times
Joined: Dec 08, 2014 2:58 pm
Full Name: Steve Krause
Contact:

Re: Offsite Copy Suggestions

Post by skrause »

If you want to use replications with "really long snapshot chains for retention" make sure that you stay within the limits of the number of snapshots (28 for VMware, 47 for Hyper-V).
Steve Krause
Veeam Certified Architect
cbc-tgschultz
Enthusiast
Posts: 65
Liked: 11 times
Joined: May 13, 2016 1:48 pm
Full Name: Tanner Schultz
Contact:

Re: Offsite Copy Suggestions

Post by cbc-tgschultz »

Ah, thanks. I've never had to do such a thing and was unaware that there was such a limit. I appreciate the heads-up.
skrause
Veteran
Posts: 487
Liked: 105 times
Joined: Dec 08, 2014 2:58 pm
Full Name: Steve Krause
Contact:

Re: Offsite Copy Suggestions

Post by skrause »

You also won't be able to take advantage of any compression or deduplication so you will likely be using a lot more disk space than backups/backup copies, especially on VMs with high change rates.
Steve Krause
Veeam Certified Architect
cbc-tgschultz
Enthusiast
Posts: 65
Liked: 11 times
Joined: May 13, 2016 1:48 pm
Full Name: Tanner Schultz
Contact:

Re: Offsite Copy Suggestions

Post by cbc-tgschultz »

The 90TBs of storage we have is much less a limiting factor than the 100Mb/s internet connection.

Again, the whole reason I'm switching over to replication rather than Backup Copy: Backup Copies take half a week to transfer (then indefinite time to merge), replications happen in 4 hours on 1/7th the bandwidth.

I keep repeating this because people seem to be harping on the storage, which is part of the problem because of the merge, but even if the merge were instant I'm looking at 3 days for a Backup Copy vs a few hours for a replication. Backup Copies, frankly, just suck for offsite. Come to think of it, I haven't yet found a good use case for them at all.
DeadEyedJacks
Veeam ProPartner
Posts: 141
Liked: 26 times
Joined: Oct 12, 2015 2:55 pm
Full Name: Dead-Data
Location: UK
Contact:

Re: Offsite Copy Suggestions

Post by DeadEyedJacks »

@cbc-tgschultz

Question, If you have Synology NAS at each site, why are you not using storage-based replication?

Otherwise, If you are using Veeam Backup Copy or Replication jobs, then Veeam Proxies at both sites to act as WAN accelerators and gateways to the NAS repositories is essential.

Using a remote Veeam proxy for merges and transforms, particularly over a slow link, is too painful for words.

Just my tuppence...
skrause
Veteran
Posts: 487
Liked: 105 times
Joined: Dec 08, 2014 2:58 pm
Full Name: Steve Krause
Contact:

Re: Offsite Copy Suggestions

Post by skrause »

Have you tried running the copy jobs from a Veeam B&R server that is in the offsite location?

To use it with your existing jobs you would need to run a script to import the backups from the original B&R server to the database (covered in a number of threads about copy jobs on the forums) but I think that might solve your merge performance issues.
Steve Krause
Veeam Certified Architect
cbc-tgschultz
Enthusiast
Posts: 65
Liked: 11 times
Joined: May 13, 2016 1:48 pm
Full Name: Tanner Schultz
Contact:

Re: Offsite Copy Suggestions

Post by cbc-tgschultz »

Given the issues involved with the original plan, adding a server at the remote site to act as gateway/proxy/B&R is on the short list of things to try.

It is my understanding that Linux Repositories already act somewhat like a proxy/gateway, in that the Linux agent performs all the computational work to avoid unnecessary data transfer. If I am incorrect in this, I have yet to be corrected. Therefore, I don't have a lot of confidence that adding a proxy/gateway will improve matters much. The limitation seems to be that Backup Copy jobs transfer a lot of data compared to replication jobs, and 100Mb/s isn't fast enough to get it done in a reasonable time frame for us.

As to why we're not using storage based replication: I believe it will be at least as inefficient as Backup Copy jobs in terms of bandwidth usage, meaning it will never keep up with the changes in the primary backup, and it has the additional problem of replicating deletes just as well as writes, leaving a number of scenarios in which it will be useless. Furthermore, I can't think of a simple way it would allow us to retain data longer than we do on the primary. But to be fair I haven't spent a lot of time looking at this option.
ammaross
Novice
Posts: 4
Liked: 1 time
Joined: Jul 18, 2016 1:56 pm
Full Name: Ammaross Danan
Contact:

Re: Offsite Copy Suggestions

Post by ammaross »

You mentioned your Linux Repository already acts like a proxy/gateway. This would only be the case if you set it up as a managed server and installed the Data Mover Service manually. Just having a repository does nothing more than allow Veeam the ability to store data at that location. This is most likely your problem and can be resolved with a gateway or the Data Mover Service (since the service gets installed on the gateway).
https://helpcenter.veeam.com/backup/hyp ... ackup.html (yes, it's talking about Hyper-V, but principle is the same).

Also, a note about SMR, once the drive has filled up to a relatively high percentage (once it starts needing to shingle), performance can (and does) drop down to only 5-20MB/s. They were likely the only drives of your required size at the time, but the capacity comes at a steep price. Would also explain why it took so long with good performance, unless you filled your 90TB in the first week.
http://www.tomsitpro.com/articles/seaga ... 2-822.html
NightBird
Expert
Posts: 242
Liked: 57 times
Joined: Apr 28, 2009 8:33 am
Location: Strasbourg, FRANCE
Contact:

Re: Offsite Copy Suggestions

Post by NightBird »

A backup repository need 4GB of ram plus 2/4GB per concurrent job.

so if your synology nas that host the datamover has only 2GB of ram it should be the problem
csinetops
Expert
Posts: 113
Liked: 16 times
Joined: Jun 06, 2014 2:45 pm
Full Name: csinetops
Contact:

Re: Offsite Copy Suggestions

Post by csinetops » 2 people like this post

I hate to say it because I'm sure you are sick of hearing it, I don't think your NAS is up to the task... I tried to do the same thing with CIFS shares on my older NetApp SAN which had more power than a Synology box and it was way too slow, the jobs would never roll-up. Sounds like you outgrew the capabilities of your equipment.

Sometimes it sucks starting over but I ran into the same issue a few years back. I ended up just getting some HP servers with DAS shelves full of 6TB drives. Slapped proxies on both ends with WAN acceleration ( I know you don't currently have this but something to look into, it helps.) and it's been running great for over 2 years. I backup copy a little over ~75 VM's over a 50Mbit MPLS every night.

So, I'd stop struggling with your current situation and come up with a upgrade plan you can pitch to the boss to make your life easier. No wonder you are so crabby ( kidding-kidding!). :D Seriously though, it definitely is easier working for companies that invest in their IT infrastructure and don't view IT as a necessary evil.

Good luck!
cbc-tgschultz
Enthusiast
Posts: 65
Liked: 11 times
Joined: May 13, 2016 1:48 pm
Full Name: Tanner Schultz
Contact:

Re: Offsite Copy Suggestions

Post by cbc-tgschultz »

Based on this new information, I think our first attempt will be to add a gateway with at least 6GB of ram (we never have more than one concurrent backup copy job). I can do that with hardware on hand. I'm glad someone was finally able to say one way or the other if my assumptions about the repository were correct or not. Thanks ammaross.

The performance of the SMR drives, which hover around 60-70% (~45TB) utilization and have done for at least 6 months, doesn't seem to be an issue as long as we do active fulls. Obviously that isn't possible with Backup Copy jobs, though. I'd hate to have to explain to my boss, so he can explain to his boss, why a piece of hardware that works perfectly well for backup here is insufficient there. Frankly even I find that somewhat silly.
cbc-tgschultz
Enthusiast
Posts: 65
Liked: 11 times
Joined: May 13, 2016 1:48 pm
Full Name: Tanner Schultz
Contact:

Re: Offsite Copy Suggestions

Post by cbc-tgschultz »

So after looking it over, it turns out the Linux repository is a Data Mover. At least it appears to be based on the fact that it is a managed server and has data mover ports associated with it, so based on that I think we're unlikely to see much gain from adding a gateway afterall. At least, I don't expect the increased ram will make the transfer time less than 3 days, though it might help the merge process actually complete.
bcscholl
Enthusiast
Posts: 31
Liked: 3 times
Joined: Dec 04, 2013 3:56 pm
Full Name: Brian Scholl
Contact:

Re: Offsite Copy Suggestions

Post by bcscholl »

We are beginning to setup a similar backup / replication environment and have a few questions:

Backup local: Veeam Backup Server running on VM which is a member of the same cluster it will be backing up. Current setup has Veeam Repositories going to Synology share on the same LAN network as the servers. I'm beginning to think switching the Synology over to iSCSI target attached to each ESXi machine in the cluster will make it quicker. From this thread will making the Backup Repositories local to the Backup Server OS faster than CIFS/NAS Share? Expected retention 2 Weeks of dailies in Reverse Incremental mode.

Replication Off-Site: Veeam Backup Server running on VM at DR site. Replication jobs to run at-least once a day.
Can we create backup jobs to run against replica VMs, provided they don't overlap with the replication jobs? What backup mode would be most efficient? We would like to hold one or two monthly backups at this location. I'm thinking this would be quicker than trying to run backup copy jobs over the 200 Mbps MPLS once a week.
cbc-tgschultz
Enthusiast
Posts: 65
Liked: 11 times
Joined: May 13, 2016 1:48 pm
Full Name: Tanner Schultz
Contact:

Re: Offsite Copy Suggestions

Post by cbc-tgschultz »

Local backup: In my experience, setting the Synology up as iSCSI instead of CIFS won't make a significant difference, however I've never used reverse incrementals. I would not recommend NFS between Veeam and Synology. Last time I tried that it had a lot of performance issues that were immediately resolved by switching to CIFS. That wasn't always the case though, I remember CIFS having similarly awful performance with Veeam on DSM5, but that seems to have been fixed in DSM6 and/or Veeam 9 as we're running it now with expected speeds.

Off-Site: I find that replication is significantly more efficient than Backup Copy, so I like your plan of running backup jobs against the replicated VMs and it should work fine. However, this will require that you license the off-site ESXi server(s) for Veeam since Veeam's licensing model is based on the number of processors in servers you are backing up.
bcscholl
Enthusiast
Posts: 31
Liked: 3 times
Joined: Dec 04, 2013 3:56 pm
Full Name: Brian Scholl
Contact:

Re: Offsite Copy Suggestions

Post by bcscholl »

Backup Local: I'm not most familiar with Synology but I am iSCSI. When you use iSCSI on a Synology with multiple NICs would we then get twice the speed vs going over a CIFS share?

Off-site: Yes, our DR site also hosts VMs for production. Both sites have full vSphere and Veeam Licensing.
cbc-tgschultz
Enthusiast
Posts: 65
Liked: 11 times
Joined: May 13, 2016 1:48 pm
Full Name: Tanner Schultz
Contact:

Re: Offsite Copy Suggestions

Post by cbc-tgschultz »

A brief look at the documentation here: https://www.synology.com/en-us/knowledg ... th_Support indicates that yes, you can use multipath IO to get a higher speed to the synology over iSCSI, at least theoretically. I'm not familiar with details of the load balancing algorithms involved, so there may be some caveats there. Or you may find that the disk IO is more of a bottleneck than the network.
Zew
Veteran
Posts: 365
Liked: 80 times
Joined: Mar 17, 2015 9:50 pm
Full Name: Aemilianus Kehler
Contact:

Re: Offsite Copy Suggestions

Post by Zew »

I have a Synology NAS at my cold site. I simply used a VM at my cold site to run Debian (which is my managed server there) which is NFS connected to my Synology NAS.

Works a treat.
Post Reply

Who is online

Users browsing this forum: andreidam and 285 guests