-
Notifications
You must be signed in to change notification settings - Fork 22
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
Implement backups of the server #24
Comments
The page above is 404. Also, do you reckon backups are a little out-of-scope for the TODO application? |
It's at https://github.com/djmitche/taskchampion/blob/c2c2a00ed507929e68358931e174e1ada5b6b57c/docs/src/plans.md now This is definitely a longer-range feature, but I think it's an important one for a robust sync system. With backups, even if the server loses all of its data, sync can continue, as it will just restore from a backup stored with one of the replicas. |
Adding this to the protocol later won't be a breaking change (it will just be a header from the server saying "hey plz 2 back me up?" which older replicas can ignore), so I don't think this needs to go in this milestone. |
Moving this back out of |
Looking back at the original proposal, the idea is only to back up recent versions (which are just blobs as far as the server is concerned) -- not to back up the entire server state. Then if the server admins recover from, say, a nightly backup, the clients can supply any additional versions created since that backup. I don't think this requires any additional support on the server. Clients already see every version -- either uploading it to the server, or downloading it after another client has uploaded it. So, all we need to do is store "recent" versions locally. If we go to upload a new version and the parent version is gone (because the server was restored from backup, for example), we can try uploading some of those older versions, thereby restoring the server to the most recent state. That said, this seems like a really niche feature, and while fairly simple, I don't know if it's worth the complexity and client-side storage cost to implement it. |
In this design, the server is little more than an authenticated storage for encrypted blobs provided by the client. To allow for failure or data loss on the server, clients are expected to cache these blobs locally for a short time (a week), along with a server-provided HMAC signature. When data loss is detected -- such as when a client expects the server to have a version N or higher, and the server only has N-1, the client can send those blobs to the server. The server can validate the HMAC and, if successful, add the blobs to its datastore.
(updated to include the proposal directly, instead of via a link)
The text was updated successfully, but these errors were encountered: