is there a backup method where you dont require double the space

[vroom]

Ok so i can't figure out if i am doing something wrong. With all the various backup methods that veeam supports, it seems that for each one, at one point, you require double the space for the backups.

So say i am backing up 3TB, the target needs to be greater than 6tb. Otherwise periodically backups will fail. Please tell me if i have this right

Forward forever = Requires double the space when compressing and defragmentation. (this is the method i currently use).

Forward incremental = multiple full backup files appear to be stored with this method.

Reverse incremental = requires periodic compression and defragmentation which requires double the space to accomplish.

Am i missing some way to make it use only the amount its actually backing up? I want to figure out the storage drive i should be buying for the future. Basically right now i have to pay for double the storage i think i will need, but not sure if there is a better way. I found if i did not use compression and defrag, the backup file will keep growing forever because it will never remove old data.

[HannesK]

Hello,

So say i am backing up 3TB, the target needs to be greater than 6tb. Otherwise periodically backups will fail. Please tell me if i have this right

only in corner cases. It depends on the size of individual VMs and whether per-machine backup files are used (recommended in general) and how many backup jobs you have (one could do defragmentation for job 1 on Monday, job 2 on Tuesday etc). If 3 TB are multiple VMs with per-machine chains, then compact & defragmentation is done "one by one" (depends how many parallel tasks are configured on the repository). So you don't need the double amount of space, but yes, you need some free space.

I found if i did not use compression and defrag, the backup file will keep growing forever because it will never remove old data.

not really, but yes, it takes more space. compression & defrag also helps from a performance perspective. So yes, compact & defragmentation is recommended and I would also do it.

The alternative is using REFS / XFS. Then you don't need additional space.

Best regards,
Hannes

[BrianBuchanan]

I've found that thinking in terms of old-school tapes, or number of active fulls, helps. If you want 2 backups that's 2 tapes. 14 daily, 12 weekly and 12 monthly is 38 full copies of your data. You'd need 38 tapes if your source fit on one tape, and if you are using a disk repository it should be 38 times the size of your source.

Everything/anything that reduces that requirement is a feature. When you budget for a disk repository that's 38 times the size of your source then data deduplicating appliances start to make a lot of financial sense.

[HannesK]

or number of active fulls, helps

active full is something that only a minority of customers is using, because it creates much load on production and backup storage. I would not recommend using that approach in general.

14 daily, 12 weekly and 12 monthly is 38 full copies of your data

hmm, I only count 21 fulls, because daily backups are incremental backups (at least I have never seen anybody doing daily full backups). 12 weeks includes the initial full plus the additional ones to end up with 14 days. 12 weeks also cover 3 months. So that's 12 +9 then. Let's go for "worst case" and make it 22.

when you budget for a disk repository that's 38 times the size of your source then data deduplicating appliances start to make a lot of financial sense.
Top

but really only, if a customer has active full backups. I would call that "corner case". With synthetic full backups on XFS / REFS, dedupe appliances don't make any sense from a financial perspective.

[stfconsulting]

We struggled with this when we first got Veeam about 8 years ago. Once REFS became a viable option it made everything much better. Where we constantly had to throw more space at Veeam we now have a surplus of space. For reference we backup about 300 VMs with the product.

[walrus2120]

With regards to REFS... can it be trusted now? It seems like everytime I look into it there is a MS Update that broke it (or something of the sort in the not too far past) which makes me very reluctant to use it. But it sure sounds like its good from the info in this thread. It's one thing to break an OS with an update but breaking a filesystem is a huge no for me to accept the risk of using it.

[chris.childerhose]

From what I have seen, Windows 2022 ReFS is pretty stable compared to older versions. We are slowly migrating from ReFS to XFS, though for the same block cloning but for Immutability as well.

[ejenner]

We've been using ReFS with Veeam for a few years on 2019 servers and find it to be pretty good now. Can't really fault it and it does save space. Was my first thought reading this from the start.

[ideenj]

Ok so i can't figure out if i am doing something wrong. With all the various backup methods that veeam supports, it seems that for each one, at one point, you require double the space for the backups.

For your space requirements, it really depends on what settings you have chosen and what type of repository you are utilizing. It is not a hard requirement to have double the amount of storage available for your Veeam backups to work.

Here are a few factors that impact the amount of storage your need

• Source side data

• Change rate

• Retention period

• Compression + Dedupe level

A few suggestions on a space savings type of setup if you are using direct attached storage:

• Forward Incremental backups for performance reasons

• Utilize XFS or ReFS utilize Synthetic Fulls at the default setting of once a week (more frequent Synthetic Full backups can be utilized to lower the

• Per-VM backup files (for efficiency of backups and recoveries)

• At a minimum have optimal compression versus no-dedupe

• Disable Active Full backups or adjust frequency that Active Full backups occur to something much lower than once a month.

• If you plan on running Active Full backups, adjust your jobs where they run on different weeks.

• If you disable running Active Full backups all-together, it is suggested that you run a health check and defrags periodically.

• If you have performance issues with your existing health checks/defrags schedule, consider adjusting the schedule where these do not all occur on the same week and consider lowering the frequency to something less than once a month.

With regards to REFS... can it be trusted now? It seems like everytime I look into it there is a MS Update that broke it (or something of the sort in the not too far past) which makes me very reluctant to use it. But it sure sounds like its good from the info in this thread. It's one thing to break an OS with an update but breaking a filesystem is a huge no for me to accept the risk of using it.

I can't speak for every situation, but sharing my own experiences, we use ReFS successfully in a number of environments (some dated back to 2017) with minimal to no issues. The only time we experienced an issue with ReFS was when one of the backup repositories was configured with the default/4K block size by mistake. We have followed the best practices listed https://bp.veeam.com/vbr/3_Build_struct ... block.html and also made sure to utilize storage devices with 'enterprise-class' PERC controllers.

[tgx]

"pretty stable" doesn't cut it.

[MartinO]

With regards to REFS... can it be trusted now? It seems like everytime I look into it there is a MS Update that broke it (or something of the sort in the not too far past) which makes me very reluctant to use it. But it sure sounds like its good from the info in this thread. It's one thing to break an OS with an update but breaking a filesystem is a huge no for me to accept the risk of using it.

The January 2022 updates broke it, but only for external devices formatted in ReFS, which it turns out isn't supported by Microsoft anyways. They released an out-of-band update to fix that for 2016+, but other than that we've not had any issues. We use it on the daily for our Exchange DAG.

[ejenner]

"pretty stable" doesn't cut it.

Depends... are you developing nuclear fusion or just backing up a load of power point files?

I rely on having multiple copies of backups for protection after a certain point. When you get to the stage of saying HPE can't make hardware or Microsoft can't write software you are setting the bar a bit too high in my view. Pretty stable does work for us if we're assuming all our repositories will be up and running and consistent most of the time.

[YouGotServered]

Every time someone asks "Is ReFS ready yet?" I just grab my popcorn and watch the chaos unfold We're in the middle camp - I'm still a bit worried after all of the horror stories, but I've been using it for a couple of years at a few clients without issues and I think it can be generally trusted. As said previously, multiple copies of your data in different locations is key. It really reduces the stress level by a factor of 10 if you do have an issue with your primary repository.