• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 27 subscribers
  • Views 10019 views
  • Users 0 members are here
Options
Related
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

Big Problem

itguy
over 7 years ago

Hello

         I was running the last version of AppAssure prior to the Rapid Recovery change. I should have upgraded, but everything was working fine....famous last words.

This post concerns the server that was running AA core, NOT the repository or offsite backup replication.

So last evening, the RAID controller decided to self-immolate and take the drives with it. Completely corrupted them.No rebuild possible and no controller anyway.

I had about 30 machines protected, custom schedules, 4+ years of back ups. and around  20TB in my one repository.

Do i REALLY have to start from scratch with Rapid Recovery? Setup all those machines, offsite replication, and local repository?

I've tried entering the path to my local repository, but RR wants to make a new one, not recognize the one i have,

The portal keeps track of machines etc, i wonder if there may be a config. file somewhere there? :)

Am I out of luck?

Thank you

 

 

  • 0 over 7 years ago
    Hi itguy,

    With the scenario you described, their should be no reason for the need to start over. What error are you getting when trying to "open existing repository" with Rapid Recovery? Once you get the repository mounted, the protected machines will display as recovery points only. Then you'll be able to re-add the machines to protection and then re-configure replication to the target core. The only issue I can see you having is that without a saved config file or registry branch, the schedules will be lost.

    Derek
  • 0 over 7 years ago
    Thank you for the reply.

    Last evening i found two corrupted files in that repository folder. My error must be related to them. They are now encrypted and gone forever. I can still see all the other files of course.

    3 weeks ago a laptop with a share to that drive brought in an infection. It was stopped in 0.7 seconds, but it must have got to that share.

    I can still see the 7.1TB repository file, etc, but possibly one of the encrypted ones is a .cfg file.
  • 0 over 7 years ago
    There should be 8 files located in each extent of the repository. Two XML files and the following:

    Deletion.queue
    dfs.bmap
    dfs.mbr
    dfs.record_ids
    dfs.records
    dfs.rmap

    Which files are infected? If the 6 files above are not infected, then a support engineer might be able to assist and recreate the infected XML for you to get the repository mounted.
  • 0 over 7 years ago
    The two .xml's are history.
  • 0 over 7 years ago
    Sorry, too many windows...sigh....The two are gone, but the six you referenced are there. I already attempted re-naming with .xml extension, but no dice...unless the core is looking for specific names?
  • 0 over 7 years ago
    The XML files maintain specific details about the repository. I recommend that you open a support ticket to see if we can pull together enough information to recreate the XML.