External NAS Destination Stores

[jcwuerfl]

Is anybody using any External NAS Devices for there Veeam Backup Destination Datastores? If so, anyone have any recommendations as to brand/model that you've seen that work well and what protocol you used? aka cifs, iscsi ?

Was thinking something like a drobo, netgear readynas or something similar ?

Thanks

[jcmachadouga]

We use DROBO boxes (NAS/iSCSI target). We used a crossover cable from the Veeam server to the DROBO via iSCSI (using Jumbo Frames). They are cheap and can handle the heavy IO load (i didn't believed the first time I saw it)

[jcwuerfl]

Good idea w/ the crossover cable. Assuming its a physical server then not a VM? I'm not thinking I want to do USB really, too slow most likely.

[Bunce]

We use QNAPs via SMB over dedicated VLAN in VA mode. No problems and throuput is fine.

Just beware that iSCSI implementations on many of these NAS devices are less than optimal.

[Vitaliy S.]

There is existing discussion on this topic, please check it out: recommendations for veeam backup storage

[Gostev]

We use DROBO boxes (NAS/iSCSI target). We used a crossover cable from the Veeam server to the DROBO via iSCSI (using Jumbo Frames). They are cheap and can handle the heavy IO load (i didn't believed the first time I saw it)

I have Drobo B800i in my lab for a few weeks now, and so far so good. One thing I would have to disagree with you on Drobo is the statement that it is "cheap". Just compare Drobo units prices with QNAP or Synology, big difference. Drobo is clearly premium storage.

[pcamelio]

Hi,
To share my experience, we had VBR server as VM with more than 1 To of storage for backup file.
In order to free up our SAN, I migrate the backup location to a QNAP (6 DD of 1To) , and the perf is still very high as SMB share (over 85 MB/s).
I would suggest to make as simple as possible, just use SMB.
Consider also using a NAS with at least 6 DD for better perf. (RAID 5 (4+1+1 spare). We choose QNAP, but Synology looks good too.

The NAS is alos used to share "static" files during the day (mostly software sources).

[scott_mac]

We use a Readynas Pro 4, CIFS for the backup target and a separate NFS partition for periodic replicas too.

We then Netgear's 'Readynas Replicate' software to duplicate the backups offsite to another Readynas. Works brilliantly.

[Gostev]

Hi Scott, just curious how do you know if it works well, do you test your offsite backups periodically?

[velowulf]

We use a QNAP TS-659 Pro+ as the backup target. We run all of our replicas from the box is NFS (as a datastore as the VM host machines and backup to the same location via CIFS. This works fantastically well!

In fact the only complaint that I have is that Veeam doesn't support backup directly to the target via NFS because that would be preferable to ClFS, but that is another story...

In case you are interested, we also use a QNAP NAS as our VM primary shared storage (also via NFS). It works a treat! I would heartily recommend QNAP devices, and their support is fantastic.

[lvh]

We have 3 Qnap's 859U and one Netgear ReadyNAS Pro Business Edition using iscsi, the Qnap's have been working allmost without problems. There was some iscsi firmware problems with the Netgear in the beginning but they are fixed now.
The speed is around 60-70 mb/s which is okay since I don't want to stress the Vmware servers to much making backup and replicas during working hours.

[scott_mac]

Hi Scott, just curious how do you know if it works well, do you test your offsite backups periodically?

Hi Gostev,

Periodically is a good term to use... but yes I have tested it, we haven't been using Veeam that long and I am just implementing the Virtual Lab/SureBackup system as per a recent Webinar I watched. I am currently a little guilty of not properly confirming my backups work but as i'm the only administrator I would usually know if i'd broken something inadvertently (famous last words!)

I have tested thus far by retrieving a file from a backup that was stored on the replicated Readynas and also booting up a server from a backup - I haven't dug into Veeam to see if it would let me point to the actual replicated backup file on the different NAS to find the backup file, but by copying the backup server to the original target NAS it booted up without issue.

With regard to the iSCSI issues on the ReadyNAS - I too suffered with issues with that, the more recent firmware has resolved it and it has been perfectly reliable since! (more famous last words)

Scott

[Gostev]

Thanks Scott. One thing I love about ReadyNAS is this > Readynas NV+ as target

[bjamieson]

We are using a DROBOFS and it is behaving well... so far. Just doing cifs to it. Cheers

[phildotnet]

Hi Scott,

I was wondering how you had your Veeam backups and readynas replicate set up. You say you have it running perfectly and I am really interested in how you did it.

I don't see how ReadyNAS can just replicate incrementally as Veeam changes the names of all the files as it backs up either via Forward or Reverse incremental.

[scott_mac]

Hi Scott,

I was wondering how you had your Veeam backups and readynas replicate set up. You say you have it running perfectly and I am really interested in how you did it.

I don't see how ReadyNAS can just replicate incrementally as Veeam changes the names of all the files as it backs up either via Forward or Reverse incremental.

Hi,

Slightly unclear here so forgive me if my response doesn't cover everything.

Initially we had an issue where I set the system to Forward Incremental with Monthly Fulls - this worked fine as the amount of data changed was very small and we were able to Replicate around 20Gb over night without issue, the problem was with the Full backup where one of our servers was over 1Tb in size and the backup was around half this - effectively for this I just bought the ReadyNAS in as it was only the size of a toaster and did the Replication over the LAN.

Secondly I opted to try Reverse Incremental, this required a Registry Hack from Veeam support which prevented the .vbk file from being renamed. This got round the problem of huge amounts of data being shifted across the LAN but caused a new bottleneck in that the ReadyNAS was really struggling to use its own 'CBT' to see what had changed and needed to be replicated - it worked but also took a long time.

Ultimately a couple of system changes took place that allowed me to make some changes. 1. We upgraded our main Server to SBS2011 and we were able to rejig the way data was stored internally - mainly that the large proportion of that 1Tb was static data that never changed. 2. The available WAN speed increased tenfold.

So now we're back to the first scenario and backing up more, smaller servers.

It won't work for everyone and in many cases, if you can implement the scenario that Gostev linked to above that is probably ultimately preferable - but for us a dual backup is preferable.....

Hope that helps, not entirely sure if it does!

Scott

[ejleipold]

We use a QNAP TS-859U+ (about 11TB of storage) running across a 2Gb trunk, works great and was cheap and cheerful.

[phildotnet]

Hi Scott,

Thanks for the reply, I have found that registry hack also and that side of things is working well but the readynas replicate still backs up the full vbk every time after a reverse incremental backup has been done even though only there has only been 20MB of changes. ReadyNAS replicate does not seem to jest send the changes.

How have you got that side working???? Is there anything other than installing readynas replicate that needs to be done on the NAS boxes??

It's been really frustrating and I just want it working... Netgear support have been no help thus far...

Any help you could provide would be fantastic!

(I tried to PM you but I don't think it worked.....)

[scott_mac]

Hi Phil,

Are you sure it is actually backing up the full vbk file. I know it says that it has and it caught me out to start with, but actually the speed that it is claiming it has backed up is ludicrous - over a 20Mb connection it claims to have copied data at 9.61MB/s - which is impossible.

For reference this is what I get as my Replicate summary for the only job which i use Reverse Incremental for:

Copy start time: 2012-09-26 01:30
Total files processed: 20
Total files transferred: 3
Total files size: 24.30 GB
Total files size transferred: 19.20 GB
Average speed: 9.61 MB/s
Exit code: 0 (Ok)
Copy end time: 2012-09-26 02:05

It does take longer as it does have to check the changes, in the above example the actual file that Veeam created was just under 400Mb. I believe the time taken is down to the effort put in to check the changes (Replicate is basically just a web based authentication to rsync from what I can gather). It certainly isn't shifting 24Gb of data over the WAN, or indeed the 19.2Gb it claims... that would take a lot longer.

Hopefully the same thing is catching you out...

Scott

P.S. Apologies, i've just seen that I have a PM!

[travis.vanholland]

Scott,

Are you saying that you have the ReadyNAS to ReadyNAS rsync working? I am running Veeam 6.5 and am looking to implement the registry key to keep the file name from changing in hopes my reverse incrementals won't need to transfer the full VBK file. Any insight is appreciated.

Trav

[scott_mac]

Hi Trav,

Yes, have been using it for a long time and now on v6.5 too... contact support and they'll let you know the registry change you need to make. 2 considerations for it though, 1. You'll need a stable WAN connection as fluctuations in line speed upset it a bit. 2. If using Reverse Incremental backups, get as much RAM as you can in the ReadyNAS as it's quite an intensive process going through the changes - as you can see from the above, I don't have a line that would offer 9.61MB/s, that was actually a calculation based on how long it should have taken to move that whole file when in fact it only shifted in that instance 350Mb but the time was down to the fact we only have 1Gb RAM in each ReadyNAS... i'm just investigating increasing it!

Scott

[veremin]

Hi, Travis.

As it has been already mentioned, you can implement a regkey described in the corresponding KB article which is responsible for setting previous naming convention.

This article can be found here - http://cp.veeam.com/knowledgebase/article/KB1076.

However, don’t forget a VBK-name will be changed only after performing a new Full backup and probable Veeam service restart.

Hope this helps.
Thanks.

[dellock6]

You will also have to run "remove from backups" to clean historical data, and keep the old chain somewhere until the new chain has enough restore point to satisfy your retention.

Luca.

[travis.vanholland]

Thanks for the info Scott. I was mainly inquiring about the rsync operation from NAS to NAS only replicating changes and not the whole file. So to hear that you have it working is good news. Support actually told me that the reg key would not work in v6 or greater but I tested it in my lab and it works fine. I implemented the reg key today in production so hopefully I will see some promising results on the rsync job that runs tomorrow.

Not sure what you mean dellock in regards to the cleaning of historical data. Wouldn't this get cleaned up automatically after the new full chain has the required number of restore points (14 in my case using reversed incremental). I don't plan on doing new full backups as I don't have time to process all of that data in my 12 hour window. I'm fine with keeping the name of the most recent backup job though so not a huge deal.

[dellock6]

read again the KB article, regardless the file name you desire, you need to remove older backups from the database to start using the new naming convention. It's not enough to simply change the registry key.

Luca.

[travis.vanholland]

Ahh I see that now. I assumed v.Eremin linked in this kb article http://www.veeam.com/kb_articles.html/KB1193 which doesn't mention anything of historical data. Excuse my laziness

[foggy]

read again the KB article, regardless the file name you desire, you need to remove older backups from the database to start using the new naming convention. It's not enough to simply change the registry key.

As I understand it, this was the case with the first version that implemented this key (v5.01), however removing backups from DB is not required starting from v5.02. Active full is enough.

[dellock6]

I understood it differently:
- remove from DB is always required
- before 5.02 you also had to wait for the next run and avoid run an active full, after 5.02 you can run the job in whatever mode and it will create the new file

Luca.

[GL@MO]

I have a QNAP TS 559 Pro II which is working excellent with VEEAM. It's a 5bay NAS in RAID5 mode with 3TB Seagate drives. Using a simple SMB Share for it where backups are transferred to.

[drew.green@tjtpa.com]

Just wanted to add that we've recently added a Synology DS1812+ (8-bay) NAS w/ dual-gigabit (bonded) NICs. We've set this device up on a separate VLAN and are using Jumbo Frames (MTU 9000). This device has 8 500GB 10K VelociRaptor SATA drives in a RAID5 + hotspare. This was purchased as a replica target (using iSCSI). We've been running it for about 5 days and so far, so good! We now have replicas of every single one of our necessary VMs (excluding various management systems that don't effect the users).