Second day of vacation and I get a text ‘backup server is full’. Well, that sucks. Pretty sure it had 1.5TB a week or two ago. Sure enough, 0 bytes available.

The first place I look is at snapshots. I think I have a few old snapshots that are locked in, let’s delete those and then maybe look at tightening up retention. ‘Error deleting snapshot’. Ah stink.

Long story short, Synology’s GUI was throwing errors when trying to delete snapshots, and I was eventually able to delete them by dropping into SSH and deleting them using btrfs commands.

First let’s get a list of snapshots:

sudo btrfs subvolume list /volume3

...
ID 79993 gen 371972 top level 673 path @sharesnap/config/GMT-06-2020.11.24-08.00.02
ID 80284 gen 374742 top level 673 path @sharesnap/config/GMT-06-2020.11.25-08.00.02
ID 80368 gen 377261 top level 673 path @sharesnap/config/GMT-06-2020.11.26-08.00.02
ID 80446 gen 379839 top level 673 path @sharesnap/config/GMT-06-2020.11.27-08.00.02
...

Next we need to take those snapshot paths and prepend the volume path so that BTRFS can delete it. Since I’m deleting snapshots on Volume 3, mine look like this now:

/volume3/@sharesnap/config/GMT-06-2020.11.24-08.00.02
/volume3/@sharesnap/config/GMT-06-2020.11.25-08.00.02
/volume3/@sharesnap/config/GMT-06-2020.11.26-08.00.02
/volume3/@sharesnap/config/GMT-06-2020.11.27-08.00.02

And now we can run the delete commands:

btrfs subvolume delete -c /volume3/@sharesnap/config/GMT-06-2020.11.24-08.00.02
btrfs subvolume delete -c /volume3/@sharesnap/config/GMT-06-2020.11.25-08.00.02
btrfs subvolume delete -c /volume3/@sharesnap/config/GMT-06-2020.11.26-08.00.02
btrfs subvolume delete -c /volume3/@sharesnap/config/GMT-06-2020.11.27-08.00.02

The -c is important. When I was first running these commands I saw output along the lines of ‘not committed’ and my snapshots appeared to still exist after re-listing them. -c waits for the the snapshot delete to commit before exiting.

With this I was able to delete snapshots and see those bytes crawl back in.