[Feature request] Scaleout extent priority for content expiration/migration

[Seve CH]

Hello,

Now that ReFS is production-grade, I'm dealing with a backup migration "challenge".

I have a Scaleout repository with many extents. I want to be able to empty them and format them to ReFS, but they are huge (50-200TB each). I've also used some temporary stockage (150TB) I borrowed from another project, this time in ReFS format which, if I use extent evacuation, crashes the server under heavy load.

My suggestion is to be able to "tip" the extent selection algorithm to mark which extents are preferred over the others or to just stop using one of the extents as target. This way, the data will automatically expire and I will be able to remove the extent without backup downtime (maintenance mode) or SLA violations (disabling jobs to be able to move data quickly enough).

So, I see two possible implementations:

• Implement extent priority (complex). The preferred extents will be used before the others with lower priority.

• Content expiration flag (easy). The extens will be as usual, but the extent selection algorithm will ignore the ones with the "content expiration" flag as a backup target.

What do you think? Does it make sense?

Best regards

[ejenner]

I tried Scale-out but after realizing the shortcomings of it I don't want to use them again. As with any feature where you have a choice there are often pros and cons which are personal to each user. Probably useful to some users in some configurations.

The reason I ended up with the Scale-out was that I had a runaway job which had filled up a single drive array and I wanted to give it some growing room so the job could continue and hopefully complete. Unfortunately it also filled up the second extent so I was back at square one. Over 90TB of disk gobbled up by one greedy job.

For reasons such as you mention, it seems as though it would be better to keep the different disks which could be combined into a Scale-out as separate repositories. The downside is that you'll have to manually manage the free space yourself. The upsides of retaining granular control over your various repositories are numerous. Being able to move them around, format them, portability of jobs, safety of all files for a job being in one place, ect, ect... biggest of all is to prevent runaway jobs from blocking out your entire system. That's what happens if a backup goes out of control and uses up all of your space overnight. Having individual repositories means that problem is contained within a single repository.

I'm still trying to evacuate a 10tb file from the Scale-out so I can split it back into individual repositories. It does not crash the server. There is some process going on when it gets to 100% complete where the file is being reprocessed again from the beginning. So if you note the point at which you get to 100% and the time it took to get there and then double it... that is the total time it will take to evacuate the file! I'm up to 21 hours. It has failed a couple of times with random errors and if it fails again I'll delete it. I've been backing up the same data to another repository for as long as it has taken to try and repair the Scale-out.

So I think rather than making this a feature request I'd say best off keeping your repositories separate. There will be occasions when people will still want to use Scale-out so not suggesting the feature isn't worth having. Just that for some users there are good reasons not to use it. i.e. it's nice to know it's there, but you don't have to use it just because you have more than one repository.

[Seve CH]

Hi Ejenner,

Well, being able to phase-out backups will be a good point for scale-out repositoires. That will let to migrate storage easily:

• Create a scale-out repo with 1 extent

• When you want to migrate to a new storage array, add the new one as second extend

• Mark the old extend to "content expiration" (the feature request I'm requesting )

• Do active full backup (backups will go to the new storage)

• Relax and let the old content to expire/disappear

For archiving storage, you will need to help a bit like copying/moving files by hand, but for short term retention (i.e. 30 days), the migration will go smoothly

If the "content expiration" gets implemented, I will use in most cases scale-out repositoires with 1 extent only.

Regards

[ejenner]

If you cloned the backup and changed the storage target you could achieve the same thing.

[sgroeschl]

I agree 100% on this, having a way to mark an extent as less desirable would be very helpful.

We have a SOBR with 5 extents, one is on a raid that needs to be expanded and will take a few weeks to complete. It would be great if I could at least tell veeam to only use it if necessary OR let me use it as capacity tier and offload aging sets to it only. My issue is if a synthetic full tries to write to the drive or read from it it chokes. Having the ability to mark it as "old" as OP has mentioned would be a great help!

[iamcts]

If your system is crashing or is slow during Veeam's operations, you might want to troubleshoot your underlying system. Veeam isn't the problem, it's just Veeam is the catalyst that revealed your problem.

I don't think they want to go down the rabbit hole of catering to customers who aren't running their software on "stable" systems.