[ARCHIVED] OLD recommendations backup storage, backup target

[Gostev]

The MD is becoming more and more unsupported

I just thought this was funny

[thornec]

Like Luca said, we've been using a verity of storage types for years, including openfiler with iSCSI, direct attached on windows os etc. they all worked up to a point where speed starts to become an issue. Whether it's the disk subsystem, local bus or even network, then money seems to be the deciding factor as to what you can live with.

[dellock6]

As I always tell to customers and during presentations "cheap, large, fast: you can only pick two"

Luca.

[PaulNSW]

I just thought this was funny

It was supported in ESXi4, then unsupported in 5 and 5.1 but still worked, but 5.5 causes msleep returned 4 errors when rescanning the storage adapters.

Anyway, Paul, there are indeed many different solutions for your needs, but I'd like to check first of all with you, what are the pain points of your actual solution? Because if it's only the unsupported state, I'm not getting it: backup jobs do not use ESXi as targets, so a storage that is not supported by VMware, can still be connected as a direct attach to a physical server with Windows or linux on it, and be used as a Veeam repository. This is common practice, I did it myself at several customers when they upgraded their production storage with a new solution, the old one often becomes a new backup target.
Luca.

We currently have the MD3000i connected via ESXi iSCSI as a 23TB Mapped Raw LUN, which in turn is presented to our Server 2012 R2 VM running Veeam as a big GPT disk. I guess I had forgotten you could connect the MD using Windows iSCSI stack!! We don't have any physical servers to dedicate to this storage, so it will have to be a VM. Would it be best using Windows or some form of linux to direct attach (openfiler/nas, ubuntu, centos?!) the MD3000i

[dellock6]

Indeed, in your actual design using in-guest iscsi would be a quick and easy solution to workaround the unsupported status.
If you want to move to a physical server, I would go for Windows, so you can install not only the repository role, but also the proxy role and leverage DirectSAN. With linux you can only use repository, and you need to keep the veeam VM; on the other side, at least one virtual proxy is suggested in order to do faster restores, since directsan cannot be used to write to datastore but only to read.
In regards to your last question, I would use a plain linux distro and configure Veeam to use a linux repository, avoid to use a nas distro, otherwise you would have to connect it to veeam as a smb share, and performances would be worse.

[PaulNSW]

Thanks for the help Luca - up and running now via Windows iSCSI! Seems to be working faster than esxi used to do as well!

[dellock6]

Well, it's somewhat expected, you removed one layer between windows and the storage
Glad it's better now, and in a supported scenario.

Luca.

[ashfwa]

Hi, I have relatively small backup footprint that is coming close to exceeding capacity on an old 12TB NAS. I am interested in getting some feedback on what folks are using as target devices for Veeam backups? Looking for something that will essentially be used only as a Veeam Target. Something with specs capable of firing up a VM from the backup for a BRIEF period of time is a plus...as is having an out-of-the-box replication mechanism to push offsite. Appreciate the feedback!

[Trev]

We recently switched from a Drobo B800i to a Synology DS813+ and are very happy with the Synology. I am seeing about twice the write performance.

We are seeing sustained write speeds in our job of over 300MB/s now when processing multiple LeftHand LUN's in parallel. All connections are 1GbE. The LeftHand nodes are configured with LACP teaming (two 1GbE NICs per node). We have two separate LH clusters each with two nodes (RAID 10).

The Veeam backup server is an older DL380G6 we had retired as a VMWare host and is now loaded with 2012 R2. It has an LACP team of six 1GbE NICs for iSCSI. I created one 25TB iSCSI volume on the DS813+ using eigtht 4TB WD Red SATA drives. The Veeam backup server connects to the Synology via the LACP team with Windows MPIO.

We do not use Windows dedup on my target disk. We started off this way but performance was too much of an issue if we were to have to restore data from the deduplicated volume or copy it to removable media. We are using the dedup feature on the source side though without issue.

On a side note, we previously were using Arconis to backup our archive data (2008 R2 physical server). We had 1.4TB of data and it was at times taking up to 48 hours to do a full backup. I migrated the data to a 2012 R2 dedup'd volume. Size on disk is now 800GB and backing it up with Veeam takes under 3 hours with our current setup.

[dellock6]

Hi Trevor,
thanks for reporting your expirience. Yours is a realy clean and simple, yet effective design. Nice!

One question: are you using storage snapshots too, or only directsan?

Luca.

[Gostev]

This thread is over 4 years old now, and because the product architecture has changed a lot in these past years, some recommendations are no longer correct. For this reason, I am locking this thread down to let it die. I have created the new topic to continue discussion in > Recommendations for backup storage, backup target

At the time of me writing this, the best low end backup storage you can get for Veeam backup repository is Windows or Linux server with internal or direct attached (JBOD) storage. Below, I am quoting a couple of weekly forum digest articles where I have discussed this in more details.

#1

What is the best storage for Veeam backups? This is certainly in the top 10 questions I get from our partners who want to build the complete solution for their clients in the most optimal manner. Higher-end storage is usually easy - if you have big money to spend, you will get great results with most of the available options, be it serious deduplicating storage device or high-capacity SAN. But, what about lower end storage systems? Most people seem to think "since I need the cheapest storage for my backups, I will just buy the cheapest NAS", which is actually a bad choice! Those cheap NAS devices are neither reliable (top source of backup file corruptions due to questionable optimizations on top of shares), nor fast (usually too few spindles and dual 1Gb Ethernet connectivity at best), nor they are actually the cheapest option (comparing to another one you get with Veeam).

What if I told you that you can get a very reliable and fast backup storage without actually having to buy one? Thanks to B&R's architecture, you can do this. Take any decommissioned physical Windows or Linux server, stuff it with a bunch of hard drives - and you get the most economical, fast and reliable target for Veeam B&R you can possibly get at this price point. Sure, you can probably build even cheaper, or faster, or more reliable target - but the above route will always provide for the best possible combination of all three. And even if you run out of space for more hard drives within the enclosure, you can still grow capacity in a very cost effective manner by direct attaching JBOD, which are quite cheap.

So, what is it exactly that makes a physical server with internal (or direct attached) storage the best choice for storing backups? It's cheap, because in most cases you don't even have to buy one - any virtualization project leaves plenty of those behind (and if not, then you are doing something wrong). It's reliable, because we are talking plain vanilla operating system without any hacks or optimizations, and there is no file shares involved. And it is very fast, because all I/O intensive operations on backup files (such as transformation) are performed locally by data mover running right on the box, instead of over relatively slow Ethernet network. Finally, you can easily grow both capacity (by adding more JBODs) and scalability (by adding additional servers) of this storage platform along with your virtual infrastructure with minimal additional investments. The latter is actually why I tend not to limit this solution to SMB only, as I've seen quite a few of mid-size customers using this storage concept with great success.

#2

Today, I wanted to share some of the most interesting feedback I have received in response to my article about best backup storage from 2 weeks ago.

First and foremost, Windows Server Storage Spaces was the popular feedback item, and I was very happy to see that because I’ve been promoting this feature quite heavily both externally, and internally to our engineers. A few people noted their usage of Windows Server Storage Spaces in conjunction with my suggested backup storage architecture which allows them to create uber repositories, spanning (for example) both internal server storage and one or more JBODs attached to the server. Not only this approach provides them with huge volumes to target their largest backup jobs to, but this also guarantees they can easily expand capacity of said volumes in future, should the need arise.

Another interesting storage architecture shared had a goal of building highly reliable backup target. The architecture is essentially the same: Windows Server 2012 with Storage Spaces on top of internal and/or direct attached storage, but additionally “virtualized” with clustered SMB 3.0 file share on top to be able to leverage the transparent failover feature. This SMB 3.0 file share is then registered with B&R normally as a CIFS-based repository. The guy actually sent us a video of his experiments, where he starts backup job and then fails over that file share multiple times - and backup just keeps running with fantastic speed! Pretty cool, especially since he noted that other backup solutions could not handle the same test, even though the failover is supposed to be “transparent”.

Finally, here is really nice write up and real-world proof that my proposed storage architecture scales in both capacity and scalability to support even largest environments of 100 TB and more in size!

We used another product for our backups for years. I was brought in last year because the company had many issues with this application. I was able to clean up almost all of the issues but we ended up switching to Veeam anyway. You see as part of their mitigation to get backups done while they had issues the previous admin used Veeam to do backups on some critical systems. Veeam worked so well that we decided to virtualize 99% of the environment in order to take full advantage of Veeam B&R.

I as began my deployment I utilized the NetApp FAS2240 that our old product used to backup too. I quickly found that doing reverse incremental backups to LUNS on this NetApp was not going to work. After much investigation with NetApp support we found that the way the NetApp writes blocks is not very compatible with the way Veeam writes blocks. It causes a huge amount of resource utilization on the NetApp an so backups and tape outs are extremely slow.

I started searching for another solution and luckily we had a lot of old HP DL380 servers and SAS attached disk arrays that had been retired. I decided to build a new backup server using this equipment for testing. I build a 60Tb backup server using only a DL380 & SAS Attached arrays full of 2TB SATA disks. The performance increase was dramatic. So dramatic that I can now perform all of my backups every night with fulls on the weekends and tape them out every night with no issues. This was something that we were never able to do with our old product alone.

Since the storage I used was all out of warranty I convinced management that we should purchase new backup units to replace these. We are purchaing a new DL380 with attached storage that will have 80Tb of usable space. We are also buying another unit to send to DR so I can run backup copies to it. The cost for this storage significantly less than a NetApp. The NetApp units can easily top 6 figures for only 40Tb where as the HP Storage is less than $50k for 80Tb.