search

teejee2008 / timeshift

System restore tool for Linux. Creates filesystem snapshots using rsync+hardlinks, or BTRFS snapshots. Supports scheduled snapshots, multiple backup levels, and exclude filters. Snapshots can be restored while system is running or from Live CD/USB.
GNU Lesser General Public License v3.0
4.69k stars 282 forks source link

Some snapshots cannot be deleted #141

Open madsherlock opened 6 years ago

madsherlock commented 6 years ago

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

teejee2008 commented 6 years ago

What distribution are you using?

emanuc commented 6 years ago

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.

Djaler commented 6 years ago

I can confirm this on elementary OS Loki (based on Ubuntu 16.04)

teejee2008 commented 6 years ago

I'm not able to reproduce this. Please provide more details if possible. Are / and /home on separate partitions?

emanuc commented 6 years ago

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

screenshot_20180317_151337

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.

teejee2008 commented 6 years ago

Logs are not helpful. They show the @ and @home snapshots getting created (not /@/@ or /@home/@home).

teejee2008 commented 6 years ago

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.

cromerc commented 6 years ago

I have the same issue now on Linux Mint 19. Is there anything I can do to help out with debugging this?

jonicho commented 6 years ago

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

jonicho commented 6 years ago

btw: i have v18.6 so the workaround doesn't seem to work

hellcats commented 6 years ago

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

evopen commented 6 years ago

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.

hellcats commented 6 years ago

@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).

evopen commented 6 years ago

@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.

madsherlock commented 6 years ago

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.

teejee2008 commented 6 years ago

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.

cromerc commented 6 years ago

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.

eugenem111 commented 6 years ago

Same issue, clean install. Mint 19

neildarlow commented 6 years ago

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.

bowdena commented 6 years ago

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/@'
cmulk commented 6 years ago

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

jondo commented 6 years ago

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.

cmulk commented 6 years ago

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

Mintulix commented 5 years ago

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

Mintulix commented 5 years ago

I've got a clue: On my second notebook (nearly same configuration) Timeshift works as it should. Differences there compared to the failing NB:

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.

Mintulix commented 5 years ago

Unfortunately I didn't get any answer. @teejee2008, does my idea means something to you?

teejee2008 commented 5 years ago

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.

tnilzon commented 5 years ago

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.

Mintulix commented 5 years ago

@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.

damian01w commented 5 years ago

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.

Mintulix commented 5 years ago

Timeshift: v19.01 I made a fresh system install with Linux Mint 19.2 Cinnamon 64 (let /home untouched) and had no more issues with the automatic deletion of automatically created snapshots. Resolved for me, but I don't know why. Perhaps a problem with BTRFS qgroups that is solved now after formatting...

metal450 commented 4 years ago

Fresh Linux Mint 19.3 install, & a few days into trying Timeshift I found my way to this thread. Surprising that 2 years later newcomers are still finding themselves having to manually go in & delete snapshots to keep Timeshift working...

catscarlet commented 4 years ago

Same issue here. Linux mint 19.3

Timeshift log

[00:36:17] DeleteBox: delete_snapshots()
[00:36:17] Main: delete_begin()
[00:36:17] delete_begin(): thread created
[00:36:17] Main: delete_begin(): exit
[00:36:17] delete_thread()
[00:36:17] ------------------------------------------------------------------------------
[00:36:17] Removing snapshot: 2020-03-07_16-15-07
[00:36:17] Deleting subvolume: @ (Id:272)
[00:36:17] btrfs subvolume delete --commit-after '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2020-03-07_16-15-07/@'
[00:36:17] E: ERROR: cannot delete '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2020-03-07_16-15-07/@': Directory not empty

[00:36:17] E: Failed to delete snapshot subvolume: '/mnt/timeshift/backup/timeshift-btrfs/snapshots/2020-03-07_16-15-07/@'
[00:36:17] E: Failed to remove snapshot: 2020-03-07_16-15-07
[00:36:17] ------------------------------------------------------------------------------

btrfs su list

cat@cat:~$ sudo btrfs subvolume list /mnt/timeshift/backup 
ID 265 gen 22228 top level 5 path timeshift-btrfs/snapshots/2019-12-22_20-05-58/@
ID 268 gen 22228 top level 5 path timeshift-btrfs/snapshots/2019-12-22_20-25-28/@
ID 269 gen 22228 top level 5 path timeshift-btrfs/snapshots/2019-12-22_20-31-06/@
ID 272 gen 22644 top level 5 path timeshift-btrfs/snapshots/2020-03-07_16-15-07/@
ID 277 gen 22228 top level 5 path timeshift-btrfs/snapshots/2019-12-22_21-31-44/@
ID 279 gen 22644 top level 272 path timeshift-btrfs/snapshots/2020-03-07_16-15-07/@/var/lib/docker/btrfs/subvolumes/7f4d499fc8a8095c1e1805d0a9a6e6cbd8832a6d56c0b4208a97df4edcdb24a0
ID 280 gen 22644 top level 272 path timeshift-btrfs/snapshots/2020-03-07_16-15-07/@/var/lib/docker/btrfs/subvolumes/3a8a3f806a0145e5c170d7688ed5f63d9955b657d7c072aecf7635b76b2312d2-init
ID 281 gen 22644 top level 272 path timeshift-btrfs/snapshots/2020-03-07_16-15-07/@/var/lib/docker/btrfs/subvolumes/3a8a3f806a0145e5c170d7688ed5f63d9955b657d7c072aecf7635b76b2312d2
ID 282 gen 22228 top level 5 path timeshift-btrfs/snapshots/2020-01-14_14-56-02/@
ID 283 gen 22228 top level 5 path timeshift-btrfs/snapshots/2020-02-26_08-18-49/@
ID 286 gen 22228 top level 5 path timeshift-btrfs/snapshots/2020-02-26_16-39-20/@
ID 288 gen 22228 top level 5 path timeshift-btrfs/snapshots/2020-02-26_16-57-05/@
ID 294 gen 22648 top level 5 path @
ID 297 gen 22228 top level 5 path timeshift-btrfs/snapshots/2020-05-13_23-00-22/@

My Timeshift version is 19.08 and my machine is runnning Docker. All the snapshots are manually generated, not scheduled. I have read some of posts and they said the issue related to Docker had been fixed but still, it happened on my machine.

wmutschl commented 4 years ago

Do you guys have all options selected (monthly, weekly, daily, hourly, boot)? Again the workaround is to delete the nested subvolumes

sudo btrfs subvolume delete PATH_TO_NESTED_SUBVOLUME So in your case the ones with docker.

metal450 commented 4 years ago

Yes, mine was due to docker. Which it seems like is a common enough situation that it should be able to detect without users having to find this issue thread & fix by hand.

teejee2008 commented 4 years ago

It's not just Docker. This issue can also be caused by other applications that create BTRFS subvolumes. At the same time, there are Docker users who have never faced this issue.

metal450 commented 4 years ago

It's not just Docker. This issue can also be caused by other applications that create BTRFS subvolumes.

To me that makes it seem even more impactful, knowing that it's likely happening to users for all sorts of other reasons. Users who may not be lucky enough to find their way here (it took me a fair bit of searching to do so).

At the same time, there are Docker users who have never faced this issue.

Which no doubt makes it harder to track down, but doesn't mean it isn't a bug. Just an intermittent bug.

teejee2008 commented 4 years ago

Feel free to investigate and fix the issue if you have time

metal450 commented 4 years ago

This is literally my first month of working in the Linux world - just trying to get everything running reliably. Debugging code someone else's app that works with a filesystem I barely understand in an OS I'm just starting to learn = not really feasible, unfortunately.

neildarlow commented 4 years ago

Hi, I commented on this situation while running Linux Mint 19 (Tara) and am now running Linux Mint 19.3 (Tricia).

I no longer see this occur after changing the settings from performing snapshots on Boot and Daily (2 of each stored) to Daily only (5 stored).

I have performed restores following problematic package updates and everything works as expected.

emanuc commented 4 years ago

I haven't had any problems setting snapshots anymore either: 1 boot, 3 weekly.

metal450 commented 4 years ago

Mine was on Mint 19.3 Tricia when the problem occurred. No repeats since that first time.

metal450 commented 4 years ago

Happened yet again. This is a completely different system, running Kubuntu 20.04. Timeshift 20.03.

Incidentally, last time, following the suggestions above to manually delete the docker subvolumes located within the snapshots completely hosed my docker data, so that wasn't a great solution either. Hours lost trying to figure out how to fix Timeshift, then hours lost trying to fix Docker as a result of fixing Timeshift.

metal450 commented 4 years ago

...And again.

I changed Docker to explicitly not use the btrfs storage driver, preventing it from creating any btrfs snapshots. This time, the extra/nested snapshot that was blocking it from deleting was timeshift-btrfs/snapshots/2020-06-13_10-44-57/@/swap, which I had to delete manually, which then broke my swap, which I had to recreate.

Seems like this is a monthly occurrence.

hereisderek commented 4 years ago

...And again.

I changed Docker to explicitly not use the btrfs storage driver, preventing it from creating any btrfs snapshots. This time, the extra/nested snapshot that was blocking it from deleting was timeshift-btrfs/snapshots/2020-06-13_10-44-57/@/swap, which I had to delete manually, which then broke my swap, which I had to recreate.

Seems like this is a monthly occurrence.

I'm using a similar setup, ubuntu 20.04 running on btrfs, with the latest docker and timeshift installed, I just noticed my docker command running VERY VERY slow (even just docker ps), and until when I wasn't able to load my desktop anymore (stuck in the solid color screen before even loading the login screen). I tried to ssh into it and hoping upgrading to 20.10 would fix things

I'm not sure if it was btrfs is becoming very slow or to I have too many snapshot backups. I'm running apt upgrade with one kernel upgrade, and it has been 40 min now still doing the snapshot

MisterMisunderstood commented 3 years ago

I am also facing all of the above problems. My exit from the timeshift --check command:

`ricardo@Neon:~$ sudo timeshift --check [sudo] senha para ricardo: Using system disk as snapshot device for creating snapshots in BTRFS mode

/dev/sda3 is mounted at: /run/timeshift/backup, options: rw,relatime,space_cache,autodefrag,subvolid=5,subvol=/

Scheduled snapshots are disabled - Nothing to do!

Removing snapshots (un-tagged):

Removing snapshot: 2021-04-28_02-00-01 Deleting subvolume: @ (Id:2138) E: ERROR: Not a Btrfs subvolume: Invalid argument

E: Failed to delete snapshot nested subvolume: '/run/timeshift/backup/timeshift-btrfs/snapshots/2021-04-28_02-00-01/@' E: Failed to remove snapshot: 2021-04-28_02-00-01

Removing snapshot: 2021-04-28_03-00-02 Deleting subvolume: @ (Id:2139) E: ERROR: Not a Btrfs subvolume: Invalid argument

E: Failed to delete snapshot nested subvolume: '/run/timeshift/backup/timeshift-btrfs/snapshots/2021-04-28_03-00-02/@' E: Failed to remove snapshot: 2021-04-28_03-00-02

Removing snapshots (marked for deletion):

Removing snapshot: 2021-04-28_00-34-19 Deleting subvolume: @ (Id:2137) E: ERROR: Not a Btrfs subvolume: Invalid argument

E: Failed to delete snapshot nested subvolume: '/run/timeshift/backup/timeshift-btrfs/snapshots/2021-04-28_00-34-19/@' E: Failed to remove snapshot: 2021-04-28_00-34-19 ------------------------------------------------------------------------------`

MisterMisunderstood commented 3 years ago

I am also facing all of the above problems. My exit from the timeshift --check command:

`ricardo@Neon:~$ sudo timeshift --check [sudo] senha para ricardo: Using system disk as snapshot device for creating snapshots in BTRFS mode

/dev/sda3 is mounted at: /run/timeshift/backup, options: rw,relatime,space_cache,autodefrag,subvolid=5,subvol=/

Scheduled snapshots are disabled - Nothing to do!

Removing snapshots (un-tagged):

Removing snapshot: 2021-04-28_02-00-01 Deleting subvolume: @ (Id:2138) E: ERROR: Not a Btrfs subvolume: Invalid argument

E: Failed to delete snapshot nested subvolume: '/run/timeshift/backup/timeshift-btrfs/snapshots/2021-04-28_02-00-01/@'

E: Failed to remove snapshot: 2021-04-28_02-00-01 Removing snapshot: 2021-04-28_03-00-02 Deleting subvolume: @ (Id:2139) E: ERROR: Not a Btrfs subvolume: Invalid argument

E: Failed to delete snapshot nested subvolume: '/run/timeshift/backup/timeshift-btrfs/snapshots/2021-04-28_03-00-02/@'

E: Failed to remove snapshot: 2021-04-28_03-00-02

Removing snapshots (marked for deletion):

Removing snapshot: 2021-04-28_00-34-19 Deleting subvolume: @ (Id:2137) E: ERROR: Not a Btrfs subvolume: Invalid argument

E: Failed to delete snapshot nested subvolume: '/run/timeshift/backup/timeshift-btrfs/snapshots/2021-04-28_00-34-19/@' E: Failed to remove snapshot: 2021-04-28_00-34-19 ------------------------------------------------------------------------------`

Guys, I managed to solve the problem by doing the following: I manually deleted the backups, in /run/timeshift/backup/timeshift-btrfs/snapshots/ from the terminal with the command "rm -frdv ./2021-*" (takes a long time!) Then I deleted the /run/timeshift/backup/timeshift-btrfs directory

Afterwards, I realized that there was a directory in the root with the name "@" without quotes, among other directories that should not be in the root directory, such as "Desktop", "Templates" etc. I deleted everything that was not part of it. The "@" directory was just a directory, not a subvolume. None of the folders contained files, they were empty. I don't know what happened to these directories to appear there.

Then, I uninstalled the timeshift completely, restarted the system and reinstalled the timeshift again. I added the backup schedule of everything went back to work.

Distro: KDE Neon base Ubuntu 20.04

fuomag9 commented 3 years ago

Same issue on kubuntu 21.04

sudo btrfs subvolume list /run/timeshift/backup
ID 256 gen 35883 top level 5 path timeshift-btrfs/snapshots/2021-06-22_13-14-30/@
ID 909 gen 32406 top level 256 path timeshift-btrfs/snapshots/2021-06-22_13-14-30/@/var/lib/portables
ID 910 gen 32407 top level 256 path timeshift-btrfs/snapshots/2021-06-22_13-14-30/@/var/lib/machines
ID 913 gen 35950 top level 5 path @home
ID 914 gen 35950 top level 5 path @
emanuc commented 3 years ago

Same issue on kubuntu 21.04

sudo btrfs subvolume list /run/timeshift/backup
ID 256 gen 35883 top level 5 path timeshift-btrfs/snapshots/2021-06-22_13-14-30/@
ID 909 gen 32406 top level 256 path timeshift-btrfs/snapshots/2021-06-22_13-14-30/@/var/lib/portables
ID 910 gen 32407 top level 256 path timeshift-btrfs/snapshots/2021-06-22_13-14-30/@/var/lib/machines
ID 913 gen 35950 top level 5 path @home
ID 914 gen 35950 top level 5 path @

Delete nested subvolumes, systemd created them.

sudo btrfs subvol delete /run/timeshift/backup/timeshift-btrfs/snapshots/2021-06-22_13-14-30/@/var/lib/portables
sudo btrfs subvol delete /run/timeshift/backup/timeshift-btrfs/snapshots/2021-06-22_13-14-30/@/var/lib//machines

Now from the Timeshift GUI you can delete snapshots

fuomag9 commented 3 years ago

Same issue on kubuntu 21.04

sudo btrfs subvolume list /run/timeshift/backup
ID 256 gen 35883 top level 5 path timeshift-btrfs/snapshots/2021-06-22_13-14-30/@
ID 909 gen 32406 top level 256 path timeshift-btrfs/snapshots/2021-06-22_13-14-30/@/var/lib/portables
ID 910 gen 32407 top level 256 path timeshift-btrfs/snapshots/2021-06-22_13-14-30/@/var/lib/machines
ID 913 gen 35950 top level 5 path @home
ID 914 gen 35950 top level 5 path @

Delete nested subvolumes, systemd created them.

sudo btrfs subvol delete /run/timeshift/backup/timeshift-btrfs/snapshots/2021-06-22_13-14-30/@/var/lib/portables
sudo btrfs subvol delete /run/timeshift/backup/timeshift-btrfs/snapshots/2021-06-22_13-14-30/@/var/lib//machines

Now from the Timeshift GUI you can delete snapshots

Thanks, this worked but I wish there was a way to do this from the GUI, since we know those are releated to the snapshots timeshift created and not something else (or at least getting a prompt for confirmation instead of the deletion process failing)