I’m sorry to hear your migration hasn’t been smooth.
Can I ask what is the size of the 2.6 backup file?
Migrations can take a while to run, and it is a memory-hungry process. But there are some strategies to optimize this:
Remove unecessary data from your 2.6 instance
Our strongest recommendation is to use retention-policies in your 2.6 instance to remove some data.
Ideally you want to aim to get the document count in RavenDB down to <150k documents (we’d be interested to know how many documents you currently have?). You can find the document count by viewing Raven through the Octopus Manager. The document count is in the footer of the Raven studio.
You can also run the process mentioned in this ticket to shave some documents that won’t be imported anyway.
You can always retain the original large backup somewhere if you require it for audit purposes.
As a pre-emptive warning, if you have a very large deployment history, you may be best to do a staged running of the retention policies, so not to cause Raven to freeze with a large number of deletions.
For example, if you have days-to-keep set to 500, dial it down to 400, then 300, etc.
Give the machine as much RAM as possible
The more RAM the server executing the migrator has access to, the faster the process will complete. If you can temporarily dial this up to a big number (e.g. 64GB), this will help.
No Logs and/or MaxAge
There are configuration options which allow you to ignore task logs, and/or documents past a certain age. This can greatly speed-up the migration.
The logs can be imported later using the
--onlylogs option if required.
I hope this helps. Even with these strategies, a migration may take multiple hours.
Please let us know the result?