etcdctlv3: snapshot/recover design

[xiang90]

Snapshot

Snapshot command should get a point-in-time consistent snapshot of the v3 KV space

Snapshot command should not snapshot any configuration related data like clusterID or memberID.

TODO: handle lease?

TODO: support incremental snapshot?

Recover

Recover command should write configuration data provided by user like (--initial-cluster, --initial-token, etc..) and create correct member dir.

Recover command should take a snapshot and put it into the right location in the created member dir.

[xiang90]

/cc @heyitsanthony

[colhom]

@xiang90 it looks to me like recover command is roughly what we called set-config command here, plus some additional logic to set up the data directory?

Will recover do integrity verification of the snapshot and return a zero exit code only if it's good? Is that even necessary?

[xiang90]

it looks to me like recover command is roughly what we called set-config command here, plus some additional logic to set up the data directory?

Right.

Will recover do integrity verification of the snapshot and return a zero exit code only if it's good? Is that even necessary?

Probably we can add a --verify flag? So etcdctl can help to verify the snapshot. Or the verification will delay to server startup time. On the other side, we do expect user to verify snapshot after they store it somewhere. So a force verification seems to be redundant for some use case.

[colhom]

@xiang90 how much validation is done on etcdctl backup? Assuming that whatever backup creates with exit code 0 is "gauranteed" to be valid for restore on any etcd 3.x, the --verify flag would be redundant. Verifying the snapshot hasn't been corrupted between backup and restore is out of scope, for sure.

[xiang90]

@colhom etcdctl backup guarantees to return a good snapshot when exit with 0.

[colhom]

Ok then, imho we don't need a --verify flag for restore.

[xiang90]

@colhom I feel so. Thanks!

[heyitsanthony]

I think auth and alarms would need special handling too.

Maybe it'd make sense to have a special etcd KV space and use the KV machinery already in place (watchers, get) instead of managing custom buckets?

[xiang90]

@heyitsanthony In most of the cases (if not all), users just want to backup the static data not dynamic ones like leases, watcher or alarm I think.

[xiang90]

@heyitsanthony Shall we close this one?

[heyitsanthony]

@xiang90 yeah seems like it's all hammered out