Anti-"Feature" Request: Dont remove backward/reverse incremental

[Poweruser]

Yes, reFS is nice.. but...
its a small installation, not thousands of disks.
one NTFS for system
one for backup repo and all other drivers, tools etc. NTFS
and one for Hyper-V Images.

NTFS is rock solid for years, support quota, acls etc. no reason to change to an "experimental" one which is not 100% fully supported and compatible.
many many vendors say: never use reFS (because they dont want to change or test their software - but thats another problem)...
so i prefer to use NTFS for everything.

i agree, there are many nice, modern/future solutions, but it and industry is normally decades before and they hate changes, so we still would love to use win7 if it would be possible ;-)

i agree also, that changing to a modern fs like reFS/XFS/ZFS etc would be a big and good step, but i think we should give it some more years...

[Gostev]

XFS is anything but modern in fact, it was introduced on the exact same year as NTFS.

[pybfr]

Its opensource incarnation turns 25 this year, introduced by Silicon Graphics for IRIX in 1993...

[RubinCompServ]

Yes, reFS is nice.. but...
its a small installation, not thousands of disks.

ReFS is a file system, and unrelated to RAID. It works just fine on a single disk.
https://en.wikipedia.org/wiki/ReFS

NTFS is rock solid for years, support quota, acls etc. no reason to change to an "experimental" one which is not 100% fully supported and compatible.

ReFS has been around since Windows 2012. It's no more "experimental" than any other Windows component (which, I admit, isn't saying much, but you seem to be okay with Windows over Linux anyway), and supports the same quotas, ACLs, etc that NTFS supports. You've mentioned that you're using Hyper-V - would you be surprised to find out that Hyper-V was also first released as part of Windows 2012? In other words, you're literally running your Production environment on something just as "experimental" as ReFS! By your reasoning, you should be running VMware (especially, on the subject of "100% fully supported and compatible", considering the number of vendors that will provide an OVA for appliance deployment but nothing for Hyper-V).

many many vendors say: never use reFS (because they dont want to change or test their software - but thats another problem)...

While that may be true, this vendor specifically says to use ReFS, and pops up that warning every time you try to create a repo on an NTFS disk.

[Poweruser]

we are going off-topic...
the main goal is to store data on tape or classic storages.
so reFS does not matter here.

anyway:

the latest info i have is reFS does not support boot nor quota.
also many vendors dont say "go" for new things, so they suggest the good old thing only. still many prefer office 32-bit...
iam also still on server 2016.

but again: i agree, that reFS is better and should be used if possible. (except compatibility and newer/complex usage)
i think for a new server i will consider using reFS for veeam repo and for hyper-v.
but if no quota support is implemented, i cant use it on fileserver (windows shares) and i cant use it as boot.

when windows 2016 was new, reFS was also still an experiment in my eyes. many new ideas come and go, and if you adopt too early, you have to go a step backward later. (like android on windows is gone, before i
now it changed, but changing to reFS can only happen if server is changed. otherwise its not worth the effort..

but what if copying files from "modern" filesystems to "classic" filesystems?
in this case the size will grow, so thats not ideal, as its intransparent imho for secondary backups like on an external disk, usb stick, whatever..

in my eyes reFS is useful for snapshots and reducing redundancies while having multiple backups and it may be more resilient and sometimes performant...
thats it. and if you dont need these features much, ntfs is still rock solid, i never had problems with ntfs ;)

[RubinCompServ]

also many vendors dont say "go" for new things, so they suggest the good old thing only. still many prefer office 32-bit...
iam also still on server 2016.

If you don't mind me saying so, it sounds like you are averse to moving to newer technologies until you are forced to. You're using an OS that was released nearly 9 years ago and left mainstream support more than 3 years ago. So why are you so concerned about Veeam 13?

Your original post said:

Maybe it is a performance impact, but its better to keep the latest backup full, because - normally - everyone wants the latest backup and full is better than delta..

It's already been explained how you can keep multiple backups as Full without using extra space. Then you were concerned about having to copy multiple points to tape, and we explained how you can keep every backup as a Full without using extra space (and Gostev even explained that all backups to tape are Full anyway). Now you are concerned about copying that Full to a different location - but that's what you wanted to do in the first place! Instead of constantly moving the goalposts, why not just explain what you're doing today and why you believe that will break and some of the experts here (which I am not) will hopefully explain how you can change your processes to keep your existing requirements. Based on what you've said so far, I can't imagine that there is no way for you to continue to get the results that you want, but not if you insist on being stuck in an "oldest is best" mentality.

I am not an employee of Veeam and gods know that I disagree with a number of their decisions about what features to cut, but you're willfully placing yourself in a corner case and expecting Veeam to cater to you, and even I can see that that simply isn't going to end well. Considering that Windows 2016 is the minimum supported level for v13 (source), you may want to consider upgrading your hardware and OS from "classic" to something that reasonably approximates "modern" before upgrading Veeam. If you still can't use ReFS, perhaps consider Rocky Linux (which is only 4 years old but a clone of Red Hat which has been around since the mid-90s) and an XFS file system for your repo.

[dpeach01]

All this theoretical stuff is wonderful and demonstrates how smart you all are. But reality is what it is. When you run incremental backups daily, at some point you MUST run a full backup, either synthetic or active. At that point you must have two VBR files in your file system. Am I wrong yet?

if one VBR is 17 TB then two is 34TB. Still with me?

That plus a week of deltas, say 36-37TB for a weeks' worth of backups on a 17TB Windows server. Granted the oldest full is deleted the next time retention runs assuming you have reached your retention RP number (oh I forgot, that's no longer supported either), but you still need to allocate the space in your repo to accommodate that growth. I haven't even mentioned the resource drain or the time required to complete the synthetic or active Fulls. 17 TB takes DAYS to complete and breaks my RPO/RTO's. Other jobs are affected as resources are consumed completing the 17TB full (worker, repo, proxy, gateway..)

What is the actual HARM in continuing to support reverse incremental backups? They work great and have been supported by Veeam for years. The heavy lifting is done.

All the pro forward people here have spent a great deal of energy explaining why everyone should simply smile and take it, but I haven't seen a coherent reason why we should have to.

This doesn't have to be a religious thing, it is just about supporting your customers so that they don't become former customers.

[BackupBytesTim]

If you use a XFS or ReFS with block cloning configured, two VBK files (full backups) do not take up twice the space. That's the key point. Backup of the entire computer takes 17 TB (per your example) if you change 100 GB of data, the next VBK will be effectively be 100 GB on the disk, less with compression, because the identical data does not take up additional space in the repository storage.

This is what Veeam is currently supporting. If Veeam's latest version is no longer suitable for you, just switch to a different backup software or don't update. There are plenty of other options out there, including some I would say are better for different reasons depending on the scenario. Ultimately for Veeam it comes down to not wanting to spend the time or effort supporting older features like Reverse Incremental backups. My company uses 3 different backup softwares across all of our customers, of which Veeam is only one. Different companies have different needs, and as much as I'm sure Veeam would like to keep as many customers as possible, if they don't want to support the Reverse Incremental functionality, and that loses them a customer, then that's the way it is.

[tommy.oshea]

When you run incremental backups daily, at some point you MUST run a full backup, either synthetic or active. At that point you must have two VBR files in your file system. Am I wrong yet?

Yep you are wrong. There is something call a Forever Forward Incremental. Doesn't require a second full on the disk. After an incremental backup is taken, the oldest incremental is merged into the the Full. This process shouldn't take any longer than the reverse incremental took.

if one VBR is 17 TB then two is 34TB. Still with me?

Thanks for the quick maths.

[dpeach01]

@backupbytesTim. Thanks for the suggestion. I may take your advice. If you are speaking for Veeam, you've done a great job promoting their product.

[Gostev]

Indeed, @Rick.Vanover I think @BackupBytesTim has made himself a Veeam Legend just from this thread alone I wish I had 10% of his patience.

[Rick.Vanover]

Thank you @gostev -> The creeping commences!

[RubinCompServ]

I wish I had 10% of his patience.

We do too, Gostev

[BackupBytesTim]

Indeed, @Rick.Vanover I think @BackupBytesTim has made himself a Veeam Legend just from this thread alone I wish I had 10% of his patience.

Thanks @Gostev !