We've just recently bought Veeam Backup & Replication to replace our old backup solution. To that goal we've also bought two Synology RS3614xs+. One at our primary location and one as a remote repository for backup jobs.
The RS3614XS+ are configured as follows:
Primary:
10 x 4TB HDD
2 x Intel DS3500 SSD's
10GBiT
Secondary:
10 x 4TB HDD
GBIT Lan connection to our primary site over fibre
I've altered the script to show correct capacity and free space(a thread i've found here in the forums) and that worked well with the secondary location, but we enabled SSD Read/Write cache on our primary location(as our infrastructure is 10G and we can pull data from our SAN at full speed) to speed up our primary backup. However as you can see capacity is not reported correctly, has anybody run into this issue? The synology is added as a Linux Server. If we remove SSD caching all is fine and the size is reported correctly.
Hi,
I don't know how Synology works, but supposing it's a linux distribution with all its software on top, my doubt is the SSD caching is done via software and not by an hardware controller. And because of this, our agent sees directly the SSD volume as a proper volume, while Synology software uses is as a cache system. A hardware controller would show the final tiered storage as a single entity...
The fact that disabling caching shows you the correct size of spinning disks is another hint.
Again, just an idea, never tested this scenario.
Luca Dell'Oca Principal EMEA Cloud Architect @ Veeam Software
That was our thought as well. However the cache size is 480GB and not 218MB(Two Intel DC S3500 240GB in RAID0 as setup by the Synology) as is reported by Veeam which makes it even more strange. It is the correct Volume and via SCP i can browse that volume and see it is indeed 32TB in size.
So, again, the raid0 is done via software by Synology... not saying this is the reason, only trying to figure out why with SSD cache enabled our agent only sees basically the size of one of the SSD...
Luca.
Luca Dell'Oca Principal EMEA Cloud Architect @ Veeam Software
Yes it's done in software raid on the synology, which should suffice if we're looking at pure throughput as it's got an Xeon E3 processor and therefore doesn't need a hardware controller. However the agent doesn't even see one SSD it sees 218MB and one SSD would be 240GB so i'm not quite sure what it sees. And as i've said other tools do see the correct volume size, so i'm wondering if something in the script that needs altering to report correct size. I'll have to dig through it to see.
Hi Akait, it seems like you're experiencing a similar issue which was reported in this topic. Check out a workaround mentioned in that thread, should help you to resolve the issue with wrong free space reporting. Thanks!
I'm looking at purchasing this same Synology model as well. How have you found performance ? If you are using Reverse Incremental, what are you general backup speeds ?.
When you add the Synology as a Linux server, doesn't it need to install an agent on the Synology itself ? I wouldn't think that would be possible .. or perhaps could break warranty ?
blodsbror wrote:When you add the Synology as a Linux server, doesn't it need to install an agent on the Synology itself ? I wouldn't think that would be possible .. or perhaps could break warranty ?
When you add any device as Linux server directly, it does require Veeam agent to be installed on it. You will be able to add it as Linux server only in case it has ordinary Linux installed, as SSH and Perl are required to deploy Veeam agent. Otherwise, you can mount it on any other ordinary Linux server.
What would be the advantage of installing the Linux transport agent on the Synology NAS itself? Wouldn't it be better to have a Windows box with higher end CPU and lots of memory and just use the Synology for pure storage over SAMBA or ISCSI?
If this Windows box is set up "in front" of the NAS, then it is, indeed, recommended. When you cannot install Veeam agent on repository, you are increasing the amount of data to be sent over the network. If you have Veeam agent on both ends (proxy and repository), the data is transferred between them in a highly compressed format, and this is not the case with CIFS-type backup repository. Another thing is synthetic backup operation, which is not performed locally on the repository, if there is no Veeam agent on it.
Sorry to open such an old thread, but wondered if people could confirm if SSD caching on Synology NAS boxes improves the performance of Veeam merging operations?
Currently I'm running a forever incremental, where the backup file is 16TBs and the daily incrementals are about 300GBs. The actual backup takes about 4 hours, but the merge can take up to 13 hours. I'm trying to reduce the merge time and wondered if an SSD cache would help. I'm thinking that the SSD cache may help as this would improve random io writes but would like to be sure the performance with worth dropping a 4TB disk for
The repository is configured as an iSCSI datastore mounted via to an ESXi host, and then the disk presented to a windows 2012 backup proxy. I haven't installed the Veeam agent on the NAS box.
Any performance tips, or comments on anything that jumps out as wrong would be much appreciated
The VMFS discussion was an interesting read and I'll have to weigh it up against the complications some of the other synology users have had, like repository size being reported as the SSD cache size etc.. Masking the storage by going through VMFS eases that pain and others caused by NAS OS upgrades, but either way, your pointer at least made me aware, so thank you!
The raid io calculator was also excellent, I think I might be able to eek some extra performance by looking at raid stripe size etc, but tsightler's comments about caching were also very interesting and I'll probably give it a shot. Either way, thanks for the two links... If I do see significant performance gains (specifically around the merge process) I'll report back just to let people know.
