Well this was a fun way to start my day. I was trying to install Davinci Resolve on my Mint PC (since Mint 22 broke some of Resolves dependencies), and it was still giving the warning of missing dependencies.
One of the dependencies libasound2 couldn’t install but apt recommended 2 others. Tried both and non worked. So I decided to uninstall both, and then Cinnamon Setting disappeared. I tried to fix it by reinstalling Cinnamon itself, but yeah… on reboot it would crash on the Mint file check.
However after trying the Recovery mode to get access to the terminal. I was able to access Timeshift, get the backup from yesterday and I’m back up and running.
So happy I enabled Timeshift. Hurray for safety nets actually working to protect me from myself.
I’ve been reluctant to use Timeshift (in rsync mode) because I’ve twice ended up hosed by it (quite possibly because of a fundamental misunderstanding).
Doesn’t Timeshift create snapshot files that your system ends up living in, much like VMware?
Case in point, I misconfigured the Timeshift backup location and wanted to correct it. I deleted snapshot files and went about pointing to the new location. But on reboot, all failed because the snapshot files were apparently live, and could no longer be found. I was dead in the water and had to reinstall. A few weeks later I tried again and ended up in the same situation where a snapshot location was removed and the system failed.
Now I’m afraid to use it.
I frequently read posts and other info like this that lead me to believe I just did something wrong and can benefit from using Timeshift, but I also don’t want to rely on running from snapshot files, and prefer my backup to live in snapshots, rather than my live system.
I’m used to snapshots in TrueNAS and virtualization, so this should be an easy transition, but experience has taught me fear.
Deleting snapshots shouldn’t destroy the system as far as I know. It might confuse Timeshift later down the line if that deletion was done outside of Timeshift’s interface, but they’re supposed to be entirely separate.
Timeshift creates a directory called “timeshift” in the root of whatever partition it’s configured to use. It should create at least one copy of every file, but it does then create hard links to save space between snapshots where files would otherwise be identical. Those links shouldn’t be to (or from) live system files though.
Now, if someone was to bypass Timeshift and manually move files of the timeshift directory back into a live system or manually link live system locations into a snapshot, that might lead to the problem you experienced. Not sure if that’s what’s happened.
It’s worth noting that I have Timeshift set to create its directory in a separate partition on a different physical drive, so if it was broken in some way, it would struggle to mess up. Hard links across partition boundaries are a lot harder to achieve if not impossible, so it would stop someone (or something) trying to bypass Timeshift, or at the very least give them pause for thought. And it would provide some protection against Timeshift doing something silly as well.
Another way I suspect this could happen is if Timeshift’s own copy as well as all hard links to it in all snapshots were manually deleted before a restore was attempted. Can’t restore from what doesn’t exist, and so the system would remain broken.
I think the first time I hosed it, I may have canceled the backup mid-process because I realized it wasn’t configured properly. Then I found and deleted snapshot files, IIRC, and things went south from there.
I’ll try again, but only on a fresh system with no value to me, not my daily driver. I know I can harness it, but for now I’m sceeeured.