This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Long term recovery options or what happens if the core doesn't contact the license server? (or have any licenses)

I need to confirm what happens if a customer stops paying for the system (we are an MSP) but wants to retain access to their old backups.  

 

For non-trial licenses, the Rapid Recovery Core contacts the license portal once every hour. If the Core cannot reach the license portal after a 10-day grace period, the Core stops taking snapshots.

I have seen the above.  Does this mean that I can still perform mounts, restores and generally still view old archives to restore old data?

 

  • What if they wanted to remove that machine (core) but archived the Repository (and structure / registry) and RR install media to tape would they be able to get it back if requested?
    • i.e. build a machine, install the RR version that they saved
    • Restore / Rebuild the repository
    • Mount the backups and look at that
  • Would this be the same if they simply archived it to S3 storage?  Can they just retain that information?
  • Going further, if they were to retain a copy of the repository (or logon details to amazon S3 storage) would they be able to install the current version of RR and mount that repository or mount / restore from archive?  This is required for compliance purposes.

At present we have been exporting RPs to VHD files and backing those up to tape.  This way i'm pretty certain we will be able to mount VHDs in 10 years and restore data as required, however it'd be nice to save that disk space (D2D2D2T is quite excessive)

 

If that doesn't make sense, please ask :)

  • Hi FredBloggs:
    You are correct, if the license/service agreement expires you are barred from doing new backups but your data is still accessible and all non backup/replication (new data) operations are available. Since your goal is keeping old data, you should be OK.
    Ten years is a long time (about an eon technology wise) so you are right to plan properly for the future.
    I would do the following:

    1. Archive all data of interest either locally to long term storage or to S3 or Azure. Archives created with RapidRecovery 6.x can be attached as read only repositories, even without downloading them from the cloud.
    2. Check the archive to be sure that it is OK (there is a function built in the core)
    3. Create a VM with the current version of Windows and the Core installed as, even if you have the appropriate Rapid Recovery Core installer, you do not know if it would work on a future version of Windows. Attach the archive, make sure that it works and detach it again. Upload the VM to the desired long term local storage or cloud location.
    4. Document all the steps -- even if they look trivial to you as whoever will be called to restore the data may be completely unfamiliar with the current version RapidRecovery. Make a few copies of the notes and store them strategically so they are easily found (on the VM, in the DR notes/manifest etc).
     
    When the need arise you (or whoever is requested to perform this task) extract(s) the old VM to a hypervisor that still supports it and attach the archive (no need to download it from the cloud) to the core. You will have access to the data.
     
    Other important precautions are related to file restores. It is unlikely that the permission structure will make any sense at that time (domain/users may have changed). As such I would suggest provisioning the Core VM with an application capable of impersonating the local System account so you do not have difficulties browsing through the files you need to restore without worrying about ownership or other NTFS permissions issues. An example of how this can be worked out can be found in KB#226853.
     
    Please let us know if this works for you.
  • Thanks, that's pretty much as I expected. At least gives us an option
  • Actually, there is one thing you have noted that I would have done differently.
    You stated that you would have the virtual machine with RR installed and ready to rock and roll. You'd then just archive off that machine.

    Your (3) above, I was going to just save the OS media and installation software. But it appears that the software won't let you configure it until you have installed the license. Can potentially save that but i suspect it'd need to connect and then fail as an invalid license so not work.

    I can't test that since I don't have a license to play with and disable to see what happens. So yes, I guess I need a VM archived off with the tape to recover the data.

    Have you been able to confirm what happens when you start your VM and the license is invalid? Is there a time when it will just not let you in to the console?

    So I guess I need an image of a core in a format that can be read by the hypervisor of the day or migrated as required. I guess back to VHDx of the RR Server & core but nothing else on those volumes, including dedupe cache as that'd be too much data change every day.
  • Hi fredbloggs:

    The way the software is now, it will allow you to log in the GUI if any type of license (trial or real) is installed. After the license expires (or the license portal becomes unavailable), you are still able to log in the GUI. Nobody knows if all will be the same X years from now -- technology moves way too fast to be able to foresee it. This is why, a frozen "point in time" is a good precaution. Please note that there is (almost) nothing to configure to the "safe" core. You would use it just to attach the archive.

    One more thing -- if you have the agents number based license -- you can spin up as many cores as you wish. If a core does not connect to the portal for 30 days or so (1), it will be automatically expunged. (You should be able to remove it from the portal manually as well (2)).

    Hope that this helps.