Timeshift makes disk full #332
Comments
Can confirm on Mint 19 Cinnamon. Timeshift has only one shapshot (about 3 GB), but Timeshift is using 17.7GB (per QDirStat). Additional reports: https://forums.linuxmint.com/viewtopic.php?t=270658 Does anyone know a quick work around to recover space, I am running low. Link above suggests use of fstrim, but I don't trust this. |
In my case what happened is timeshift started doing its backups to /var for some reason. Then, because it was also supposed to backup /var, it started backing up it's backups until it ran out of disk. For me the workaround was to add /var/timeshift as an exclude, that made the trick. (I'm not sure why it's backing up in /var, though, I don't think that'll work out well when trying to do a restore...) |
I ran into the same full disk problem, details here https://forums.linuxmint.com/viewtopic.php?f=247&t=281996 Summary : I mounted other partitions outside /media, the paths were not excluded (because I forgot) so they were included in snapshots, and with scheduled snapshots it ended up filling the disk. |
Happened to me and had to unmount the root filesystem and change the root password to even get into delete the snapshots which I had mistakenly put into the trash on previous space warnings |
This caused me grief upgrading from Mint 18.2 xfce to Mint 19. I used the mintupgrade tool - When I returned, computer had crashed. Rebooting succeeded but I got stuck in a login loop. Each time my credentials were entered, it sent me back to the login page. Tried deleting files using recovery option but space created seemed to disappear instantly. In the end, I cleared a lot of space, booted and logged in successfully. Found that Timeshift had created another complete snapshot of the new installation. Looks like when I cleared space, Timeshift simply used it up. When Mintupgrade had finished, I had Timeshift v18.6 and it effectively made my system unusable. I feel these sort of applications should, by default, leave the last few percent of the disk free and flag an error. Logs are attached: There was another file called 2019-04-22_17-00-01_backup which wouldn't upload as it was empty. |
Crazy. 6 months have passed since I have reported here this bug, and almost 1 and a half years since uselessly reporting it at launchpad, and such a serious bug is still there. That's why I dropped with both Timeshift and Linux Mint a long time ago. Instead, I highly recommend PCLinuxOS, a fantastically stable distro, with a great and supportive community, where folks really give you a hand when you're in trouble with your PC. PCLinuxOS has been around for more than 15 years, longer than Ubuntu (2004), Mint (2006), openSUSE (2005), Android (2007), Mageia (2011), Fedora (2004) and CentOS (2004), and it's systemd-free!! Why don't you give it a try? |
Using a dedicated partition for Timeshift avoids the risk of filling up the main partition with snapshots. I only encounter two problems with this configuration: It would be useful to have a notification when Timeshift detected that disk space was insufficient or when a snapshot did not go to completion, and then give some instruction about how (if desired) to remove the folder(s) of the incomplete snapshot(s). |
I also just experienced Timeshift filling up a partition. I had developed a degree of trust in it, so wasn't checking for something like this every few days. I just found that the last snapshot was 3 weeks ago. I would really like it if it could somehow issue a warning ... maybe by something blinking in the taskbar of the screen or something. There are so many annoying apps and things that bombard you with notifications, but for once I think one is needed. |
Since my last comment I've had no problems with TimeShift but, would I have known? I've had a few problem with disk space (new SSD on its way). It seems to me two things are needed:
|
Please ignore the text below (now in strikethrough). I figured out what happened, the issue I described was my own fault. I had mounted a folder from a NAS and did not add it to the exclude list in TimeShift. The mount wasn't permanent, I only mount that folder occasionally, so most of the time TimeShift worked as expected until that one time it ran when the folder was mounted.
|
Can also confirm this has also been happening to me. Repeatedly. Decided to reboot because I didn't know what was going on and got stuck on the login screen. Here is what worked for me: drop into a text terminal with ctrl+alt+f2, clean APT cache, remove old kernels. This is of course just a bandaid. |
It also filled my partition. I manually removed the snapshot from the command line at I believe Timeshift calculates the disk usage by the full disk (not partition) which leads to the wrong estimate of free space. |
@teejee2008 many thanks for your great software and contribution to a common problem, backup and setup of snapshots under Linux in general!
I am on Timeshift v20.03 / Linux Mint 20.0 |
I can confirm that this is still an issue with this 'application'. After so many years of this thread pointing out the problem, it's causes and multiple ways to 'get around' it. As a system recovery tool, I don't think it is in a state to be recommended let alone included in any distros until it has finished beta testing. IMHO I needs to conform to stricter standards of operation if we are to trust it - as a system recovery tool. Hard to do unless there is a rethink of the entire concept. Obviously this program seems to be causing the very problem it is written to fix - a corrupted system. My Timeshift (v19.08) is happy to inform me that I have 5.5GB free for Timeshift. Hint: I didn't... On ANY disk! I actually had 0 bytes free after it continually filled it up, causing X preferences and many other application preferences files to be come corrupted. My xfce menu and panels have partly reset their config as a result of this lack of free disk space - Most applications seem to flail and fail catastrophically, and silently, on running out of disk space lol It's honestly a pathetic situation to be in, when the best system in the world can't tell when its arse needs wiping. NONE of the running programs said ANYTHING about the lack of disk space! NONE! ALL of them failed silently, leaving me to piece together what was going on. This whole sh!tsh0w is NOT useful to anyone! I still have no idea where it was getting 5.5GB of free space from - NONE of my devices have 5.5 GB free space! O_o I freed up some space... Still confused as to how TS is working out how much free space it has to work in... It seems to be using it's own (very broken) disk query routines instead of asking the system, which had it right all this time! - Bad redundant code? As I mentioned before, maybe this application should be finished before people rely on it to recover their system. Indeed, relying on it seems to be the wrong thing to do! Does anyone have any ideas if there is an update as to what is happening with this system-breaking bug? There is little to no feedback as to the space it will take up, no checks to ensure it isn't filling up a disk or backing up files which are too large... Unless you have the prefect environment and know what it wants better that it, it is simply a liability to your system. One wonders what on Earth the developer(s) were thinking about how this was going to work. I, for one, would rather we have LESS of this breed of 'solution'. IMHO it needs to be able to accurately predict disk use for the upcoming snapshot and inform the user if there is going to be less than xGB of space after making said snapshot - Preferably on the desktop, via notification, at the time of taking the snapshot, but NOT hidden in a system log somewhere with no user feedback presented at all - as seems to be accepted rubric, for some illogical reason.
Apologies for the caps, but this is a ~3 year old issue, now - I am flabbergasted at the length of time this issue has been around for. If it can't be fixed, the project should be dropped, but not forced upon trusting people. It's a liability as is. And some people still wonder why Linux isn't going anywhere on the desktop... We need to stop treating the user like a mushroom and start using interfaces properly. Edit: I noticed this little gem in the description for Timeshift, too... "Timeshift is designed to protect system files and settings. It is NOT a backup tool and is not meant to protect user data. Entire contents of users' home directories are excluded by default. This has two advantages:" So, I need ANOTHER program to protect personalised software settings? Does Linux even have a standardised way of storing user preferences? ...So many ideas thought through to conclusion. Sometimes some humans just make the solution more trouble than the problem. |
hi,i'm on mint 20.1 mate. timeshift active 1 a month on a separate partition. i've got disk full during backup. , i've used a 150 gb partition for saving files. kernel 5.8.043 . also during backup the occupied space going to 100% and then later i can see free space ( righit now i've got 93gb free) |
@jcartner-young thanks for pointing the finger in the same direction and giving your shortlist of things to implement. Still I think Timeshift eases a problem and using it for manual backups prior to System upgrade is a good use. I assume the calculation that Timeshift uses is based on the "modern" ISO / SI Notion of biBits. From df man-page: Could you verify (and/or post) your output of df -H as well ? |
First off, anyone writing snapshots to the same drive as the OS is not thinking about recovery seriously enough. If something goes wrong with the disk all your recoveries are worthless. And yes if you are writing snapshots to the same partition you are going to fill up your partition and possibly brick your system. This is not a bug, this is user error. That said a smart and safe recovery program would detect available disk space before, and during backups. Do no harm, should be job #1. However there is a bug in the code. Apparently the free space calculation doesn't take into account the physical structure of the filesystem. It appears to be using a blocksize smaller than the size my OS uses. df -H shows a partition size of 503G and a usage size or 23GB and a free size of 455G. Timeshift reports 23GB used and freespace of 483GB. An odd number that doesn't add up under any scheme, and includes an extra 3GB. Not huge, but certainly wrong, and in actuality is reporting 28GB too much space. |
Today I got a call for help from a user. He too ran into the free space issue. Why? It might be, because I (as the admin in charge) followed another (quite common) suggestion to put the /home directory to a separate partition. So we have an OS partition size of 20GB and a HOME partition size of 450GB. Timeshift did its thing until everything crashed. Both aspects are non-default Mint setups, so nobody is to blame here. It's meant to be just a heads-up to consider doing those free space calculations differently and/or check, if software RAID is in place. Fun fact: The free space information to the bottom right of the timeshift window was correct in both regards: It showed the free space of the smaller OS partition and the virtual RAID path. Since timeshift wasn't configured by me, it did its thing by itself. Maybe having it disabled by default to protect against different setups (which timeshift cannot handle properly) is a better approach. Cheers. Edit: Used OS version: Mint 20.1 |
Closing this one. |
It's unbelievable this is closed with the amount of time I've wasted as a result of Timeshift filling a drive without warning or automated cleanup mechanism. This is not a problem with any other backup solution. Not filling the drive and making a machine unbootable is a standard expectation most people have for backup software. |
Timeshift really is just a pile of sh*t. |
I'd be in better shape if I'd never installed it. |
Timeshift ate my hard drive too. I used these steps to remedy it. Note that
|
@dsbert I couldn't find the Timeshift snapshots on my drive with BTRFS to delete manually and |
Incredible how many people complained about the lack of proper warnings and information, and the maintainer closed with "pay attention to what you're doing", as if the software wasn't responsible for properly reporting issues to the user. At least the Mint devs are doing something to patch up the issue, somehow 🎉 |
For the unaware - https://github.com/linuxmint/timeshift |
Unfortunately that won't save people who make the grave mistake of using this repo. I'm very appreciative of open source projects, but not ones that do harm without warning users of extremely important and unexpected caveats for no good reason other than to salve the creator's pride. In the end, our machine was essentially unrecoverable because we installed backup software. |
That's open source at its best 🙃 |
I think you are doing @teejee2008 no good complaining here about a feature he never intended to implement in the first place. |
Describe the bug
I reported this bug at Launchpad last year, where all the details are - https://bugs.launchpad.net/ubuntu/+bug/1738065. Thought that my case was an isolated one.
Recently new users have reported the same issue at both Launchpad and the Linux Mint forum:
https://forums.linuxmint.com/viewtopic.php?t=277654
https://forums.linuxmint.com/viewtopic.php?f=47&t=278083&sid=b3faaab7908a893bd314df6aa72b5246
https://forums.linuxmint.com/viewtopic.php?t=264436
To Reproduce
Steps to reproduce the behavior:
Expected behavior
It should detect that there's few disk space and whether warn the user whether stop the snapshot.
System:
The text was updated successfully, but these errors were encountered: