Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Add recovery feature #2

Closed
edolstra opened this issue Mar 21, 2012 · 2 comments
Closed

Add recovery feature #2

edolstra opened this issue Mar 21, 2012 · 2 comments
Assignees
Labels

Comments

@edolstra
Copy link
Member

If the state file of a Charon deployment is lost, it would be nice if it could be reconstructed automatically given the UUID of the network.

A related feature would be to enumerate all known machine instances in all backends (along with their network UUIDs).

So you could recover like this:

$ charon discover-machines
ec2 33bced96-5f26-11e1-b9d7-9630d48abec1 foo
ec2 33bced96-5f26-11e1-b9d7-9630d48abec1 bar

$ charon -s ./state.json recover 33bced96-5f26-11e1-b9d7-9630d48abec1
@ghost ghost assigned edolstra Mar 21, 2012
aszlig added a commit to aszlig/nixops that referenced this issue Nov 4, 2013
The increase of the server name length was part of my wishlist to the
folks at Hetzner which they implemented in the meantime (before the
maximum length was 50 chars which leaves room for the UUID but truncated
host names at 6 chars). So thanks to the Hetzner Robot team for
increasing that limit.

For us, this means that we can store the full vm_id in the Robot which
currently only makes it easier to distinguish individial NixOps hosts in
the Robot.

In the long term however, it could be useful reconstructing/recovering
deploments (see NixOS#2).

Signed-off-by: aszlig <[email protected]>
aszlig added a commit to aszlig/nixops that referenced this issue Nov 4, 2013
The increase of the server name length was part of my wishlist to the
folks at Hetzner which they implemented in the meantime (before, the
maximum length was 50 chars which leaves room for the UUID but truncated
host names at 6 chars). So thanks to the Hetzner Robot team for
increasing that limit.

For us, this means that we can store the full vm_id in the Robot which
currently only makes it easier to distinguish individial NixOps hosts in
the Robot.

In the long term however, it could be useful reconstructing/recovering
deploments (see NixOS#2).

Signed-off-by: aszlig <[email protected]>
@LiliDeng LiliDeng mentioned this issue Mar 7, 2016
@jezen
Copy link

jezen commented Aug 16, 2016

Any word on this? Having to maintain a state file which could potentially be lost is keeping people away from using NixOps.

Also I have lost my state file and I am not sure how to rebuild it.

@grahamc
Copy link
Member

grahamc commented Apr 20, 2020

#1264 implements state backends, and those backends could implement backups.

@grahamc grahamc closed this as completed Apr 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants