Extending exclude file after some snapshots: how to get rid of old files

I’ve searched through the manual, github, and this forum but I could not find an approach for a use-case I do think is quite common.
I’ve done some backups with restic (I’m still new to it). Meanwhile my backup disk is at >99% usage. So I need to ignore more directories. Therefore, I extended the exlude-file.
Now I need to get rid of the data within the snapshots for these new excludes before I’m able to create a new snapshot. If not, my backup disk would be 100% full which is something restic does not handle to my knowledge. (Which is very bad IMHO.)

Since https://github.com/restic/restic/issues/14 is not resolved, there must be a workaround to do so.

I’m guessing that prune might delete this data somehow?
I tried to mount the latest snapshot and delete the files but the mount point is read-only and I do think this should not be overridden for good reasons.

Thanks for any hint here!

Note that at 99% full, you’re still going to have problems even if you could rewrite snapshots in this way, because the data is not immediately deleted. Prune needs to rewrite packs containing deleted objects into new packs before it can delete the old packs, so you need some free space for prune to work correctly – and if you can’t prune, there’s not really any way to remove data blobs.

You likely need to temporarily copy the repository to a larger disk before you can fix this issue.

Do you really need the old snapshots? Personally, I wouldn’t complicate things - I’d just delete the entire repository and start a new one. Reason: I never need that old data anyway, and I always have the second backup to lean on if I did. Because you do have a second backup, right? :wink:

No, I don’t need it. I just wanted to spare me the 30 hours of initial running time to backup my 4TB again.
OK, I will start from scratch then.

I guess it’s either that or what @cdhowie said, copying the repo to another larger disk for maintenance.

I see. Unfortunately, I don’t have a larger disk. And copying the content twice would take longer anyway.

I just would like to comment that PR #2513 adds a possibility. With this change, the way to go could be:

  • create a new backup/snapshot with more excluded files
  • forget your original backup snapshot
  • run cleanup-index and cleanup-packs

cleanup-index does create new index files and delete the old ones but does so file-by-file. I think it should work if you have some MB free…

However, I would not suggest running this on a productive backup until the PR is reviewed and fully tested!