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

Implement backups of the server #24

Open
djmitche opened this issue Nov 22, 2020 · 5 comments
Open

Implement backups of the server #24

djmitche opened this issue Nov 22, 2020 · 5 comments
Assignees

Comments

@djmitche
Copy link
Collaborator

djmitche commented Nov 22, 2020

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)

@savchenko
Copy link
Collaborator

The page above is 404. Also, do you reckon backups are a little out-of-scope for the TODO application?

@djmitche
Copy link
Collaborator Author

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.

@savchenko savchenko added this to the Future milestone Apr 28, 2021
@djmitche djmitche self-assigned this Sep 6, 2021
@djmitche djmitche modified the milestones: Future, v0.5.0 Sep 26, 2021
@djmitche
Copy link
Collaborator Author

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.

@djmitche djmitche modified the milestones: v0.5.0, Future Nov 17, 2021
@djmitche djmitche reopened this Jun 8, 2024
@djmitche
Copy link
Collaborator Author

djmitche commented Jun 8, 2024

Moving this back out of plans.md and into an issue.

@djmitche djmitche moved this from Backlog to Ready in Taskwarrior Development Jan 8, 2025
@djmitche djmitche self-assigned this Jan 16, 2025
@djmitche
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Ready
Development

No branches or pull requests

2 participants