How many backup repos?

[Harald]

Hi,

we have setup our Veeam system with iSCSI storages (Synology NAS), but now we're planning to move important backups to faster storages (NL SAS with IBM v7000 FC-storages). The Synologies are organised with one LUN per storage, providing 30 or more TB per storage. With the v7000 it would be possible to setup them in the same way and build few big repos, or setup several smaller ones.
So, the question is, what are your experiences? Is it better to have fewer repos, each one serving several backup jobs, or should we build a couple of smaller repos, with each one being used for only a few jobs?

Many thanks for sharing your experiences, and kind regards from Germany,

Harald

[foggy]

Harald, multiple repositories are not typically required unless you want to be able to leverage multiple writing streams to your storage by splitting jobs into different repositories. However, with the per-VM chains that will be available in v9, you can achieve that even with a single repo.

[skrause]

Are your V7000s the same storage devices your production systems live on? If you are purchasing them new (and your IBM rep will probably get angry with me for telling you this), you can get V3700s and get pretty much the same level of performance on the NL SAS drives for considerably less cost as they use the same drives/OS (we are an IBM shop and this is what we do). We were able to purchase an entire V3700 full of NL SAS disks for about a third less than purchasing an additional tray with the same disk capacity for our V7000.

Outside of the cost difference, if the V7000 is your production SAN you are not protecting yourself from a storage failure if your backups live on the same hardware as your production systems.

As far as repo setup, we set ours up with several smaller repositories which makes it easier to allocate additional disk to a volume if they grow more than expected but is less efficient in space utilization. In v9 the per-vm chains and scale-out backup repositories should help us a quite a bit with that though.

One bit of advice: don't create your Veeam repository volumes as thin provisioned volumes in the Storwize. IBM does not have TRIM/unmount support in the code yet so you will get alarm messages about space utilization on the volume even though Windows will be singing along happy as a clam as the space is not reclaimed on the storage. I happened to get said warning at about 2AM on a Saturday when my backups were running

[Harald]

Hi,

and many thanks for your responses. To answer the questions, the NL SAS HDDs are connected as extra shelfs to our productive v7000s, but we have two independent ones and backups from one productive storage will be written to the other one and vice versa. This is also necessary since the two storages are located in different datacenters, so, we have to redirect the backups to have off-site backups.
And, thanks for the tip with the v3700, but unfortunately this came too late, the v7000 shelfs are already delivered and activated today.
But good to know this if we need additional space, .
So, we will setup only a few big repos, and use the per-VM chains in v9 (also looking forward to this release, seems to have some really interesting features). Last not least, thanks for the tip regarding thin provisioning, this is quite good to know and we will pay attention to it when we setup the repos!

Thanks and best regards from Germany,

Harald

[skrause]

Glad to know I could help. If you just need backup or a secondary site storage the V3700s are great. Not only are the enclosures/licensing way cheaper, the drives are about 60% of the cost per drive as well.

Also, they recently released bigger 2.5" drive capacities for all models which are actually less expensive per-GB than the smaller ones of the same speed. I think they released them right after we added a shelf with NL to our production V7000s, sigh

Oh, make sure you use the /L volume format option as well just in case you decide to use Windows 2012 dedupe. https://www.veeam.com/kb1893

[kdorsainvil]

I am doing a Veeam POC and having a little trouble wrapping my head around multiple repository. I am coming from a Veritas Netbackup environment. We are using a Data Domain (DD4500) as our storage device.

Should I be using multiple Storage unit and create one Veeam Repository per storage? Or create one storage unit on the DD and point multiple Repository to it?
Is there some where I should be specifying the size of the Repository?

How many VMs should you backup per Repository? We have a large environment about 1500 VMs and growing.

[foggy]

Please review some considerations above. The size of repository is defined by the space available on the volume it points to.

Also, I have to mention that having dedupe storage device as a primary repository is not a recommended approach.

[albertwt]

Hi All,

I'm currently wondering about which is the best storage strategy for my existing VBR 9.0 repository.

As I have just installed HP StorageWorks D2600 array - 12 x 3TB SAS 7200 rpm HDD, using RAID 6 (ADG) the available LUN size is 27 TB approximately.
So should I deploy Multiple smaller LUNs (2x 13.5 TB) or one big single LUN (1x 27 TB) ?

The existing Backup Repository on the same server is also served by HP StorageWorks D2600 array - 12 x 3TB SAS 7200 rpm HDD, using RAID 5 the available LUN size is 30 TB approximately, but it was deployed as 3 x 10 TB NTFS or smaller NTFS LUNs as below


is that because of the performance purpose or NTFS limitation ?

My Backup Proxy VM is 3 and the number of Backup job is 24, so what would be the best case for me to prepare for the additional 27 TB of backup repository ?

[foggy]

Albert, please review some considerations above.

[meggerz]

Hi All,

I was wondering what's the best practice in regards to setting up a SAN for Veeam backups? Would one big LUN be better or would multiple smaller LUN's per backup host be recommended?

Thanks!

[DGrinev]

Hi Megan,

Please review this discussion above it should answer your question. Thanks!

[meggerz]

Thanks, however, I still have some concerns and hope it is OK to write in this post.

Each job we run is a separate job; we do not have multiple VMs backing up in the same Veeam job. Reasons for this are balancing our loads for our fulls as we found it most effective to do it this way as we still go to tape and don't have a library. I don't see how utilizing per-VM backup files would help with this configuration. The thing I am unsure of in my mind is largely the performance impact. All of the LUNs are on the same physical drives (disk group), but I'm wondering if Windows sees them differently and adjusts the disk queues accordingly when they are separate LUNs as opposed to one large 30TB LUN with a single disk queue in Windows. I haven't done any performance testing to test this theory and realize that there could still be a limitation at the hardware controller level but that should happen regardless of multiple or a single LUN. Hope that makes sense....

[skrause]

Are you doing any Windows Deduplication on these files?

[meggerz]

No, I'm not using dedup. I'm paranoid

[skrause]

If you aren't doing dedup on your repositories then using one giant volume versus many smaller ones is going to be a personal choice in most cases. We use windows dedup so we carve our SAN up into a number of 8ish TB volumes.

You would probably need to check with your storage vendor for recommendations in terms of the perfomance impact of one vs many LUNs.

[foggy]

Hi Megan, you can run some basic tests to see if there's any significant performance impact with multiple LUNs vs a single one. Per-VM backup chains could help to achieve multiple writing streams to the storage in case of multiple VMs in a job, which is not the case in your environment, if I'm getting it right (instead, this is achieved by having multiple jobs).

[meggerz]

Foggy, you are correct, per-VM won't help me as my jobs are all individual ones

I would do some testing as I have in the past and haven't had a ton of time right now, but was hoping some others could provide some feedback based on what they have seen in the past in Windows primarily. I'm getting in touch with my storage vendor to see what they say.

[foggy]

Please get back to share your findings with the community, we would really appreciate that.