Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Restore backup to new VM #59

Open
YanChii opened this issue Jan 26, 2017 · 4 comments
Open

Restore backup to new VM #59

YanChii opened this issue Jan 26, 2017 · 4 comments

Comments

@YanChii
Copy link
Contributor

YanChii commented Jan 26, 2017

When restoring backup, user may choose the VM, into which the data will be restored. It would be usefull if there was an option to restore to new server.
Specifically: first item in the list of VMs can be <<new VM>> and new VM will be created according to definition of original VM.
Currently, the user has to create and deploy new VM manually before the restore.
Jan

@YanChii YanChii added this to the 3.0.0 milestone Jan 26, 2017
@dn0
Copy link
Member

dn0 commented Feb 22, 2017

Reasons why this is complicated:

  • it requires a sequence of tasks (define a VM, deploy/stop the VM, restore a backup into the VM)
  • the VM definition has many open questions (assuming that we take the default values from the backed-up VM's configuration)
    • which compute node? (what if there are no resources)
    • should we preserve the disk IDs?
    • if it is the first disk, should we create a second disk?
      • if it is the second disk and the first disk has an image that no longer exists?
    • what about NICs, should we copy the network configuration as well?
    • what if there are no free IP addresses?
  • ...

All of this would be much easier if we had a VM template generator that would be able to take a VM.json configuration and generate a VM template (which is a set of parameters for the vm_define* API calls). Lets return to this task after we solve the VM template problem.

@dn0 dn0 closed this as completed Feb 22, 2017
@YanChii
Copy link
Contributor Author

YanChii commented Feb 22, 2017

Ok, I agree. I see the complexity. Moving to my nice_to_have list.

@dn0 dn0 removed this from the 2.5.0 milestone Mar 1, 2017
@dn0 dn0 reopened this Apr 1, 2017
@dn0 dn0 added this to the 2.7.0 milestone Apr 1, 2017
@dn0 dn0 modified the milestones: 2.7.0, 2.8.0 Oct 30, 2017
@dn0 dn0 removed this from the 2.8.0 milestone Nov 6, 2017
@marcheschi
Copy link
Contributor

Hi
I think this could be a very important enhancement, especially when an entire node breaks for some reason.
I think it has to work like the command "migrate", but with the ability to migrate from backup multiple VM to a new real server or distributed to the other nodes.
Thank you
Paolo

@dn0
Copy link
Member

dn0 commented Nov 24, 2017

Hi @marcheschi :)
We already have this feature; this issue is mostly about enhancing user experience. What you can do now regarding backup restore:

  • You can always create and deploy new VM inside Danube Cloud and restore the backup into the VM - this can be performed also in the GUI (this issue is about automating the define/deploy process of a blank VM). Btw, this feature can be used to clone VMs.

  • In case the compute node with the mgmt VM completely breaks, you can restore any VM backup from the backup node by using command line tools provided on the compute node. Usually, you would first restore the mgmt VM and then restore other VMs via the GUI. We will document this soon - Document disaster recovery scenarios esdc-docs#30

# for free to join this conversation on GitHub. Already have an account? # to comment
Development

No branches or pull requests

3 participants