Linux Hardened Repo vs HPE StoreOnce as primary backup Repo?

[UlrichThomas]

Hello there,
I am searching for hints, pros and cons to invest in a Linux Hardened Repo or a HPE StoreOnce as the primary backup repo.
Primary Storage is a HPE Nimble.

[Mildur]

Don‘t use a dedup appliance as primary Backup Storage.
In case of a restore, you will have very low restore speed. It‘s never recommended.

Go with a small linux hardened repo as primary storage and use a HPE StoreOnce as a secondary storage for your gfs/long term retention.

[erwanns]

You can leverage that KB article : https://www.veeam.com/kb2660

[UlrichThomas]

Are there any measures how worse the penalty of a restore from a dedup appliance is?
Is it more of the half slower then a Linux/Windows JBOD?

Today I have a backup job, doing an incremental to a NAS box and leave the storage snapshot on the nimble.
In a case of restore I would use the storage snapshot if it's possible.

For the NAS I'm looking for a replacement that is more reliable, supported and utilize a 10GbE connection.

[Mildur]

Storage snapshots on the production datastore are not backups.
If your production datastore dyes, you need to restore everything from your backup Repository. If this is a dedup appliance, you will have large RTO Times.
Instant vm recovery will help you, but with a dedup appliance, it could be very slow.

Our old dedup appliance from another vendor had a restore throughput of 100-150GB per hour. Ok, it was old (from 2016), but a linux hardened repo will give you much more throughput and it will be ransomware protected if you configure and protect it correctly.
Take a HPE Apollo and use it as a linux hardened repo. We have done that and are really happy. Our RTO time is 10-15 times faster as our old dedup appliance. At the moment, our bottleneck is the production storage.

For question about the restore speed, call your hpe presales technician and ask him about a poc or a demo.
They know better what their devices can deliver.

[soncscy]

Seconding Fabian here -- deduplication appliances for your secondary archival backups.

Veeam's IO pattern is primary random read/write for virtually all the useful options (Synthetic fulls, Instant Recovery, Health check, etc). Unless you're in a position on production to perform active fulls non-stop and deal with the performance impact this carries, you want to offload the IO of your backup workload to the repositories whenever possible. For virtual machines, this means very short snapshot times. For physical machines, this means very limited CPU time for the relevant agent.

Deduplication appliances like Storeonce excel when you throw multiple write streams at them, but a stream for Veeam as I get it is a single backup task; one disk/Machine basically. The deduplication appliances are great if you throw dozens of streams at them, so it's fantastic for taking a huge volume of throughput but with limited max ingest. (i.e., you can easily sustain 64+ streams on higher end deduplication appliances, but each stream is going to cap at the NIC/FC ingress speed)

There is a place for this trade-off, but it's not as a primary target for your production backups; that cap on each stream will mean longer IO impact on the machines. Furthermore, to get high throughput, you need to provision your gateway for the deduplication appliance like a repository anyways to maintain performance; in the field, I've had clients that were able to pretty generously push past the Veeam recommendations, but I suppose this isn't a guarantee, so I wouldn't bank on it.

For all those reasons, for your primary storage, size out for an appropriate short-term "fast restore" retention, and maybe look at deduplication appliances for secondary targets. You __can__ use deduplication appliances as primary, but check the random read performance and get your sales rep for the storage to prove the max of random IO for your device so you can properly plan for recovery.

[nmdange]

With the space savings you get from XFS/ReFS, I don't think it's really worth it to use a deduplicating appliance even for archive backups. I would just get a Linux repo with locally attached cheap high capacity disks. You can get a 4U server with 60 drive bays from several vendors.

[Gostev]

You are correct about the space savings as we're talking 30-40% effective capacity difference between ReFS/XFS and StoreOnce as a primary repository.
I literally got a note about results from the most recent rest a few days ago, it showed 37% difference on 56 days retention.

You can only get cost benefits from deduplicating storage with a very long term retention policy.

[UlrichThomas]

Thanks a lot, folks, for sharing your opinions.

Are there any recommendations / sizing guide about CPU and RAM for this Linux repo box?

[Gostev]

Not really as it depends solely on the size of the environment and backup window. Having more CPU/RAM resources will allow running more tasks in parallel, that's the only difference. Veeam can work on any server, you just need to configure the number of max concurrent tasks according to the CPU/RAM resources available, according to system requirements for a backup repository.

General advice is to not skimp on RAM, since it's cheap anyway. While lack of CPU power is hardly a problem with modern CPUs (and especially so for repositories, which do not do much heavy-lifting). If I am not mistaken, 2 tasks per core is considered sufficient for backup repositories, whereas for backup proxies 1 task per core is recommended.

[FedericoV]

Don‘t use a dedup appliance as primary Backup Storage.
In case of a restore, you will have very low restore speed. It‘s never recommended.

Go with a small linux hardened repo as primary storage and use a HPE StoreOnce as a secondary storage for your gfs/long term retention.

I just came across this old thread. The new StoreOnce HW and SW releases are much faster than just 2 years ago, especially with V12 and the new catalyst stores in fixed block chunking. I haven't run benchmarks, but in my lab I have seen restore running constantly over 400MB/s. For Random I/O, the improvement is even higher and basically depends on the number of spindles in the system. The deduplication overhead on random I/O is minimal, especially for the StoreOnce units with metadata on SSDs.