edh wrote: ↑Feb 20, 2025 6:56 pm
This is our experience—keep in mind that we all recognize that Blob is not S3 and that many S3 implementations are not alike.
We migrated a 200TB bucket from Wasabi to our Minio, and it worked correctly. The migration took a weekend because Wasabi limits the number of concurrent connections per access key. We achieved an incoming traffic of 14Gbps, limited by our backend.
To do this, we made sure that the bucket had the same name in both the source and destination to maintain the same paths at the Veeam Office 365 level. We used a migration tool that copies the object metadata and can handle hundres threads.
Obviously, while the data is being copied, you must remove it from the source VBO to ensure there is no activity.
Once all the objects have been copied, you create a new storage and perform a resync. When the first task finishes, you will see all the old points.
This method is not officially supported, so I recommend testing it with your own tenant and with just a few GBs.
Hi,
is there an update to the original feature request?
An official way would be very interesting for us, as we cannot scale our S3 systems infinitely and offload migrations to other data center areas are very likely.
@Polina
it would be nice if you could implement it without the need of a rescan like it is today. Migrating buckets is easy but the rescan of the new bucket (especially SP/Temas/OD) often takes a lot of time and let us miss SLA`s...
"On the roadmap" has been known to mean several years or never. We need to have a solution for this now. Flexify.io was suggested. Any other suggestions?
@DanielJ
If it is just about migrating your data to a different bucket, there are plenty of solutions available for this.
We have around 2.5PB in 300 buckets and most of the data was migrated at some point to a different/new on-prem S3 storage system.
We use Rsync for this. Very easy and reliable.
But after migrating the data you need to create a new repo (with your new bucket) and therefore the data needs to be rescanned.
We have one of the largest VBO environments globally. Doing lifecyicle managent on de back-end is now simply not possible.
Enabling us Users to migrate 1 repository to another would absolutely help this goal. It would enable us to move away from storage vendor A to storage vendor B.
If anybody from Veeam wants to talk to help define this feature, please feel free to reach out.
I’ve moved your question to the existing topic.
We don’t support this type of bucket migration, and there’s no guarantee from us (Veeam) that a repository will continue to work without errors for backup and restore after such a migration.
May I ask about your use case for the migration? Is it between buckets from the same object storage vendor, or are you looking to switch to another S3 service provider or device?
We have S3 storage on premises. One is now out of support, and we are implementing a new system. The migration will take place from one Cloudian to the other.
It always seems so surprising to Veeam that people want to do this. But of course anyone who has any on-prem storage solution needs to lifecycle manage it. Support for this type of migration should have been there from the very beginning, not as an eventual possible future "nice to have" afterthought.
This request is critical. Without a native capability to migrate data between object repositories, customers will be forced to use unsupported methods such as rsync to move data, simply because there will be no other option. The alternative is allowing the storage array to fill up, which would stop all operations. Faced with a choice between downtime and an unsupported workaround, it’s easy to see which path most customers will take.
Yes, I'm on board with that. The possibility of scaling out would also be an additional idea. The data in M365 can grow quickly during migration, and not every S3 storage solution can handle so much data in one bucket. Therefore, it would simply make sense to split the data.
Hi,
For those who have already completed the migration, how did you verify that everything was working properly after the transfer? Did you simply run backup/restore tests?
Is there any other way we can test the transfer to be absolutely sure (200%) that the data is valid?
I’ve migrated one small bucket and it seems to be working, but before proceeding with the rest, I want to make sure nothing was broken in the process.
Thank you!
Hi Andre,
we tested it before we started with our M365 backup service some years ago.
We tested different kind of migrations and tools. We could not see any issues. Even migrating from S3 to Azure Blob or vice versa worked properly.
After the migration was done we tested it exactly like you expect it. Simply test Restore/Backup. Be aware that a rescan might take some time (especially for large SP buckets).
After our initial tests we migrated some hundred buckets with Petabytes of data by now without encountering any issues!
Can you remember how long rescans were taking for 100-200 TB orgs? We are about to get pushed into using "supported rsync" as well. In addition to that, we have a rather large org we might need to reconfigure on another "controller", which will trigger a rescan,etc. Are we talking hours, days or weeks?
Bjoern_ch wrote: ↑Sep 29, 2025 6:58 am
Hi Andre,
we tested it before we started with our M365 backup service some years ago.
We tested different kind of migrations and tools. We could not see any issues. Even migrating from S3 to Azure Blob or vice versa worked properly.
After the migration was done we tested it exactly like you expect it. Simply test Restore/Backup. Be aware that a rescan might take some time (especially for large SP buckets).
After our initial tests we migrated some hundred buckets with Petabytes of data by now without encountering any issues!
Just a reminder that these types of migrations are not supported and can lead to issues with backup chains. Recently, there was a support case where a customer migrated an object storage repository using third-party tools and was unable to continue the backup chains, even though restoring from migrated restore points was successful.
Veeam Customer Support and R&D teams will not be able to assist in such cases and will advise you to create a new repository and start your backups from scratch.
Official migration methods for object storage repositories are being worked on, but there is no ETA at this time.
