Need help with configuration check - Veeam support declined to assist

[CaliMSP]

Hi folks,
As I've posted previously, I'm deploying Veeam 11a as a new install to replace old v9.5. There are new features and functionality that we want to use that has not been used before. Because of this, the job configuration and storage needs to change. I've asked Veeam support to verify my plan and proposed configure and answers some questions, but they sent me back to documentation and pointed out that support is only for break/fix issues. I just want to ensure that we proceed with the correct understanding and correct configuration.

OLD:
v9.5
Reverse incremental
On-site daily to NAS
60 restore points
Encryption enabled

Proposed:
11a
Forward Forever incremental
90 days on-site to NAS
90 days off-site to Capacity Tier object storage to WASABI via COPY
Immutability on
Encryption on

My concerns and questions:

1) Do I understand correctly that for Capacity Tier essentially requires Forever Forward Incremental and COPY mode in order to retain full chains with immutability enforced?
2) Can immutability flag be turned ON after the job has been running as a test for some time to ensure that files are being successfully offloaded to Capacity Tier?
3) Wouldn't we need to somehow exclude the FULL backup file in Capacity tier from immutability in order for the oldest VIB file blocks to be injected into the VBK file?
4) Is it essential to start new chain and start uploading it to the Capacity Tier from the very start as otherwise there would be too many backup files if Capacity Tier off-loading enabled later?

I've deployed Veeam from v6-9.5, but never with the Tiered storage or immutability and documentation and FAQ do not fully answer my questions. This is the reason I've opened a case with support and now asking here since they can't help. Support ID: #02646374 in case it matters.

[CaliMSP]

5) Currently there are replicas on vSphere hosts made by Veeam. We do cross replication between the servers. Since we are doing a new deployment and are not importing configuration from v9.5 - will new Veeam 11a see replicas or will it attempt to make it's own new replicas of the live systems? Do we need to delete replicas from disk created by old veeam install?

[CaliMSP]

2) Can immutability flag be turned ON after the job has been running as a test for some time to ensure that files are being successfully offloaded to Capacity Tier? - answer is no per Wasabi, only at the time of the bucket creation.

[CaliMSP]

Gostev, Anton, Bueller?

[HannesK]

Hello,

1) the backup mode is irrelevant for COPY mode
2) from Veeam side: can - but that leaves parts unencrypted. From Wasabi side (you answered it already)
3) not sure what is meant here. It just works (see FAQ again )
4) COPY means 1:1 copy of the whole repository. There is no need for new backup chains
5) Sounds like you are looking for the mapping functionality?

Best regards,
Hannes

PS: yes, support is only for break/fix issues. Not for consulting.

[CaliMSP]

Hi HannesK

Let me rephrase some of the questions since my understanding of these features has also changed since I posted it. From what I've read, the Capacity tier doesn't work with "files", but with objects (chunks) of data that are hashed and looked up in the database. So uploads to Capacity Tier are always incremental in essence since only new or changed pieces are uploaded, regardless of the "local" job methodology (reverse, forward, forever forward, active or synth. full). Existing objects/chunks are only referenced in the Veeam software to "represent" a backup file and are only stored there for as long as anything is referencing them. In theory, each chunk will only be stored once, but can be referenced a number of times. So the fulls are only really needed for locally stored backups really as in object storage they are "synthesized from the objects/chunks" via references and regardless of the number of full backups you want to upload to Capacity Tier, each object/chunk will only be stored once. Please correct me if my understanding is off here.

Now the questions that takes into account my updated understanding:

1) Object storage backups are in essence forward incremental only. Since there are no "backup files", the data is never "injected" into Capacity Tier chains, as it would be with forever incremental or reverse incremental backups locally and the job type is irrelevant really. Right?

2) this article on your site https://community.veeam.com/blogs-and-p ... ackups-275 says the job must be forward incremental or full, but I think this is only case of LOCAL immutable storage AND if the job says to MOVE (not copy) to Capacity Tier, right? So if our local job is to not immutable storage and we only do COPY to capacity tier, then we can have any backup methodology. If we want to MOVE data (to save space on local storage) then it has to be any job that does full backups (in order to seal the chain).

3) Immutability flag from Veeam side - can be flipped at any time via reconfiguring the job settings, but objects/chunks that have been uploaded prior to this change will not have the "i" flag set, so they could potentially be deleted from the storage manually or via Veeam if all of the objects/chunks belonged to a backup that didn't have the flag set initially.

4) Our full backup will take 3 days to seed to the object storage (we would have to run it Friday-Sunday). Since full backup to the Capacity Tier is only made once and then it's forward incremental (only new/changed object/chunks are uploaded and never a file), running a synthetic or active full locally will result in only an "incremental" amount of data being uploaded to the object storage on that day. Correct?

5) Is there a way to come up with a backup methodology where local backups are done daily, but what is uploaded to Capacity Tier is only data that is created during Friday night's backups (so it's uploaded over the weekend)? Right now I can't find a way to do this since Veeam will COPY or MOVE any new backups objects/chunks. Maybe a way to only COPY/MOVE GFS designated backups to the Capacity Tier in some way if we can manage them to run on only on Fridays?

6) Let's say I run a newly created job and the upload to Capacity Tier takes too long and into the time when the job is scheduled to run again, what happens then? Does the upload get paused and the local job runs, then upload resumes OR does the local job wait for the upload to the Capacity Tier to finish?

7) I've read that immutability flag is not strict, but has a "fudge factor" (block chain generation) or around 10 days. So our backups will stay immutable for about 17 days +/-, right?

8 ) We need to preserve a few backups with immutability (in case of ransomware) in the Capacity Tier, but it only needs to be for the last week. Yet, we would like to keep 60 days worth of backups in the Capacity Tier. As I understand I would set "Make recent backups immutable for = 7" and then "Restore points to keep = 60", right?

9) In this article it says "The structure of the backup chains can be different. That depends on whether your backups were created using the per-machine method (for more information, see Per-Machine Backup Files) or as a single storage, with all VMs placed into a single file. The type of the backup chain structure does not affect the offload process." In Veeam interface is says to use Per-Machine files for high performance enterprise storage or dedupe storage. It makes no sense for us to use it since we use NAS + cloud object, correct?


Sorry, I know it's a lot of questions, but I'm just trying to ensure I have a solid understanding of how the software works. Despite the fact that the interface looks simple, the layering of configuration options makes it more complex that it appears on the surface.

[HannesK]

Hello,
1) yes, correct. One could also say it's like Incremental forever with daily synthetic fulls, but in the end it's irrelevant. It's just tons of objects and not to be compared with local large files.
2) that article is about hardened repository and looks irrelevant for questions on object storage.
3) not sure what you mean. Did you try it out? It works different in my environment
4) I think the FAQ answers it

Even if you do active full backup: only the changes will be uploaded to capacity tier. There is no need to upload full backups after the initial offload / copy.

5) Not in V11. For V12 you can use backup copy jobs. In V11 it's a repository setting.
6) Backup has priority over offloads, yes. The rest is answered in the FAQ as far as I see
7) if you set 7, then it's up to 17 days, yes. That's to save API costs
sounds good, yes
9) I did not read article, because it's a different topic. I would always go for per-machine chains. It's much more flexible and will become the default in V12 anyway.

but I'm just trying to ensure I have a solid understanding of how the software works

I assume it costed you some time to write all of that... probably trying it out would have been faster

Best regards,
Hannes