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.