Replies: 1 comment 5 replies
-
|
I'm not sure if you understand what a prune operation is? Restic backups are based on the concept of 'snapshots'. Think of a snapshot as a list of directory and file versions, based on contents. I'm not the world's expert on restic, but my understanding is that snapshots share a repository, and this allows restic to not have duplicated data - because most snapshots, most of the time, are 90%+ the same as the previous snapshot. Maybe 10% of the files change (new files, deleted files, files which have been renamed or moved to a different folder in the filesystem, or files where the contents have changed). Every time a restic backup job runs (whether a backrest 'plan' or something you fire off with a script or cron job or manually with CLI), restic creates a new snapshot. Generally speaking, most backup plans will delete old snapshots after some period of time, so that your backup repository size doesn't tend to grow to infinity, and so that you can actually delete files at some point, that you intend to delete. So, maybe a backup plan might have the following retention policy:
This snapshot policy means that eventually, some snapshots get deleted. HOWEVER, the data in the repository isn't deleted immediately when a snapshot is deleted. Instead, the prune job, whenever you run it, runs through all the snapshots and figures out what data in the repository is still referred to by any currently extant snapshot, and preserves that data, but deletes any 'orphaned data' which no snapshot refers to any longer. After deleting the data it compacts and re-compresses the repository data. Prune is generally a 'safe' operation, because if no snapshots refer to the data, there's really no way to recover it - it's there, but restic no longer has a way to access it, because you access files through the snapshots - e.g. you can restore a snapshot, or mount the snapshot, etc. If you REALLY want to disable the prune functionality in backrest, I think you probably could do that through settings. But be aware that your repository will likely grow with a lot of junk data that's no longer accessible - unless you keep every snapshot forever. |
Beta Was this translation helpful? Give feedback.
-
|
It looks like there is a prune schedule in the repository-specific settings. To get to that, go to the backrest web ui, expand the list of repositories, and there should be a 'pencil' icon at the right end of the repository entry in the list. Click the pencil to edit the repository settings. |
Beta Was this translation helpful? Give feedback.
-
I appreciate your very detailed explanation (I seriously think you should put it in a wiki so that people who start with backups get another information source). For the context, I have managed both personally and professionally servers since the mid-90s, so I am (fortunately 🙂) quite acquainted with backups, including deduplicating ones. I've used, for instance, Borg for years but after several tests I see that restic is better (duplicati is not bad either) My point was not "what is this prune thing" but rather - why is there a prune operation scheduled by default? Either it is "very default" and forces some "default and reasonable" prune values (which would be totally scary), or it is going to run empty (so what's the point of setting it and stressing users :)) |
Beta Was this translation helpful? Give feedback.
-
|
Ok, well, I wasn't sure if you understood what prune is - because it's not scary to me at all. Nothing still in a snapshot gets removed. What's scary about removing the data if the snaps have already been removed? That said, I think when you create a repo, you can go in and modify the prune schedule. The whole point of 'reasonable defaults' is to help novice users "do the right thing", and pruning the repository is, the vast majority of the time for the vast majority of users, the 'right thing'. I cannot think of any use case for not pruning the repository. That said, my lack of imagination in this case doesn't mean there is no use case. But this won't be causing data loss for users who let it default to on. |
Beta Was this translation helpful? Give feedback.
-
|
I completely agree with you - the problem I had is that a scheduled prune appeared out of the blue, unexpectedly. Then you don't know what is hidden behind this forced prune (maybe there is a policy to prune anything older than an hour? Who knows, since it showed up on its own). When running restic, you run a backup session (that creates a snapshot), and then deliberately do a prune (if you want, when you want). With backups I do not like surprises :) This said, you should really consider adding your write-up somewhere. |
Beta Was this translation helpful? Give feedback.
-
|
forget is distinct from prune phase, https://garethgeorge.github.io/backrest/docs/operations provides details about what each operation is doing. The operations in the UI map 1:1 with restic commands. A prune operation removes data from your repo that has been "forgotten". A "forget" operation marks snapshots older than your retention policy as "forgotten" and eligible for pruning. There's a UI bug I'm now noticing in the latest release where the section headings for the "prune" and "check" schedules are missing, these schedule for prune and check can be customized here in the repo settings: 
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I just plugged backrest to my new backups. There are two strage things I see:
The first one is worrisome: what are these
pruneandcheckcommans scheduled for 2026-01-01? They are not mine and I do not want any to happen out of the blue.The second one, I guess, mean that these backups are not associated to any plan (which is normal - they run though their own means). I just wanted to make sure this is indeed the case
Beta Was this translation helpful? Give feedback.
All reactions