• State Suggested Answer
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 28 subscribers
  • Views 680 views
  • Users 0 members are here
Options
Related

Getting this error couple times a day - Failed to mount volume image(s): (Volume Labeled 'System Reserved')

johnny
5 months ago

I have taken a look into several different areas and found a related post about this, https://www.quest.com/community/rapid-recovery/f/forum/26635/broken-volume-image?ReplyFilter=Answers&ReplySortBy=Answers&ReplySortOrder=Descending

when i am looking into the type it does show that system reserved is 'incremental, orphan' and the post is saying that if it is showing orphan than it is a serious issue but is there any ways i can diagnose it further? if needed i can include more information just let me know 

  • 0 5 months ago

    Good morning. If it says 'orphan' anywhere, that more or less means there is missing data and/or data that can't be read. As the RP chains are one big long chain of incremental RPs it's like missing a rung in a ladder, all the subsequent rungs after that are now unusable or 'orphaned' since the preceding is missing. Is the orphan on the SRP volume itself when you expand the RP? Or is it on the data volume(s) themselves. There are a few causes that can lead to this, some manual (manually deleting recovery points) some environmental (abrupt loss of power on server and/or storage). If you open up a ticket with Quest and provide them the core Log they have a utility to tell you where any and all orphans lie. Hopefully it is tied to that one Protected Machine. If you have a duplicated copy through replication, you're welcome to delete all, in that RP chain, and let the Quest DB catch up and purge that data from the repo and the DB. Give it an hour or two to let the DDs run, gracefully shutdown the core service, reboot, then rebase. I'd still recommend getting a ticket open so you KNOW where the orphans are. Newer and newer versions of RR are much, much more resilient to orphans, but kinda like lightning, it's hard to provide absolute data integrity if the core is in the middle of a rollup or other repository task and the power happens to go out. 

  • 0 5 months ago in reply to phuff

    Yes i can start a ticket i believe. also when i do look under the drop down it does show that its only the SRP volume. I am doing these backups for another company and just started this position so I am unsure how the backups work i can see that there are the logs that i can copy and show into a ticket. as far as deleting and testing these things out i will talk with my company and see if that is something that they would like for me to do 

  • 0 5 months ago in reply to johnny

    If it's only the SRP you might have dodged a bullet there. There is a log utility that Quest provides that gathers all kinda of data so they can see basically everything that was happening at 'x' time that the job failed - it'll grap system logs/app logs/sys info, vss writers, a lot: 

    https://support.quest.com/rapid-recovery/kb/4041267/how-to-run-the-info-gathering-tool-support-bundle-for-service-requests

    There is a separate way to remove just that volume from the Recovery point chain too, which they can do if need be. Replication and archiving can help you prevent the loss of data part too, as both options would duplicate the data elsewhere. As we are talking about orphans the investment of a UPS for the RR server and it's storage/repo goes a long, long way my friend.