KB4835

[Polina]

@DaStivi
Please read the KB carefully - currently verification and repair is only provided to object storage repositories. Verification for Jet has not yet been delivered and is expected within the next few weeks.

[DaStivi]

Alright, sorry really just overlooked this for jet ...
Can you give us a technical explanation for jet ?

As of for immutable S3 I can somehow imagine it... Even there not really.. when defective items has been found they needs to be flagged, this could be a issue I guess... But new version can just be downloaded of source still exist... But yeah some more complications for immutable S3 ...

But in jet Repos ?

[Polina]

Jet has a data structure completely different from obect storage, and - potentially - a longer history of upgrades. Technically, it's no easier than object storage, and in certain aspects even more complicated.

[karsten123]

how is the way to go for repositories, which are not used of active jobs?

[Polina]

It doesn't matter if there are any active jobs or not - checks and repairs are performed on the repository level.

[karsten123]

i dont get it. can you please elaborate.
how does the redownloads work in this case?

[Polina]

Hi Karsten,

To repair impacted files, you run Start-VBORepositoryRepairSession for a selected repository, and it starts a special repair session that runs independently from any jobs.

[b.vanhaastrecht]

@b.vanhaastrecht I expect closer to the end of this month.

Hi @Polina, this prediction has been overshoot by more than a month. Do you have a new ETA?

[Polina]

Hi Bastiaan,

That's why I don't like providing estimates - you never know how many things to fix come up. We're almost there.

[b.vanhaastrecht]

On the other hand we have our customers who are very worried about their backupped data being accessible, and we need to give them some kind of prognoses. Please understand that this is a tough one to defend, having backup data available is why they have Veeam/Backup software. This is taking way more time than acceptable. Bugs happen, but by the way Veeam is handling this time wize, my support for this product has been badly damaged.

[msobm]

I also would like to say that for a Company that sells Backup-Software, a bug that results in Data loss shouldn‘t take that long to fix.
Regardless of any complexity or hard work that needs to be done, the time it takes for veeam to fix this is neither acceptable nor understandable.
This should be a Prio 1 issue and it is clearly not. If it would be, the issue would be fixed long ago (and for fixed I mean that any possible data loss could be restored/recreated).
I hope the support for the missing repositories are coming in the next days.

[DaStivi]

Is there a way to check how many items in a VBORepositoryRepairSession have already been processed? It would be helpful to get more status output from "Get-VBORepositoryRepairSession -Id xxxxxx" besides just showing that it’s still running.

I tried checking the logs but didn’t find anything obvious.

[Polina]

@DaStivi

There's no straightforward way. In the logs, you can check for the "File data consistency checked (web: {WebUniqueId})" messages - each of those indicates that one web was repaired.

[DaStivi]

thx,
my projection times from smaller repos (50TB: integrity check: 1h, repair session: 2h) where quite correct to my largest one (400TB: integrity check ~9h, repair session: ~19h)
("onprem" S3 Storage, Netapp Ontap S3)