I can´t get space if i delete backups on PBS

BetoAndujo

New Member
Aug 10, 2022
6
0
1
I have a problem, deleting PBS backups does not free up space, what configuration should I have for that to happen??
 
You first have to prune the backups. Then you have to wait for at least 24 hours and 5 minutes. When you then run a GC task the space should be freed up. If it is still not freed up (this 1 day between prune and GC is important) check if you got snapshots or missing discard/trim preventing the storage from freeing up old data.
 
Last edited:
Not having snapshots is god as this would prevent deleted data from freeing up space.
 
Its like I described:
1.) do a prune...this will delete the backup snapshots but won't remove any chunks so space is still used
2.) wait for at least 24 hours and 5 minutes
3.) run a GC task. This will then actually delete the unneeded chunks and free up the space but only if 24 hours and 5 minutes passed between the prune and the GC.

So yes, you have to wait for a day and can't immediately delete stuff or free up space.
 
I changed the settings like this, as you said i have to wait 24 hours and 5 minutes i think this is correct


1667930931946.png



Or i should configure
GCS at sun 18:00
Prune Schedule at sat 12:00

1667931197531.png
 
I changed the settings like this, as you said i have to wait 24 hours and 5 minutes i think this is correct


View attachment 43038
There GC is running 24 hours and 10 minutes before the prune. Not GC after prune. If you want to free up space as fast as possible I would run the prune sat 12:00 and the gc sun 13:00. Not sure how fast or big your storage is, but the prune can take a moment too.
 
so.... similar issue but i went nuclear and did an rm -r on the mounted directory that made the data store. when that didnt work I launched gdisk and wiped my data drive. i then added a partition back and the damn thing still shows 95% full

i gather its the "chunks" that i need to delete but you are saying you just have to wait a day?

is there not a way to force it?
 
There is a non-recommended way to delete the data immediately ...

Code:
find /path2pbs-datastore/.chunks -type f -print0 | xargs -0 touch -d "-2 days"

.... and GarbageCollect.
Thank you @Ernst T. for the solution.

While I apresahte that this is not the "recomended" way, sometimes when you have no choice "like when your filesystem is full" because you forgot to put a max amount of backups to keep; you just cant wait ~2 days for it to resolve itself as backups in the meantime will be failing.

Code:
2024-07-29T09:38:41+00:00: processed 98% (648983 chunks)
2024-07-29T09:38:44+00:00: processed 99% (655690 chunks)
2024-07-29T09:38:46+00:00: Removed garbage: 1.409 TiB
2024-07-29T09:38:46+00:00: Removed chunks: 462615
2024-07-29T09:38:46+00:00: Original data usage: 6.674 TiB
2024-07-29T09:38:46+00:00: On-Disk usage: 562.618 GiB (8.23%)
2024-07-29T09:38:46+00:00: On-Disk chunks: 199797
2024-07-29T09:38:46+00:00: Deduplication factor: 12.15
2024-07-29T09:38:46+00:00: Average chunk size: 2.884 MiB
2024-07-29T09:38:46+00:00: TASK OK

Thanks again for the solution.
 
There is a non-recommended way to delete the data immediately ...

Code:
find /path2pbs-datastore/.chunks -type f -print0 | xargs -0 touch -d "-2 days"

.... and GarbageCollect.

What are the risks with this command? Will it delete all backups or just the pruned ones?

This is what the documentation says regarding the use of file access time:
"Garbage collection considers chunk files with access time older than the cutoff time to be neither referenced by any backup snapshot's index, nor part of any currently running backup job. Therefore, these chunks can safely be deleted."
(https://pbs.proxmox.com/docs/maintenance.html#gc-background)

Based on this it sounds like if every chunk has an old access time then they're all considered "safe to delete", no?
 
Garbage Collector runs two steps or phases. GC phase one will go through all snapshots, read which chunks are used by each and update chunk's mtime to now(). GC phase two will remove all chunks whose mtime is older than 24 hours 5 minutes. So even is you run that command to manually force the mtime of everything to "now() - 2 days", the GC will only remove the chunks that are not used by any snapshot.
 
  • Like
Reactions: Johannes S
This was already answered, but I had something typed out so posting it in addition.
What are the risks with this command? Will it delete all backups or just the pruned ones?
The command itself does not delete anything; it "just" changes the modification time of all chunk files such that they seem older, making sure that GC considers them for deletion, if no existing backup snapshop has any reference to the file(s) that is.

btw., one can adapt the command to make it slightly more efficient by only changing the mtime for the files where it's newer than 2 days ago using find's -mtime filter, e.g.:

find /path2pbs-datastore/.chunks -type f -mtime -2 -print0 | xargs -0 touch -d "-2 days"
 
The command itself does not delete anything; it "just" changes the modification time of all chunk files such that they seem older, making sure that GC considers them for deletion, if no existing backup snapshop has any reference to the file(s) that is.

Got it.

It would be great if there was an option to do this from the GUI. While I was waiting for a reply, unsure if the command is dangerous, our PBS was on 100% usage, nothing could be backed up, nothing could be deleted right away after lowering the retention, and the GC would last many hours due to the tens of terabytes of backups.
We ended up in a situation where we missed 2 days worth of daily backups, which is not ideal when you have critical infrastructure.

Maybe add a dialog box when you click "Run GC now" with a checkbox for whether you want to delete pruned backups right now?
 
We ended up in a situation where we missed 2 days worth of daily backups, which is not ideal when you have critical infrastructure.

Allowing any storage to run out of space is also not ideal in the first place, to say the least...