Once I figure out what to fix I’d happily do this.
1 Like
@2000
Not sure why but it’s not co-operating. Anyway i won’t waste anymore of your time. I don’t have a problem reinstalling it.
I wanted to ask what is the main difference between using raid 1 instead of having snapshots? I have two 500 GB nvme drives so that’s another thing i’m interested in. Raid 1 with btrfs and encryption would be okay also.
Not a waste of time; it’s problem-solving! 
There definitely is something different with the new ISO. I’ll start investigating next week.
You can combine both concepts if you want to.
With raid1 you just have a mirror in case a drive dies. If you need to recover a deleted file or recover from a botched update, the raid won’t be any help as it holds identical data.
You can have snapshots on a single drive and on a raid system. In both cases you’ll be able to revert to a snapshot state.
1 Like
Thanks for your expertise. I’ll keep trying this and maybe something will be figured out.
1 Like
@2000
Okay… I did a full reinstall and I’m getting the same thing. So I’m wondering if I’m doing something wrong? In the instructions at #04. Am i supposed to create a swap partition? Or just enter that in the terminal which is what i have been doing.
Everything looks like it’s working except hibernation so when i boot i get no resume device for hibernation. When i try hibernation it shuts off after a short time.
Myabe swap is too small make it 2x ram.
Ram is 32 GB
@2000
Okay i think i have this working now. Suspend works but on hibernation it has to decypt and it’s almost like it’s a reboot? I’m just not sure how this is suppose to work. With suspend it just comes back no decryption necessary.
Edit: Suspend works awesome. Screen is locked when it resumes. With Hibernation it almost seems like it boots which i understand it is loading from a saved file on the hard drive? But, you have to decrypt it to open and enter as if booting. How do i know it’s working properly?
Hurray, this is exactly the way it is supposed to work.
Suspend just keeps the systems state in RAM, so you can revive from it near instantaneously. For security reasons you’re usually greeted with a screen lock. Suspend needs a tiny amount of power (outlet or laptops battery) to keep the memory in RAM.
Hibernate is like a shutdown, but your systems state is written to the drive (the swapfile). When you reboot this system state is then reactivated and you can start working exactly where you left off. Just like a normal boot you have to decrypt the boot device. Unlike suspend this doesn’t use any power.
If you could just shortly describe what finally did the trick, I’d be really thankful.
1 Like
Well first of all i reinstalled and i had three desktops booting from separate drives. So i had removed them and then i found another site with same commands i think but for some reason they worked when i had tried and they didn’t? 
I’m sure they are the same?
I also added the resume info in /etc/default/grub and updated with sudo grub-mkconfig -o /boot/grub/grub.cfg
Edit: So normally you would include the @home in timeshift?
1 Like
You could activate this in Timeshift’s settings without problems. When restoring, Timeshift will then explicitly ask if you also want to restore @home or only @root.
I personally mostly only make automated snapshots of @root before an update because I almost excusively need these to get me out of trouble when an update went wrong. For this only @root needs to be restored; you normally wouldn’t want to loose the personal data that changed during the time of your snapshot and when you notice you need to revert.
For software testing reasons I very seldom also make a manual snapshot of @home alongside @root so I can restore the whole system after trying out some stuff.
My /home data is covered by my backup scheme so I don’t need snapshots to get me out of trouble here.
Lastly, note that having a large number of snapshots could potentially cause system slowdowns. This is why I try to limit the total number, size and age of my snapshots.
Is this not done with Timeshift? Sorry if i’m a little confused. I have never used Timeshift.
Timeshift is primarily a ‘system’ level backup that can take you back in time to when it worked properly. Rarely do you want a system rescue to also revert changes to your data 
If you don’t rely on automatic, doing a snapshot right before an update can avoid the joy of chrooting, downgrading, and repairing if something breaks…
1 Like
I guess i don’t understand how the snapshot with btrfs is set up because timeshift is also used. I noticed in settings that @home wasn’t set. I’m going to have to get @2000 to explain how this works since it is his rodeo. I noticed this morning it did a snapshot before updating. Not sure if it does that every time there are updates? Is timeshift doing something different? Or is it tied into creating the snapshots?
Yes, that is the way it’s supposed to behave: Before running a system update (through pacman -Syu or yay) a snapshot of your @root should be taken automatically by Timeshift.
The default setting for Timeshift (timeshift-autosnap to be precise) is to keep up to five of these automatically created snapshots. So if you notice anything not working after an update you could just restore to a state before the update with the help of Timeshift.
I described how to restore to a snapshot in common scenarios in the first post (see post #1: # - How to RESTORE a snapshot (previous system state)).
Note that Timeshift is just a very helpful GUI-tool for creating, restoring and deleting btrfs-snapshots. All this can also be done manually through the command line without ever installing Timeshift; but this would overwhelm most btrfs first time users. So why not go the easy route?
[Edit] On the issue of @home not being snapshotted:
“data” here being your /home data. You wouldn’t want your latest paper on … also being reverted to an old state or even removed just because you want to undo an update.
But you can make Timeshift also take a snapshot of @home with @root in the settings if you really want/need to.
1 Like
Yes. I would be overwhelmed for sure. So a couple of things? Currently there is no home partition as your set up only has root. So what is your backup strategy and how do you do it? Do you use timeshift and just back up the @root and @home separately at different times? Also everything currently is backing up to my current drive. Do i need to change that in timeshift and use a different drive? I understand if the system goes haywire i can’t access it. Are you able to boot and chroot and access it? or it has to be done from another drive?
Oh, now I understand the misconception. 
No, the system does actually have multiple “partitions” in the way you would interpret them. Here, what in the case of ext4 for instance would normally be physically different partitions, are so called btrfs subvolumes.
If you check /etc/fstab you should notice that you actually have 4 distinct subvolumes (@root, which is actually only “@”, @home, @swap, @var-cache-pacman-pkg). Just like normal “partitions” these are mounted to specific locations; e. g. @root to “/”, @home to “/home”, @var-cache-pacman-pkg to “/var/cache/pacman/pkg”.
This way, even though /home is a subfolder of /, if you make a snapshot of the subvolume @root, the subvolume @home won’t be part of that snapshot. So you can revert to a different copy (snapshot) of @root without affecting your data in /home (@home).
Note that I specifically don’t recommend the use of snapshots as a real backup strategy but rather as a quick way of recovering when updates go wrong.
Like freebird54 said: “Timeshift is primarily a ‘system’ level backup that can take you back in time to when it worked properly. […] doing a snapshot right before an update can avoid the joy of chrooting, downgrading, and repairing if something breaks”
The btrfs-snapshots are stored on the same drive as your system is, this is a btrfs requirement, so if you have a hardware failure there is no way from recovering from that.
You could copy your snapshots to and from a different drive with the btrfs send and receive commands but because I’ve never lost access to a system in over 15 years and even if, it’s so easy and quick to set up a new system I don’t bother with backing up my /root.
Now, the data in /home is very important to me and needs to be backuped properly.
I use a combination of syncing to multiple other devices with Syncthing and backing up with rsync (rsnapshot daily, weekly, monthly) to an onsite nas, an offsite cloud storage and an offsite external drive.
2 Likes
If you think of snapshots as being able to get more than the root mount backed up, Timeshift should have an option to back up hidden files (think .config and .vscode) - it does when not on btrfs anyway. I do that, as it means less setting up again. Of course, without btrfs, you have your timeshift on a different drive (partition, whatever)…
Confused yet?
I’m understanding how it’s working with btrfs making snapshots of @root and you can add @home. So timeshift can also be used manually to do other backups but they are still really snapshots still? Or when you change it to rsync it’s different?
Well with rsync you copy whole file
You can use btrfs snapshots as backup
If you send the snapshot to another btrfs drive.
A backup is a copy on another drive
A snapshot is a copy on the same drive
2 Likes