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.