Upgrade to 6.1.x from 5.4.3. What is the current best / safe practice with rollback?

Question

I realise that the documents simply state you can upgrade as long as the core server meets certain criteria yada yada. 
 
 However i'm also aware that certain people (Tudor or Anton?) have in the past recommended other safer ways to upgrade. I require a way to be as safe as possible with the upgrade, it's pretty hard to have a backup of your 30TB repository so that you can roll back. I also don't have spare hardware capacity to do a replicated migration. 
 It used to be something along the lines of 
 backup the registry keys. note config of your repositories stop the core remove repositories from registry remove agents from registry? Upgrade Check it seems ok stop core import repository / agent registry keys.... start core and hope Between 5.3 & 5.4 it needed to upgrade the repository, it would appear that 5.4 > 6.1 doesn't need to do that. So am I safe in retaining the registry keys (or even an image backup of the system & application drive (not repositories) and performing the upgrade. 
 If this fails, can I revert to 5.4 with the repository already defined and use that as my rollback 
 What happens to the dedupe cache, i'm assuming that this is retained and not lost. 
 Also, what are the latest patches available for 6.1.1 that we really should install? 
 
 Sorry for lots of questions, but I want to ensure that this is as seamless and safe as possible before we progress or get approval.

Tudor.Popescu · Answer

Hi fredbloggs: 
 Sorry to disappoint. The upgrade from 5.4.3 to 6.x is irreversible as the repository structure changes. For instance, the recovery points IDs in 5.4.x are identified through two elements: AgentId and Timestamp. In 6.x, recovery points are identified through 3 elements: a GUID, the AgentId and the timestamp. This was necessary due to the new archiving paradigm (kind of read-only repository) and the introduction of DR appliances as secondary storage (more about DR appliances here ). 
 Please note that -- and I am going to shout here for the benefit of other readers, that after upgrading to 6.1.x A FULL REPOSITORY CHECK IS TRIGGERED. We had customers who were unaware of this and did not plan the time for the job appropriately. 
 If you MUST have a reversal path, the only sensible approach saving the registry settings AND archiving the data prior to upgrading. Needless to say that, for a 30TB of data this is not a trivial task. 
 RapidRecovery 6.1.1.137 is pretty stable, surely better than 5.4.3 and chances that something goes wrong are small. There are no general use patches available. Moreover, the release of a new version is right around the corner. 
 Moreover, upgrading is advised as 5.4.3 is getting close to the end of its life (we still support it but we cannot involve the dev team in writing patches if some specific issues are found). 
 If you are not sure how to proceed or you would like to bounce some ideas as of the best specific steps to take in your environment, please open a ticket with us and we will help you out.

Tudor.Popescu · Answer

Hi fredbloggs: 
The repository check after the upgrade should take about the same time as the regular full repository check that is triggered after a dirty shutdown of the core service. As you already know this depends in turn of the available IOPS on the storage and the other resources available. I would venture to guess that assuming all resources average (and no dedupe cache size excess), three hours give or take would suffice for 30TB. I just performed out of necessity a full 10TB repository check (90% full) on a less than average system with 1.5GB of dedupe cache and it took about 45 mins.