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

Suggestion: Mark a specific archive as "never prune" #146

Open
tgharold opened this issue Dec 9, 2014 · 6 comments
Open

Suggestion: Mark a specific archive as "never prune" #146

tgharold opened this issue Dec 9, 2014 · 6 comments

Comments

@tgharold
Copy link

tgharold commented Dec 9, 2014

Right now you have the "attic prune" command for automatic pruning of old revisions (kudos for a very well thought out command) as well as "attic delete".

I would like to see a "never prune" flag added to an individual archive. Maybe I have an archive that I want to keep around forever, even if pruning is applied to the attic repository. Any archive with the "never prune" flag would simply not be a candidate for pruning nor would it be included in the pruning algorithm.

I'd want to be able to specify this at two points in time:

  • At the time of archive creation (attic create), maybe with an option of "--never-prune".
  • At a later point in time, being able to change an existing archive to never be a candidate for pruning.

An expanded version of the concept would be "--never-prune-earlier-than DATE". Once that date has passed, the archive becomes eligible for pruning with "attic prune".

@kahlin
Copy link

kahlin commented Dec 9, 2014

+1 for this.

My use-case is that I want to move old backups into attic and make sure that (some of) those archives aren't pruned.

@fewyun
Copy link

fewyun commented Dec 9, 2014

I think that the --prefix flag does a decent job of dealing with this use case. However, when relying on the archive name like this, it would be nice to have a rename archive command.

@tgharold
Copy link
Author

A rename command for an attic archive would definitely be useful and probably a very good way to achieve this. However, right now the --prefix command only lets you specify what archives to include in the pruning. So if you have a list of archives that start with a non-static string, i.e.starting with the year:

20141201-1021 Mon Dec 1 16:51:23 2014
20141203-2045 Wed Dec 3 21:05:34 2014
20141204-0331 Thu Dec 4 03:39:54 2014
20141205-0705 Fri Dec 5 07:14:45 2014
20141205-0737 Fri Dec 5 07:43:45 2014
20141205-1735 Fri Dec 5 17:44:29 2014
20141206-0342 Sat Dec 6 03:50:15 2014
20141206-1126 Sat Dec 6 11:33:38 2014
20141206-1819 Sat Dec 6 18:28:19 2014
20141207-1137 Sun Dec 7 11:45:10 2014
20141208-0930 Mon Dec 8 09:38:07 2014
20141209-1330 Tue Dec 9 13:45:24 2014
20141210-0148 Wed Dec 10 02:02:09 2014
20141210-0830 Wed Dec 10 08:38:00 2014

And you rename one of the archives to be "never-prune-20141209-1330", there is no easy way to tell attic which archives to prune.

So "attic prune" would need a --prefix-exclude option added, or better both a --prefix-exclude and a -suffix-exclude. Because I'd rather rename a "never prune this" archive as "20141209-1330-do-not-prune".

Another argument for adding a "never prune" flag is that it is harder to get wrong if someone does an "attic prune" but forgets to use the --prefix or --suffix correctly. With the "never prune" flag or "never prune before" value set on an archive, you don't have to worry that someone goofing up the attic prune command will wipe out the archive that you have set aside for safe keeping.

Thinking about this a bit more, it would make sense to add a comment at the time of setting the "never prune" flag.

attic create --never-prune-before 5y --never-prune-comment "This archive must be kept for five years due to XYZ regulation" (path-to-repository) (files-to-backup)

@fewyun
Copy link

fewyun commented Dec 10, 2014

The docs currently suggest a prefix title for naming (eg hostname`-`data +%Y-%m-%d) so the prefix already covers best practices.

If you run attic prune or attic delete incorrectly you are already in a world of hurt. I'd suggest backing up your attic repo. And possibly attic should require user confirmation when running these commands -- with a --force/-f flag for automatic scripts.

I love attic's simplicity, so I'm against adding too many new flags or moving prune logic to a completely different command (ie create).

As for dealing with your naming scheme, the prune command could have a single --pattern or --regex flag, but I'd suggest just renaming them. You could rename them all hostname-cron-date. And then carefully (as you always should) run attic prune --prefix hostname-cron- .... Archive that you never want pruned you could then rename hostname-date or hostname-IMPORTANT.

Actually, on the topic of a rename command it might make more sense to have a copy command, which would just add an archive that points to the same blocks. The old archive could then be deleted if desired. But I'm not sure about implementation details at this time.

I would be very interested to hear some of the main devs' views on the suggestions in this thread.

@tgharold
Copy link
Author

Simplicity is indeed a good goal, but for backup software I desire a few things:

  • Paranoia (lots of self-checks, hashes, etc.) against bit-rot, broken transfers, deleted files
  • Self-repair where possible
  • Redundancy where needed
  • Protection from shooting oneself in foot (i.e. a "read-only bit")
  • Some way of cloning off to permanent storage

If the solution to a problem with the backup repository is to "restore it from backup" in the case of a minor issue that could have been avoided, then Attic is not living up to its billing as backup software.

@ThomasWaldmann
Copy link
Contributor

See PR #251 for archive rename.

I think the PR also fixes this issue as you can rename your never-prune archives so that they do not match prune --prefix any more (e.g. noprune-*). If all your regular archive names start with the year, you could use prune --prefix 20 and be ok until 2099. :)

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

No branches or pull requests

4 participants