{"action":"created","issue":{"url":"https://api.github.com/repos/coreos/etcd/issues/3791","labels_url":"https://api.github.com/repos/coreos/etcd/issues/3791/labels{/name}","comments_url":"https://api.github.com/repos/coreos/etcd/issues/3791/comments","events_url":"https://api.github.com/repos/coreos/etcd/issues/3791/events","html_url":"https://github.com/coreos/etcd/issues/3791","id":114527334,"number":3791,"title":"Question about a case of permanent quorum loss + disk full","user":{"login":"mitake","id":1173955,"avatar_url":"https://avatars.githubusercontent.com/u/1173955?v=3","gravatar_id":"","url":"https://api.github.com/users/mitake","html_url":"https://github.com/mitake","followers_url":"https://api.github.com/users/mitake/followers","following_url":"https://api.github.com/users/mitake/following{/other_user}","gists_url":"https://api.github.com/users/mitake/gists{/gist_id}","starred_url":"https://api.github.com/users/mitake/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mitake/subscriptions","organizations_url":"https://api.github.com/users/mitake/orgs","repos_url":"https://api.github.com/users/mitake/repos","events_url":"https://api.github.com/users/mitake/events{/privacy}","received_events_url":"https://api.github.com/users/mitake/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-11-02T05:23:07Z","updated_at":"2015-11-03T05:40:20Z","closed_at":"2015-11-03T05:40:20Z","body":"Hi etcd developers,\r\n\r\nI'm considering a case like this: an etcd cluster loses quorum permanently (1 survivor node and 2 dead nodes) and there's no space for `etcd backup` in the survived node.\r\n\r\nCurrent standard methodology of handling a case of permanent quorum loss is `etcd backup`. Removing failed nodes forcibly isn't provided intentionally for safety reason (https://coreos.com/etcd/docs/latest/runtime-reconf-design.html).\r\nHowever, `etcd backup` needs extra disk space for saving data and its size is proportional to the size of data dir. If the data dir is large (e.g. 80% of the drive), allocating the space for saving data will be impossible.\r\n\r\nTherefore I think providing another way of recovery would be valuable for handling such a case. For example, an offline tool for removing failed nodes from the raft log of living node. How do you think about this idea?"},"comment":{"url":"https://api.github.com/repos/coreos/etcd/issues/comments/153248039","html_url":"https://github.com/coreos/etcd/issues/3791#issuecomment-153248039","issue_url":"https://api.github.com/repos/coreos/etcd/issues/3791","id":153248039,"user":{"login":"mitake","id":1173955,"avatar_url":"https://avatars.githubusercontent.com/u/1173955?v=3","gravatar_id":"","url":"https://api.github.com/users/mitake","html_url":"https://github.com/mitake","followers_url":"https://api.github.com/users/mitake/followers","following_url":"https://api.github.com/users/mitake/following{/other_user}","gists_url":"https://api.github.com/users/mitake/gists{/gist_id}","starred_url":"https://api.github.com/users/mitake/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mitake/subscriptions","organizations_url":"https://api.github.com/users/mitake/orgs","repos_url":"https://api.github.com/users/mitake/repos","events_url":"https://api.github.com/users/mitake/events{/privacy}","received_events_url":"https://api.github.com/users/mitake/received_events","type":"User","site_admin":false},"created_at":"2015-11-03T05:40:20Z","updated_at":"2015-11-03T05:40:20Z","body":"> I think the limit of data dir, considering v3 case, is smaller than 30GB. \r\n\r\nI didn't notice the limit. 60GB would be reasonable space for users. Thanks a lot for your comments!"}}