VBO migration to Wasabi


Userlevel 5
Badge

This quick and nerdy video is 10 mins long and shows you how to add a wasabi bucket to VBO365 and use powershell to migrate the backups from on-prem to the cloud. 

 


11 comments

Userlevel 7
Badge +3

 @mrmccoy007 : Thanks for sharing, Its good !

Userlevel 7
Badge +5

Very informative!! 

Userlevel 7
Badge +6

Very nice share.  Nice to see things like this and Wasabi is pretty good for OBS.

Userlevel 7
Badge +6

Very informative video. Thank you.

I will defintely have a closer look at Wasabi...

Userlevel 7
Badge +4

@mrmccoy007 

Thanks for the video :)

Is there any way to calculate how long the migration would take. I need to migrate 10TB of O365 Data to a S3 compatible Object Storage (OnPremise) and I am reading in the R&D Forum that this process could take very long to finish.

Jobs should be stopped before starting the migration job. If it takes days, then that’s not really an option.

Userlevel 5
Badge

Unfortunately we do not have a tool for estimating migration time. If migrating everything at once is not an option, you may want to create new jobs pointing to object storage and separate them by exchange job, sharepoint job, etc…. This is actually a good practice for larger environments anyway.  

Userlevel 7
Badge +4

Thanks for the answer.

We have some small tenants bellow 200-400GB and some tenants are bigger. I will test the script first for the smaller companys.

Would you create one bucket per company or as stated in the best practice guide for each workload a company (to create different Retention Policys for each workload)?

Userlevel 5
Badge

I would have a bucket for each company just to keep each company’s data separate. Retention is set on the repo itself so you may also want separate repos for same companies if data retention differs between employees/user. 

Userlevel 7
Badge +5

@mrmccoy007 @Mildur  I always create at least 3 different jobs (Sharepoint/Teams, Onedrive, Exchange) and a corresponding repository (Sharepoint/Teams, Onedrive, Exchange). No matter the size of each service. Why? Then it is possible to have a different retention per service. You never know that a customer asks you to change the retention, at that way you are more flexible. I also read that it is a best practice to split up the jobs for performance reasons.

Userlevel 7
Badge +4

@Nico Losschaert 

I am doing that too with the legacy repos (local disk). That was easy.Create 3 folders for each Workload Type.

Now I have S3 Buckets to migrate and I am not sure If I go with Bucket per customer or Bucket per Workload/Customer. Our Customer has always the same Retention for every workload. 

Userlevel 7
Badge +5

@Mildur , I just create one bucket for each customer and a folder for each workload type

Comment