news about move-VboEntityData enhancements with v8 ?

[DaStivi]

hi,
are there any enhancements in v8 regarding the move of objects/m365 data that has been in the backup allready, from a JetDB into a S3 Objectstore? in v7 this was not a feasible option for anything that had more like a few hundred GB of data... on the oneside because of the data move was slow and the most important part was to not be able to run the job in the meantime!

there where "rumors" the new version will make that better?

thx br
Steve

[Mildur]

Hello Stephan

Yes, there will be a new cmdlet to migrate backups from Jet to Object Storage. The main benefit of this new cmdlet is that it will allow you to move your backups to object storage while still running your backup jobs.

Unfortunately, this new command has been postponed to an upcoming patch. The code is already finished, and we are currently running tests on it. We plan to deliver this functionality as soon as possible.

Best,
Fabian

[dasfliege]

Unfortunately, this new command has been postponed to an upcoming patch. The code is already finished, and we are currently running tests on it. We plan to deliver this functionality as soon as possible.

If you need someone to "field-test" the cmdlet, i may could help. We have 45 Jet-Repos (300TB of data) to migrate to object asap

[dasfliege]

Any news?

[Polina]

The new migration mechanism is currently in testing/bug fixing. We will deliver it as soon as it's ready.

[karsten123]

Hi Polina. Do ship the new migration mechanism with 8.1?
Thx. Karsten

[DaStivi]

I am waiting for this too!

[Polina]

Hi @karsten123

We have to postpone it further. QA is rigorously testing it, but the process is taking longer than expected.

[karsten123]

ok. thank you Polina.
kb3067 is still the way to go?

[Polina]

Yes - for as long as it takes us to release the new mechanism

[karsten123]

we are still on v7a latest and have to upgrade soon because of the EOS of v7.
we also have to migrate >30TB from local jetDB to object storage.
what is your advice?
should we migrate the repositories with v7a and uprade to v8 afterwards or is it smoother the other way around?

[Polina]

Compared to v7a, v8 includes many new fixes, and if you see any problems on v7a, our support team will ask you to be on the latest build to get a hotfix.
You can already start planning and testing your upgrade to the latest 8.0.5.20; however, note that within a month, we expect to deliver a newer v8.1 (technically, it will be a big patch).
The new data migration functionality, once released, will also be available only for v8.x installations.

[karsten123]

thanks. we are waiting for 8.1 for sure

is ETA more like before the end of january or mid february?

[Polina]

It's hard to say; follow our updates here on forums and on the website

[karsten123]

is kb3067 safe to use with v8.1?

[Polina]

Yes, it's still relevant

[karsten123]

Hi Polina,
will the new mechanism be able to migrate backups from local JET-based repositories to immutable object storage repositories?
Thx

[Polina]

It will support migrations to regular object storage, but not immutable.

[karsten123]

ETA for new cmdlet?

[Mildur]

Hi Karsten

I moved your comment to our existing topic for the new cmdlet.
There was no change since Polina's recent comment about the ETA.

Best,
Fabian

[dasfliege]

It will support migrations to regular object storage, but not immutable.

What does this means exactly? Is the Cmdlet not able to move data to immutable object storage at all or is the copied content just not flagged as immutable?
We're waiting since months now for the new Cmdlet to transfer 400TB of data from JET to our immutable object-storage, but if this is not working at all, we don't have to wait any longer and have to find another solution.

[karsten123]

ETA for new cmdlet?

[Mike Resseler]

We are hoping in a few months. But we need intensive testing on this. If we migrate the data from Jet to OSR, and therefore transform it into an OSR format, there is a huge risk on corruption so we need to ensure all data has been verified.

[DaStivi]

i just used the old cmdlet and the ps1 script... and run again multiple errors... some sharepoint sites where left in the old jet-repo, once the ps1 script just hung up and not finished...

moving the backups is really a trusting operation... you can't really compare the repos afterwards... as the s3 one is a lot smaller because of multiple reasons (probably?!) as the jet-DB
and again, moving repos with more than like 2 or 3 TB isn't something I'd like todo right now...

[dasfliege]

What does this means exactly? Is the Cmdlet not able to move data to immutable object storage at all or is the copied content just not flagged as immutable?
We're waiting since months now for the new Cmdlet to transfer 400TB of data from JET to our immutable object-storage, but if this is not working at all, we don't have to wait any longer and have to find another solution.

Any feedback to my question above? @Mike? @Polina?

[Polina]

Hi Florin,

Immutable repositories will not be supported as a target for migration from Jet.

The support for advanced migration scenarios should come at a later phase.

[dasfliege]

Thanks for the clarification Polina.

This fact given, i'll try to find an alternative for our plan to move all our data.
Is there any way to copy VBM365 data from an immutable bucket to a non-immutable bucket with current mechanisms and maybe also lower the retention on the new bucket compared to the old one?
If this is possible, i may use one of our object storage with non immutable buckets as the target for the primary backup and only enable immutability on the copy in second tier.

[Polina]

Immutable and non-immutable repositories have different data structures, and copying the data will not work. I'm afraid I have nothing to recommend you as a workaround today.
Neither is it possible to decrease the retention period on immutable repositories with backups - you can only increase it (while for repositories with backup copies the retention period cannot be changed at all).

[karsten123]

any update for the „new“ mechanic?

[Polina]

In development/testing.