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

Maintenance of backup dirs #19

Open
Marxsal opened this issue Aug 15, 2019 · 6 comments
Open

Maintenance of backup dirs #19

Marxsal opened this issue Aug 15, 2019 · 6 comments
Labels
enhancement New feature or request

Comments

@Marxsal
Copy link
Owner

Marxsal commented Aug 15, 2019

The backup dirs may become untidy. I'm thinking a menu item that will trim the directory to one file a week. But I regard this as a useful enhancement, not as a must-have. Also, there is the liability that occurs whenever files are deleted.

@Marxsal Marxsal added the enhancement New feature or request label Aug 15, 2019
@TiddlyTweeter
Copy link
Collaborator

TiddlyTweeter commented Aug 16, 2019

IF user has auto-download on in wiki/browser; edits things a lot; auto-monitors in seconds ... that could spawn large numbers of backups very quickly. I do think pruning will be needed in some situations.

However, I get nervous deleting things. The trouble is we can do the backups easy now, but managing backups, retained or deleted, is another story. Spacing? How many, etc?

Maybe this should be for a semi-separate specialised tool later?

@TiddlyTweeter
Copy link
Collaborator

Just FYI: Both PMario and Riz implemented "Towers Of Hanoi" well in their backup plugins. I looked for a PS library that can do it but haven't found one yet.

TBH I'd be nervous about any arbitrary cut-off date. I'd think spread is better, if you know what I mean.

@Marxsal
Copy link
Owner Author

Marxsal commented Aug 16, 2019

I believe the way PMario (don't know about Riz) did TOH was to actually label the backups as they occurred, like myfile (A), myfile(B)...

The thing about TOH, is it assumes that your need for a file is geometric over time. That is, there are 8 backups, then there will be 8 backups whether your data set consists of everything you did this week, or everything you did over 3 years. I'm thinking that a more realistic approach might be to keep all backups from the past week, one backup each week for one month, and then one monthly backup a month forever.

Of course, both approaches are misnomers, since they don't actually backup anything. A true backup needs to send files off to another device or cloud. But I digress.

@TiddlyTweeter
Copy link
Collaborator

@Marxsal ... both approaches are misnomers, since they don't actually backup anything. A true backup needs to send files off to another device or cloud.

Actually I agree. And its a not a digression in the sense that: Is it better to emphasise proper replication to another device first, over smart pruning. TBH I think fundamental of backup to separate device matters most.

@Marxsal
Copy link
Owner Author

Marxsal commented Aug 16, 2019

Re backups, per your other comments, it should be possible to upload genuine backups to cloud sites? It's apparently possible to install git on powershell, so you could even push backups to your own GH repository. Definitely gilding the lily, or something.

@TiddlyTweeter
Copy link
Collaborator

TiddlyTweeter commented Aug 17, 2019

@Marxsal ... realistic approach might be to keep all backups from the past week, one backup each week for one month, and then one monthly backup a month forever.

I slept on this. Actually, when I think about actual usage of backups for TW my single most common case is in the last 24 hours Why? Because TW has no "Undo" function. I have, quite often, used TW backups as a surrogate "undo".

So there is me thinking again ... Wondering IF we might be able to do sequential restores from backups via the Polly interface?

This tool is frightening! :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants