• State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 27 subscribers
  • Views 4833 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

Boot From Backup

Corrigun
over 6 years ago

Is this on the horizon at all because if it's possible it really should be. Booting a VM from a backup image is pretty standard now and it would be a HUGE leap forward.

  • 0 over 6 years ago
    This can be done by setting up an export job. Unless you mean to boot directly from the backup, I doubt that is in the road map.
  • 0 over 6 years ago
    I do indeed mean boot directly from a backup. Even a VM that's slow but booted from backup beats 20 hr export all day long.
  • 0 over 6 years ago
    It seems to me like the way the repo functions currently is basic, it can not perform fairly easy functions and the layout seems to be a mess. Even if it could boot from the repo, I think a 20 hour export would be better.

    But seriously, if the server is critical it should be setup for continuous export. If space is an issue, bring it to the exec's and let them decide. If they say no to a budget for increasing space, then when it takes 20 hours, it is on them.

    Never even tried this but one idea maybe to export only critical drives (but no data drives) so at least the machine can boot, then perform live recovery of the data drives

    I don't work for quest, so this is all my own thoughts. Someone else may have better insight
  • 0 over 6 years ago

    So here is the problem I had over the weekend. I lost a server during the export which I think corrupted the VM. My only choices then were a new 20 hour export or a BMR to a new machine.

    If RR could alternate scheduled exports to two hypervisors or if it could boot directly from a checkpoint I would be instantly back in business.

  • 0 over 6 years ago
    That makes sense. Not going to help now, but I use the native hyperV to take a checkpoint of my exports once in awhile. It takes a ton of space and is a hassle but I have been burned to many times with end case issues like you are experiencing

    I would be interesting in hearing what happened as I was under the impression that if an export failed, no changes would be made to the existing vmdk
  • 0 over 6 years ago
    I don't think it failed to export but rather exported an already broken machine. I had thought about checkpoints or just adding it to my Altaro routine but was concerned it would mess with it. Food for thought though.
  • 0 over 6 years ago
    This maybe a good end-case to send the logs to someone knowledgeable at quest. If the backup worked on broken machine and exported that broken machine. MAYBE there is a way the backup could have noticed the issue and failed the backup instead.

    Long shot, but maybe worth a try for a future release