timeshift
timeshift copied to clipboard
teejee2008
Some snapshots cannot be deleted
I am trying to free up disk space by deleting old btrfs snapshots. However, deleting them from within the Timeshift GUI is impossible. They are greyed out.
The following text describes my process to force delete these snapshots, and hopefully someone will be able to find the error (if any) within Timeshift causing the problem. For a quick summary of my findings, see bottom of this post.
Here is an excerpt from the latest log of the Timeshift GUI trying to remove the oldest snapshot (already greyed out in GUI).
[11:13:25] ------------------------------------------------------------------------------
[11:13:25] Removing snapshot: 2017-09-05_15-00-01
[11:13:25] name=@home, uuid=dc2a14e2-4318-4f34-80a6-5f9fefd992a4, id=323, path=/mnt/timeshift/backup/timeshift-btrfs/snapshots/2017-09-05_15-00-01/@home
[11:13:25] Deleting subvolume: @home
[11:13:25] btrfs subvolume delete --commit-after '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2017-09-05_15-00-01/@home'
[11:13:25] E: Failed to delete snapshot subvolume: '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2017-09-05_15-00-01/@home'
[11:13:25] E: Failed to remove snapshot: 2017-09-05_15-00-01
[11:13:25] ------------------------------------------------------------------------------
I tried running the btrfs command directly as root, and got the following output:
$ sudo btrfs subvolume delete --commit-after '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2017-09-05_15-00-01/@home'
Delete subvolume (commit): '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2017-09-05_15-00-01/@home'
ERROR: cannot delete '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2017-09-05_15-00-01/@home': Directory not empty
So, the "directory is not empty". I am no btrfs expert, and don't know what this means. Next, I tried listing snapshots from the corresponding date:
$ sudo btrfs subvolume list /mnt/timeshift/backup/timeshift-btrfs/snapshots/ | grep 2017-09-05
ID 323 gen 160616 top level 5 path timeshift-btrfs/snapshots/2017-09-05_15-00-01/@home
ID 324 gen 160658 top level 5 path timeshift-btrfs/snapshots/2017-09-05_15-00-01/@
ID 325 gen 160616 top level 323 path timeshift-btrfs/snapshots/2017-09-05_15-00-01/@home/@home
ID 326 gen 160630 top level 324 path timeshift-btrfs/snapshots/2017-09-05_15-00-01/@/@
It seems there are nested snapshots eg. "/@home/@home" where there should only be "/@home". I guess that is what caused the "Directory not empty" error. I delete the nested snapshots manually:
$ sudo btrfs subvolume delete --commit-after '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2017-09-05_15-00-01/@home/@home'
Delete subvolume (commit): '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2017-09-05_15-00-01/@home/@home'
$ sudo btrfs subvolume delete --commit-after '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2017-09-05_15-00-01/@home'
Delete subvolume (commit): '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2017-09-05_15-00-01/@home'
(and same for "/@")
It seems to have worked.
Within Timeshift GUI, the snapshot seems to exist (greyed out still). When I hit "Delete", the snapshot disappears from the list.
I guess this is a success for me, but a cumbersome workaround!
Timeshift seems to create nested snapshots occasionally. When deleting from GUI, the top level snapshot is selected, and so cannot be deleted (due to a sub-snapshot residing within). This is the issue I'm reporting here, as it is making snapshot deletion impossible from within the Timeshift GUI. I don't know if the fix should be in the snapshot creation, or in the snapshot deletion.
Best regards, Mikael
The problem is that it creates a snapshot on snapshot: "timeshift-btrfs/snapshots/2017-09-05_15-00-01/@/@" You must first delete the second snapshot: sudo btrfs subvolume delete /mnt/timeshift/backup/timeshift-btrfs/snapshots/2017-09-05_15-00-01/@/@ Then remove the first one: sudo btrfs subvolume delete /mnt/timeshift/backup/timeshift-btrfs/snapshots/2017-09-05_15-00-01/@ Sometimes I have the same problem.
I'm not able to reproduce this. Please provide more details if possible. Are / and /home on separate partitions?
the bug is back, I am attaching the logs of the snapshot created the bug and the one after that. I hope it is useful 2018-03-08_14-00-01_backup.log 2018-03-08_17-00-02_backup.log info.tar.gz
I add: The snapshots are 2 per day and one weekend, so the first one in the list should be removed, but it is not removed, to remove it, I should do it manually.
Logs are not helpful. They show the @ and @home snapshots getting created (not /@/@ or /@home/@home).
I couldn't reproduce the issue but I've added a workaround in v18.4. Create a snapshot with v18.4 and let me know if issue still occurs.
I have the same issue now on Linux Mint 19. Is there anything I can do to help out with debugging this?
I have the same issue on Linux Mint 19 too. Would be great if it could be fixed, it's annoying to delete the @/@ and @home/@home snapshots by hand
I also am seeing this problem. I created a snapshot (lets call it A), installed something I didn't like, restored A (which created a restore snapshot B), rebooted, decided that I really did want the thing I had installed, restored B (which created another restore C). Then rebooted and deleted B, and attempted to delete C, but got the error. So A and C still exist, but B is gone. Enclosed is a btrfs subvolume list in the current state. list.txt
I'm also having this issue. The snapshot which can't be deleted is created before a restore.
I got subvolume
ID 264 gen 20 top level 257 path timeshift-btrfs/snapshots/2018-07-30_02-06-26/@/var/lib/portables
ID 265 gen 21 top level 257 path timeshift-btrfs/snapshots/2018-07-30_02-06-26/@/var/lib/machines
inside it.
Need to delete nested subvolumes first. They must be created after a restore and before a reboot.
@evopen It looks like maybe if there are already other btrfs sub volumes below the path that timeshift is snapshotting, then they show up as sub-sub volume in the snapshot. Then timeshift gets and error when it tries to delete the snapshot without deleting the sub-sub volumes. I noticed that you had /var/lib/portables and machine, while I've been using Docker (which uses sub volumes for image storage if it detects btrfs).
@hellcats Maybe you are right. The subvolumes are created before snapshoting. But I don't have these subvolumes in my host and any other snapshots. So I don't know how they got created. And I searched for these paths and I don't think they are related to docker.
For me, it seems docker was part of the problem. Having docker images on a btrfs system means having docker subvolumes. Timeshift understandably does not handle these subvolumes when deleting timeshift-created subvolumes.
Normally, creating a snapshot of a subvolume excludes any nested subvolumes. I'm not sure what's special about these 2 subvolumes that they are getting included.
Well I have some new info to add to this issue. The problem stopped happening for me after changing some settings in timeshift. Before I had all options selected for schedule, monthly, weekly, daily, hourly, and boot. I switched to just monthly, weekly, and daily only and I have not had the problem since. So that means that either it happens when all options are selected at the same time, or it happens when boot or hourly are selected. Not sure if it is important, but boot on this machine is pretty slow, not sure if that could effect the boot option in timeshift or not.
I am experiencing this issue on Linux Mint 19 Tara Cinnamon edition with timeshift 18.6+tara.
I have a single BTRFS partition with @ and @home subvolumes only. Snapshots are stored in the partition as BTRFS ones.
A number of earlier snapshots have lost their B and D tags (i was retaining two of each) and are not able to be deleted from the Timeshift GUI.
Examination of the snapshots shows that there is a recursion on @ i.e. there is an @/@ snapshot. Deleting this snapshot manually (with btrfs subvolume delete --commit-after snapshot/@/@) does allow deleting of the snapshot shown in the Timeshift GUI afterwards.
No restores of snapshots have been performed or running of esoteric software like docker on this system. The issue must be caused by a bug in Timeshift that will manifest on a vanilla configuration.
Thanks for opening this thread, I stumbled across this as I had the same behaviour. The root cause of the problem for me was running docker on the root filesystem created subvolumes that I couldn't get rid of.Being a complete brtfs novice, I couldn't follow @hellcats instructions so on the off chance that someone else is in this boat, I've documented the process here:
ERROR: cannot delete '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2018-10-15_22-51-44/@': Directory not empty
root@mintXPS:/mnt/timeshift/backup/timeshift-btrfs/snapshots# btrfs subvolume list /mnt/timeshift/backup/timeshift-btrfs/snapshots
ID 278 gen 26772 top level 5 path timeshift-btrfs/snapshots/2018-10-15_22-51-44/@
ID 291 gen 26772 top level 278 path timeshift-btrfs/snapshots/2018-10-15_22-51-44/@/var/lib/docker/btrfs/subvolumes/f8a750facd1d0d1f739b07e08de3935011ab6cf4aad0652ce48c244fcbb0bffc
ID 292 gen 26772 top level 278 path timeshift-btrfs/snapshots/2018-10-15_22-51-44/@/var/lib/docker/btrfs/subvolumes/df101025758e8c36bbf609884a3107ab485993c5a8b6ac3017aa7fccef428413-init
....
root@mintXPS:/mnt/timeshift/backup# for subvolume in /mnt/timeshift/backup/timeshift-btrfs/snapshots/2018-10-15_22-51-44/@/var/lib/docker/btrfs/subvolumes/*; do btrfs subvolume delete --commit-after $subvolume; done
Delete subvolume (commit): '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2018-10-15_22-51-44/@/var/lib/docker/btrfs/subvolumes/005f31cd6d594ed2178b80b44ef67a3ce0c11286c5333ae5a3127f8428ca7793'
Delete subvolume (commit): '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2018-10-15_22-51-44/@/var/lib/docker/btrfs/subvolumes/005f31cd6d594ed2178b80b44ef67a3ce0c11286c5333ae5a3127f8428ca7793-init'
....
root@mintXPS:/mnt/timeshift/backup# btrfs subvolume delete --commit-after /mnt/timeshift/backup/timeshift-btrfs/snapshots/2018-10-15_22-51-44/@
Delete subvolume (commit): '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2018-10-15_22-51-44/@'
Seems to be caused by cases where multiple tagged snapshots are taken at the same time by
timeshift --check (e.g., Daily, Weekly, Monthly). The simple change in #344 fixes it for me
Thank you @cmulk! In addition, it would be nice if timeshift could also clean up the current situation. Not everyone is able to do this manually like @madsherlock .
I am seeing this on Mint 19 (without docker), with weekly, daily, and monthly snapshots and root and home on the same partition.
Good idea @jondo! I was able to add that to the same pull request as well, at least for the case where it's simply nested @ and @home subvols
My configuration:
Disk is a single SSD: nvmn1p2 / BTRFS nvmn1p3 /home EXT4 nvmn1p4 /mnt/media EXT4
UEFI/GPT installation, secure boot is off
Linux Mint 19.1 Cinnamon 64, NO Docker involved!
Timeshift v.19.01 is set to use BTRFS-backup only for /. Completely de- and reinstalled timeshift + settings, cleared all BTRFS-backups.
I'm only using daily backups (max. 4) to exclude if there's something wrong with different updates at the same time. I didn't start any manual backup, just let timeshift do its work -> broken from the first backup! (cannot be deleted from the GUI).
What informations do you need else to reproduce this?
#364
I've got a clue: On my second notebook (nearly same configuration) Timeshift works as it should. Differences there compared to the failing NB:
- no GPT (just MBR) and CSM instead of UEFI
- SSD SATA instead of NVMe
Maybe one of those configurations makes the difference.
@neildarlow @eugenem111 @evopen can you confirm this? Details see my post from May 3rd. Others in this thread had docker or something else what has been fixed already.
Unfortunately I didn't get any answer. @teejee2008, does my idea means something to you?
Sorry, I don't have a clue. I have spent countless hours tracking down this bug without success.
I use btrfs snapshots on all my systems but I have never run into this issue.
I am on a fresh newly installed Manjaro gnome system (file system is btrfs). I can only confirm what the op reports on this issue. When trying to delete a snapshot, the only thing that happens is that it is greyed out, but not deleted. Also after a re-boot and opening Timeshift, the snapshot that was marked to be deleted is still there (still greyed out).
System: Host: tomas-pc Kernel: 5.1.16-1-MANJARO x86_64 bits: 64 Desktop: Gnome 3.32.2 Distro: Manjaro Linux System: Host: tomas-pc Kernel: 5.1.16-1-MANJARO x86_64 bits: 64 Desktop: Gnome 3.32.2 Distro: Manjaro Linux
Timeshift: v19.01
This must be considered as a major issue. In the meantime until this is properly solved, is there any safe "workaround" to delete the greyed out snapshots?
[Update]: The issue seem to be related for 'snapshots on demand' only. For other snapshots it works as expected.
@tnilzon The workaround is to delete snapshots manually, e.g.: sudo btrfs subvolume delete --commit-after /mnt/timeshift/backup/timeshift-btrfs/snapshots/2019-07-10_21-00-12/@/ and afterwards delete the entries in gui. For me it's not working on demand and scheduled snapshots.
I'm facing this same issue when trying to delete snapshot that has been created automatically before a restore. When trying to delete this snapshot, Timeshift greyed it out, but not deleted. Exploring the contents of this snapshot, I see two (2) nested subvolumes inside '@':
timeshift-btrfs/snapshots/2019-09-01_15-19-44/@/var/lib/portables
timeshift-btrfs/snapshots/2019-09-01_15-19-44/@/var/lib/machines
The workaround is to delete these 2 nested subvolumes manually, and then Timeshift allows you to delete the snapshot from the GUI. But this problem should be solved properly without this type of workarounds, which affects the usability of this great app.
