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

Only one backup per day? #49

Closed
pcav opened this issue Aug 26, 2018 · 4 comments
Closed

Only one backup per day? #49

pcav opened this issue Aug 26, 2018 · 4 comments
Labels

Comments

@pcav
Copy link

@pcav pcav commented Aug 26, 2018

Unsure whether this is a bug or a feature: when running rsbackup multiple times in the same day, it seems to skip further backups (i.e. making only the first backup for a specific date).
In our case, it would be desirable to check at every run whether there are new or modified files. Failing to do so may result in data loss.
Is there an option for this?
Thanks.

@pcav
Copy link
Author

@pcav pcav commented Aug 26, 2018

Even if configs change (e.g. excluding new elements), the backup does not seem to be repeated in the same day.

@ewxrjk ewxrjk added the feature label Aug 26, 2018
@ewxrjk
Copy link
Owner

@ewxrjk ewxrjk commented Aug 26, 2018

Indeed, there is a limit of one backup per day. This could be changed, with a bit of care to handle existing systems gracefully. It would have an impact on space used, since although identical files can be hardlinked within backups, the same is not true of identical directories. I'll have a think about the best way to approach it.

@pcav
Copy link
Author

@pcav pcav commented Aug 26, 2018

Thanks for clarifying. In our scripts, whch worked similar to rsb, we used a full timestamp as name of top dirs, instead of the date only.

ewxrjk added a commit that referenced this issue Feb 9, 2019
Done:
- Backup IDs are full timestamps
- adjust tests to reflect new ID policy
- backup-policy directive
- 'daily' policy for historical behavior
- 'always' policy for unconstrained backups

Not done:
- test 'always' policy
- more flexible policies
- think more clearly about localetime vs gmtime
  (in backupID, but throughout)
ewxrjk added a commit that referenced this issue Feb 9, 2019
ewxrjk added a commit that referenced this issue Feb 9, 2019
ewxrjk added a commit that referenced this issue Feb 9, 2019
Hourly backups and DST could clash otherwise.

re #49
ewxrjk added a commit that referenced this issue Feb 9, 2019
ewxrjk added a commit that referenced this issue Feb 9, 2019
ewxrjk added a commit that referenced this issue Feb 9, 2019
…and make docs more consistent. re #49
ewxrjk added a commit that referenced this issue Feb 9, 2019
re #49
ewxrjk added a commit that referenced this issue Feb 9, 2019
re #49
@ewxrjk ewxrjk closed this in 86f1250 Feb 9, 2019
@pcav
Copy link
Author

@pcav pcav commented Feb 10, 2019

Thanks

ewxrjk pushed a commit that referenced this issue Feb 18, 2019
Now that there can be more than one backup per day, we need to be more
careful about how we pick the oldest backup in a bucket.

See http://www.greenend.org.uk/rjk/rsbackup/decay.pdf for the argument
that it's the oldest backup in each bucket that is preserved.

re #49
ewxrjk added a commit that referenced this issue Feb 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants