Skip to content
This repository has been archived by the owner on Oct 16, 2022. It is now read-only.

Timeshift makes disk full #332

Closed
ghost opened this issue Oct 16, 2018 · 29 comments
Closed

Timeshift makes disk full #332

ghost opened this issue Oct 16, 2018 · 29 comments
Assignees
Milestone

Comments

@ghost
Copy link

ghost commented Oct 16, 2018

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:

  1. Start TimeShift to save snapshots on your own HD;
  2. It keeps copying until there's no more space available on the HD.

Expected behavior
It should detect that there's few disk space and whether warn the user whether stop the snapshot.

System:

  • Linux Distribution Name and Version: Linux Mint 18.2 and 19
  • Desktop MATE
@OptogeneticsandNeuralEngineeringCore

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.

screenshot from 2018-10-17 09-03-07

@johnnyquest
Copy link

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

@rshamsnejad
Copy link

rshamsnejad commented Nov 25, 2018

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.

@teejee2008 teejee2008 self-assigned this Dec 6, 2018
@teejee2008 teejee2008 added this to the v18.12 milestone Dec 6, 2018
@mytvpro
Copy link

mytvpro commented Mar 26, 2019

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

@cedricgannet
Copy link

This caused me grief upgrading from Mint 18.2 xfce to Mint 19. I used the mintupgrade tool - sudo mintupgrade install and was prompted to install timeshift first. Had to clear enough disk space but succeeded in making a snapshot of the Mint 18.2 installation. After installing LightDM I was allowed to complete the upgrade and everything worked. Booted into Mint 19, all well, made a few adjustments and then left desk to deal with real world.

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:
2019-04-22_22-05-07_gui.log
2019-04-22_22-00-01_backup.log
2019-04-22_21-52-47_gui.log
2019-04-22_16-00-01_backup.log
2019-04-22_15-00-01_backup.log
2019-04-22_14-04-08_gui.log
2019-04-22_14-00-01_backup.log

There was another file called 2019-04-22_17-00-01_backup which wouldn't upload as it was empty.

@ghost
Copy link
Author

ghost commented Apr 24, 2019

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?

@teejee2008 teejee2008 modified the milestones: v19.08, v19.10 Aug 11, 2019
@Enjymon
Copy link

Enjymon commented Sep 8, 2019

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:
1- Timeshift won't actively warn when the partition is full and will just silently stop making snapshots.
2- Also, as noted somewhere else, the folder(s) of the aborted snapshot(s) won't show up in the GUI and one has to remove such folder(s) manually by accessing the file manager through the GUI.

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

@Mrodent
Copy link

Mrodent commented Apr 4, 2020

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.

@cedricgannet
Copy link

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:

  • Setting to limit the operation of the programme when the patrtition is more than x% full (say 95% by default).

  • Automatic dialogue pop-up when the limit is reached.

@atzmon
Copy link

atzmon commented May 31, 2020

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.

Not sure if this is the same issue but I'll add my own experience in case it helps.

A few weeks ago I installed TimeShift on a fresh installation of Ubuntu 20.04 and set it to keep 5 daily snapshots, 2 weeklies and 2 boots. Two days ago this took about 11 GB of storage, including two weeklies and one boot.

Yesterday it suddenly started taking up more and more space, around 130 GB. I could literally see the disk available space dropping at a very fast rate until I got the OS alert for a full disk. Had to delete the snapshots and (hopefully temporarily) uninstall TimeShift.

@AndreiMiculita
Copy link

AndreiMiculita commented Jul 14, 2020

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.

@tkivisik
Copy link

tkivisik commented Dec 7, 2020

It also filled my partition. I manually removed the snapshot from the command line at /timeshift/snapshots before reboot to avoid getting locked out.

I believe Timeshift calculates the disk usage by the full disk (not partition) which leads to the wrong estimate of free space.

@stefan123t
Copy link

stefan123t commented Jan 27, 2021

@teejee2008 many thanks for your great software and contribution to a common problem, backup and setup of snapshots under Linux in general!
As far as I can see from this issue there are multiple causes and therefor possible resolutions to prevent this from happening in the future:

  1. timeshift backups its own folder -> this should be excluded or warned about generally
  2. timeshift backups the /var folder -> this should raise a warning too if not specified exclusively on the include / exclude list
  3. timeshift backups external /media folders -> these filesystems are usually external connected or otherwise mounted via userfs, hence they could be excluded in general too
  4. timeshift destination for backups is on the same filesystem as the source of the backup, which can lead to the dreaded disk full symptom experienced by many users -> it should be a common suggestion to use a separate partition or external media for timeshift destination. Maybe some checks should be implemented to prevent users from setting it up that way in the first place either in timeshift or using a default config through the package maintainers.
  5. timeshift can fill the disk until a certain threshold is reached (1GB) -> this change has been implemented above, but the warning / failure to perform the backup is not brought to the users attention (notification system), dunno the exact status.
  6. timeshift does only calculate the free space left for backups. It is not configurable to show the space allocated for it to be used for the backups or keep at least space for another timeslice plus amount X GB free for the next daily backup (or whatever the shortest frequency is) -> timeshift could store the size of its backup timeslices in the /timeshift/snapshots//info.json therefor knowing how much storage it will use for the next slice and raise warnings when free diskspace is below the storage needed for another N timeslices.
  7. timeshift does also backup files which are extremely large, ie. movies, isos, flatpak/snapd/AppImage binaries -> it would be good to have a threshold for file- and/or folder sizes in the include / exclude list. I assume this might be added to the rsync / find commands run in the background for each list entry.
  8. timeshift debian package does not ask the users whether to purge the /timeshift/ folder upon removal of the package -> looking at Timeshift potentially fills hard disk 100% jmunixusers/cs-vm-build#200 the problem might be in the packaging, i.e. removing / purging the package from a system may ask to keep the timeshift slices or remove some or all.

I am on Timeshift v20.03 / Linux Mint 20.0
Hope some of these can be approached in the future.
Thanks, Stefan

@ghost
Copy link

ghost commented Feb 20, 2021

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

What my system sees:
Screenshot_2021-02-20_21-11-26

What Timeshift sees:
Screenshot_2021-02-20_21-11-41
Screenshot_2021-02-20_21-21-12

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.

  1. Detect available space CORRECTLY - Words fail me;
  2. Determine the accurate size of the pending snapshot - Goes without saying;
  3. Allow user to select a suitable time slot for snapshots;
  4. Determine if [available space] - [snapshot size] > [minimum free space]. If not, DO NOT snapshot, inform the user - Obvious to me and many others;
  5. Clear and concise feedback to the user at the time of use/snapshot - DON'T silently log it away from the user (this is one of the most frustrating 'features' of most Linux projects and it needs to stop!) What's so bad about informing the system's owner/current user as to the state of an error? I don't get it. I only found out about Timeshift's error by running it from the console - it would simply abend after running with no feedback! Almost non-existent error handling and obfuscated user feedback.
  6. Can we compress/archive these snapshots?
  7. Rolling snapshots - Deleting the oldest snaphot of current/any type to make room for most recent snapshot?
  8. More options for users to configure the behaviour for Timeshift on their system - Retention policies, disk space policies, clearer

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.

@westdam
Copy link

westdam commented Feb 22, 2021

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)

@stefan123t
Copy link

@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.
Also calculation of free space might be off by a lot, let's say you are making daily backups, then using rsync and hardlinks will probably not use much space at all, except for inodes. The same probably holds true for other filesystems like btrfs / zsf that are copy-on-write based and faciliate snapshots.

I assume the calculation that Timeshift uses is based on the "modern" ISO / SI Notion of biBits.
Though I still can't get used to it myself and there might be an option in Timeshift to change the display setting ?

From df man-page:
-h, --human-readable
print sizes in powers of 1024 (e.g., 1023M)
-H, --si
print sizes in powers of 1000 (e.g., 1.1G)

Could you verify (and/or post) your output of df -H as well ?

@DensmoreB
Copy link

DensmoreB commented Mar 3, 2021

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.

@BlueStar88
Copy link

BlueStar88 commented May 18, 2021

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.
I said "might", because I followed another (quite common) suggestion putting those partitions on RAID devices and timeshift might have an issue with such devices as well. At least it doesn't show the RAID virtual devices in snapshot locations overview. It just shows the two physical devices.

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

@teejee2008
Copy link
Owner

  1. The backup partition should have enough space. By default, the root partition is selected and automatic snapshots are disabled. Select a proper partition before you enable automatic snapshots.
  2. Don't keep too many snapshots if you don't have enough space
  3. Exclude any large folders that you don't need.

Closing this one.

@Nantris
Copy link

Nantris commented Feb 4, 2022

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.

@spikespaz
Copy link

Timeshift really is just a pile of sh*t.

@Nantris
Copy link

Nantris commented Feb 19, 2022

I'd be in better shape if I'd never installed it.

@dsbert
Copy link

dsbert commented Apr 29, 2022

Timeshift ate my hard drive too.

I used these steps to remedy it.

Note that timeshift --delete-all does not delete the actual files from your disk...

sudo killall timeshift
timeshift --delete-all
cd /timeshift/snapshots
sudo rm -rf .

@Nantris
Copy link

Nantris commented May 2, 2022

@dsbert I couldn't find the Timeshift snapshots on my drive with BTRFS to delete manually and timeshift fills the drive to the point it cannot actually run - so that's not a full workaround unfortunately.

@igorsantos07
Copy link

igorsantos07 commented Aug 30, 2022

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 🎉

@dsbert
Copy link

dsbert commented Aug 30, 2022

For the unaware - https://github.com/linuxmint/timeshift

@Nantris
Copy link

Nantris commented Aug 30, 2022

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.

@igorsantos07
Copy link

not ones that do harm without warning users of extremely important issues for no good reason other than to salve the creator's pride.

That's open source at its best 🙃
Too much code, too many bugs, too little time and money to actually take care of any of them.

@stefan123t
Copy link

I think you are doing @teejee2008 no good complaining here about a feature he never intended to implement in the first place.
After all this feature request has been closed for years. If you use timeshift and need these pre-cautionary checks you are free to implement them yourself.
Tony George still maintains this otherwise fine software amongst many other projects as you can see from the releases on his page https://teejeetech.com/2022/05/29/timeshift-v22-06/
Thanks Tony and maybe you could implement the changes from the Mint team which compares free space with the size required for the first (full) snapshot before deciding whether target space is enough. It will run a dryrun to estimate the required space only if the remaining space is scarce.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests