Make Debian Fun Again And Learn How To Do Other Cool Stuff Too

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
DATE CHECKED THIS PAGE WAS VALID: 29/08/2023

Addendum to the guide:

When I wrote this qgroups was a feature of Timeshift. It has now been removed and you should disable qgroups also on btrfs volumes (unless you need it for some reason). Here is a quick note on removing qgroups.

To check if its enabled you would use:
<code>
sudo btrfs qgroup show /
</code>

where / is the btrfs filesystem (in this example root) and it will show either quota entries or say its not enabled.

To delete the entries you would use:
<code>
sudo btrfs qgroup destroy 0/5329 /
</code>

Where the 0/5329 is one of the entries the previous command returns. This deletes them.

To then disable qgroups on a volume you would use 
<code>
sudo btrfs quota disable /
</code>

--------------------------------

<del>Addendum: Please note - btrfs space_cache is now replaced by a newer version space_cache=v2. If you see "space_cache" it can be replaced with "space_cache=v2" instead. This is because space cache v2 became stable after some time and is the newer option.</del>

Addendum 2: There was a short period where you had to specify space_cache=v2 but with release of Debian 12 this is no longer true. Simply specifying space_cache defaults to v2 so it is no longer required to specify the =v2 anymore once again. You can 100% just put space_cache and that is enough.

Ok So we just installed Debian stable if you followed the install guide and before updating to Debian testing it would be advantageous to first get timeshift going so that we can roll back no matter what without starting again, even if we totally break the system and its completely borked. **It is possible to create an @home during install but I wanted to show you that fixing a mistake is possible as it is important to know that you should never have to reinstall to fix a problem. All problems can be fixed with enough know how, as in linux everything is just a file on a disk, so if you edit the correct files on the disk and create the correct things then it must work. This is an inescapable truth about linux in general. Everything is a file. The only reason something is broken is because you dont have the knowledge on what file(s) to edit to fix it. Never forget this fact. **

So lets first review that our @ subvolume is working after installing and everything is as we expect. Obviously we want the @ subvolume in fstab on the / mountpoint during install but what does that mean? How do we access it?

If we open a terminal our fstab looks like this currently:

{{:images:fstabnewdeb.png|}}

Okay so how do we *know* its working. Well we can access that mountpoint if we mount it. Take a look here in this example:

{{:images:showatfs.png|}}

I wont write out the code typed in the terminal here because its more important to understand why we are doing this and what it achieves than memorizing these commands if its your first time. 

So the point is we can see that the @ subvolume does actually work as expected. If you would like to verify yourself you can check using the commands in the screenshot and hopefully understand that we can now mount subvolumes as normal disk mounts. The great thing is when we snapshot, as we will see, they become additional dated mountpoints that you can just browse and copy out files if you want. So if you have a file, edit it and then make a snapshot, then edit it again, then you can browse that subvolume for the file prior to your edits and get it back. This is very useful as you can take snapshots of your system prior to ding something, like upgrading it, and if it totally breaks just roll back. **However for greatest flexibility we want the @ and @home to be separate.** This way we can roll back files in our /home without changing our installed system, say if we lose a critical document by mistake, or alternatively we can roll back a bad update to our system that stops us booting without losing the contents of our /home directory. 

So how do we achieve this.

Well as we are manipulating home, we cant be logged in as a user with a home directory. To work around this we will be forced to create a root password and login as root from a terminal.
So while still logged in as your user lets do that:

<code>
sudo passwd root
</code>

Ok so follow the prompts and get a password set. Once we have one we will edit our fstab prior to actually creating our new /home. This is fine so long as we dont reboot the computer until we are ready to do so. The correct order would be to first create our subvolume then edit fstab but we are sneakily going to do it out of order and be very careful. So lets edit the fstab in nano so we can easily copy and paste and change just a couple values for our /home.

You can use nano or gedit but I will use gedit for this example (either apt-get install gedit or use nano /etc/fstab instead):

<code>
sudo gedit /etc/fstab
</code>



Well first lets make a new subvolume for @ home:
Now copy and paste the line that looks like this:
UUID=f0c8474c-e0dd-489a-af83-79b61e879de5 /               btrfs   defaults,noatime,compress=lzo,discard=async,space_cache,subvol=@ 0       0

Note: ssd option for btrfs is depreciated and not used anymore. Dont forget at the beginning of the guide it mentioned using space_cache now.

Obviously your UUID will be different. We are looking for the line with / and subvol=@ in it.

Now make a copy of this line underneath it and change the / to /home and the @ to @home and click save. (You are copying a line and making 2 edits to it essentially).

Example:

{{:images:editfstabdeb.png|}}

Wonderful, now thats saved we will do the second step which is really the first step but we did it out of order so now its the second step (Can do the steps the other way around it does not matter).

So log out of debian in the top right and side. Do not restart or any funny business like that, we are logging out. Once back on the login screen we will now access a terminal by pressing ctrl-alt-f4. We are now at a terminal like this:

{{:images:terminaldeb.png|}}

Incredible. Now we login with the user 'root' and the password you set earlier. Once logged in with user root you can now create the subvolume.

<code>
mkdir /mnt/Temp
mount /dev/vdaxxx /mnt/Temp
*Note: vdaxxx is your hdd mountpoint.*
cd /mnt/Temp
btrfs subvolume create @home
btrfs subvolume list .
</code>

Please see my screenshot also showing an incorrect way to create @home. It is important you do not create @home under the @ subvolume in the initial part of the screenshot I do this to show you the incorrect way, and then fix it to show you the correct way. You can see the final list command shows that @ and @home are both level5 and @home is not nested beneath @. This is important or you are bypassing the ability to snapshot @home separately from @.

{{:images:examplehomesubvolcreate.png|}}

You must also move your home folder. The exact command will depend on your home folder name but it will be something like:

<code>
mv /mnt/Temp/\@/home/peter /mnt/Temp/\@home/   (note debian 12 you can use format like mv /mnt/Temp/@/home/username and so on)

chown -R peter /mnt/Temp/\@home/peter
</code>

Please note that if you happen to have a large home directory the mv command will take a long time to process and provides no feedback while moving files. Do not interrupt the command. Now we have created the subvolume and moved the home folder of our account we can reboot and let fstab mount it correctly. To reboot just type 'reboot' in the terminal.

Once back up, login normally and if you followed the steps correctly then everything will be working. If you did not your system is broken and will need to be repaired from a live cd or you can start again with the install. Fixing it is not hard with a live cd but I can understand that it might be daunting for newer users. You can always ask for help on reddit. You will essentially need to be able to login as root to fix the issue via a terminal and review what you did wrong.

Either way if you did manage to complete the steps you now log in and everything is normal. typing 'sudo btrfs subvol list .' in a terminal will show you the subvolumes and typing 'mount' will show you the @home being mounted.

But now we have everything in place for timeshift. Lets install timeshift from the terminal with:

<code>
sudo apt-get install timeshift
</code>

By the way you can always search for a package with : 

<code>
sudo apt-cache search timeshift
</code>

And that will search all packages with the keyword 'timeshift'.

Once installed it will be a GUI app in the activities menu. Just type timeshift in the search.

Timeshift opens like this:

{{:images:timeshiftopen.png|}}

So select BTRFS and select next, The snapshot disk is typically the same disk as you installed on (ie its not a backup its a failsafe to allow reverting snapshots not protect against hardware failure). So just select the same hard disk you installed on (if you choose a different disk then snapshots will be very slow and this should not be done, its not really what is the intention of snapshots). Next it asks what to keep. Normally You dont want more than 32 snapshots or the disk starts getting a bit slow. As in 32 total. I just set the below, however for best performance try keep it to max 10 snapshots as they can become slow:

{{:images:scheduledeb.png|}}

That is around 20 which is fine and give you plenty to look back on. Anything else you should refer to your backup set. Another thing to note is the automatic backups per schedule wont happen if you have Timeshift open for some reason. You must leave Timeshift closed. Also, the hourly always happen on the hour, so you will need to wait for an hour to pass + whatever was remaining for the current hour. So if the time was 9:23, your first hourly backup would be at 11:00. The reboot schedule also seems to have a delay on it so if you reboot and immediately open Timeshift you wont see any snapshot. Just go get a coffee or something and leave it like 15 minutes after a reboot or check after 2 hours have passed to see auto snapshots getting made. It doesn't like being watched. 

So hit next and on the next screen you can go ahead and tick the "include @home in backups" if you want. I do because this will allow you to restore deleted files from your @home which is useful. 

Once you are done selecting all your options just click finish. You can create a manual snapshot by clicking the create button as a test.

Now you can go break your system, or in our case test it out. If you want you can create a file in your home directory and then restore the snapshot, If you click "restore @home subvolume" when you do the restore you will then also wipe out any changes you have made in your home directory since the last snapshot. So I will show you here. 

Here I have created a test file and am about to restore a snapshot (you can also choose browse to browse a time in the past if desired):

{{:images:restore.png|}}

You now reboot the system as normal and will note everything is restored to exactly when the snapshot was taken:

{{:images:nofiles.png|}}

One thing to note is that manual snapshots don't seem to be removed by Timeshift so you should remember to delete them when you are done with a manual snapshot as they consume more and more space over time.

So now I have completed this test I will go delete the snapshots I don't want.

But what if the system doesn't boot? How can one restore a snapshot if you cant open Timeshift?
Well there is an answer for that too. I will make a new snapshot and then remove all of gnome as a sort of simulation in what to do if the system is not working after a bad update. We will pretend we cant boot it even and instead fix it with a live CD of Ubuntu as its a very convenient live CD to use to repair issues.

So I have created a snapshot and totally 'broken' the install by running sudo apt-get purge gnome* and rebooting:

{{:images:breakdeb.png|}}
{{:images:ohnobroken.png|}}

Lets imagine we cant even login or something so bad has happened we have no method of recovery at all.
Well we can boot a live CD and run Timeshift. We will use the Ubuntu live image we download in the install step to Ventoy and just boot it into Ubuntu. I have clicked "try Ubuntu" here and opened a terminal:

{{:images:tryubuntu.png|}}

Now type the following:
<code>
sudo apt-add-repository -y ppa:teejee2008/ppa
sudo apt-get update
sudo apt-get install timeshift
</code>

If like me you got an error that jammy didn't have a release file yet you will need to edit the sources file to be the previous version of Ubuntu (for me this is impish).

<code>
sudo nano /etc/apt/sources.list.d/teejee2008-ubuntu-ppa-jammy.list
</code>

replace the name "jammy" in that file with "impish":

{{:images:sources.list.png|}}

Save with ctrl-x and press y. 
Obviously in an installed distribution you will NEVER mix sources as I have just done on a live CD. Doing so will break your system and only a fool of a took would ever do such a thing. However for a live CD we can just do whatever we want as nothing will happen if it breaks. We can just reboot and start again.

Now we have changed the sources we can try install again:

<code>
sudo apt-get update
sudo apt-get install timeshift
</code>

At this point you can open Timeshift from the GUI and believe you can restore by clicking cancel on the setup and restoring normally. However I never do that and have never tested it. Instead I use Timeshift from the CLI:

So I run:

<code>
sudo timeshift --restore --btrfs
</code>

I select my disk and then it lists the snapshots I can restore from:

{{:images:restoretimeshiftcli.png|}}

Now it wants me to press enter and confirm with 'y' reboot. Reboot by:

<code>
sudo reboot
</code>

Remember to remove the USB/ISO image and get back into your restored Debian system :)

{{:images:hoorayfixeddeb.png|}}

There you go! Now you know how to run around and completely break your Linux install and never not be able to revert. **You will always have a working Debian to boot into by reverting back to the time before you broke it. Now lets get on with setting up more fun an experimental stuff happy in the knowledge we cannot fail, by design.**

In the guide if things break I dont use Timeshift, instead I try to show you how to fix them so that you can learn what has happened, but we always have Timeshift to fall back on if need be.

Don't forget to clear any manual snapshots you don't need. Restoring a snapshot also created one ondemand snapshot in case you want to undo the restore so you will need to delete at least 1 manual snapshot if everything is back up and working.

If you are on stable, you can now upgrade to testing from the main page :)

=== Notes ===
Notes:
If your system is not super fast then you will need to turn off qgroups as your system will pause/hang during snapshot creation. This is very annoying if you have it set to hourly. Another issue that can happen is sometimes the qgroups get corrupted/orphaned and they might have worked before and then stop working and cause the hanging when they did not hang the system previously. The easiest way to correct this is to delete all the snapshots on the system so there are no snapshots at all then use 'sudo btrfs qgroup show /' - if any qgroups are listed at all then they need to be deleted eg: 'sudo btrfs qgroup destroy 0/5 /'.

Once you have no snapshots and no qgroups at all then snapshotting seems repaired and wont hang the system although you can get hangs if you have too many snapshots or some issue occurs with them again (typically caused by unclean shutdown etc). They are troublesome but I find they dont cause me an issue if everything is clean and nothing is orphaned etc. 

Also note qgroups is an older issue that is no longer a problem (as they are disabled by Debian 12 onwards anyway).
Make Debian Fun Again And Learn How To Do Other Cool Stuff Too

User Tools

Site Tools

Page Tools
