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

protect again time-machine rollbacks? #5388

Open
moscicki opened this issue Dec 16, 2016 · 4 comments
Open

protect again time-machine rollbacks? #5388

moscicki opened this issue Dec 16, 2016 · 4 comments

Comments

@moscicki
Copy link
Contributor

moscicki commented Dec 16, 2016

An afterthought of #5387: suppose the sync folder is not excluded from the time machine backup and the system is rolled back. All the changes would be propagated to the server which is probably not what the user wants.

Is there a way to protect agains backup rollbacks and let the user decide what to do (start from scratch or propagate current state)?


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@SamuAlfageme
Copy link
Contributor

SamuAlfageme commented Dec 20, 2016

@moscicki hm, I think preventing this would be a really nice enhancement for the desktop client (not only on OS X) but yeah. Actually found myself in a similar situation not so long ago and ended up having to restore things from server.

This would need some design though, e.g. first solution that occurred to me would be to detect the modification time of the folder sync connections (as they're retained in Time Machine) and compare to server's, but it's not that easy since this metadata might be completely different in both sides.

@ckamm
Copy link
Contributor

ckamm commented Dec 21, 2016

Maybe something about seeing mtimes moving backwards?

@moscicki
Copy link
Contributor Author

Quickly thinking about it I see two mechanisms:

You could have some extra protection if you keep track of the sync client activity in both sync folder and in the configuration directory and correlate them. It would allow you to detect the situation when the sync folder last activity does not match the one stored in the config. That would work for setup which I have seen which is to include config directory in the time machine but exclude sync folder from it.

Another mechanism is also possible but it would require to uniquely identify the client to the server (e.g. with uuid). If you keep the last mtime of the sync journal file of uniquely identified client on the server then you can see that it goes back in time in case of the restore from backup.

@andrewperry
Copy link

I have restored my whole computer from a time machine backup from a couple of weeks ago and now there's a lot of frequently used folders that are not completing a sync. I assume this is related to this issue?

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

No branches or pull requests

4 participants