Announcement

**GreyGeek** · Jun 11, 2018, 01:31 PM

Probably because you didn't preface your command with "sudo".
"sudo -i" changes the environment to root's. "sudo " does not.
BTW, isn't snapper already in the Bionic repository? It is in Xenial and Neon.

**claydoh** · Jun 11, 2018, 03:54 PM

not the third party gui tool for it

**oldgeek** · Jun 11, 2018, 05:42 PM

OK, prefixing the last command with 'sudo' did the trick. But I got the following warnings. Is there anything to worry about?

(snappergui:3181): Gtk-WARNING **: 18:39:45.258: Theme parsing error: gtk.css:68:35: The style property GtkButton:child-displacement-x is deprecated and shouldn't be used anymore. It will be removed in a future version

(snappergui:3181): Gtk-WARNING **: 18:39:45.258: Theme parsing error: gtk.css:69:35: The style property GtkButton:child-displacement-y is deprecated and shouldn't be used anymore. It will be removed in a future version

(snappergui:3181): Gtk-WARNING **: 18:39:45.258: Theme parsing error: gtk.css:73:46: The style property GtkScrolledWindow:scrollbars-within-bevel is deprecated and shouldn't be used anymore. It will be removed in a future version
^[[B^[[B^[[B^[[B^[[B^[[B

**GreyGeek** · Jun 11, 2018, 06:02 PM

Do worry about it. It is a gui control that is going to be changed in a "future version". As long as it works now you are alright.

BTW, I hope you realize that snapper's snapshots are within the @ and @home volumes, usually at /.snapshots/1/... and /home/name/.snapshots/1/.... That means that if either subvolume doesn't open for some reason you can't access the snapshots in order to roll back to them.

When you mount your working drive to /mnt, for example, you make /mnt the <ROOT_FS>, which contains @ and @home.
When you add a snapshots directory to <ROOT_FS> and store snapshots in them the only thing you need to mount to access them is <ROOT_FS>, which you access by mounting /dev/disk/by-uuid/xxxxxxxxxxxxxxxxx (or /dev/sda1) to /mnt. You can even do this from a LiveUSB that has btrfs installed. So, even if @ or @home won't open you can fetch @YYYYMMDD & @homeYYYYMMDD snapshots from /mnt/snapshots and make them @ and @home, respectively, thus allowing you to boot up your system again.

BTW, the latest Ubuntu binaries for all relevant releases are here:
https://software.opensuse.org/downlo...r#directUbuntu

**jlittle** · Jun 11, 2018, 06:32 PM

Gtk-WARNING **:...

These warnings and errors are common these days running GTK apps in KDE. "Normally" end users don't see them when they are run from the K menu or other GUI launchers; they might be sent off to a log like .xsession-errors but that's hit or miss. If some error is serious an error dialogue might be opened, maybe. Some of them are GTK 2 bugs that will never be fixed. Some of them are desktop theming "interpretation" differences.

They're a nuisance if, like I do often, one runs GUI programmes from a shell, and there are some errors I want to see. I resort to aliases like these:

Code:

 
alias    mw='mysql-workbench --query mine 2> >(grep -vE "Gtk|^\$|GLib-GO|without letting") &'
alias      v='gvim -geometry 80x60 2>>~/.vimerrors'

(I expect that somebody sometime is going to hit your post in a search on the warning, and my reply is thinking of that somebody; I was the somebody in the past.)

**GreyGeek** · Jun 11, 2018, 08:19 PM

Just to make things clear about why I decided not to use snapper, I refer to the following document:
https://bbs.archlinux.org/viewtopic.php?id=194491

Objective: Use btrfs to create periodic snapshots of the system that make it easy to recover individual files, or the entire system should you accidentally screw everything up.

The quick answer: Anyone who has done any research into this knows that snapper is a tool that allows easy setup of a system that does periodic snapshots of any btrfs subvolume you want.

The problem: Snapper seems like a great tool for doing automated daily/weekly/monthly/yearly snapshots. I say seems like, because it sounds good in theory... The problem is that snapper appears to mainly be used to recover files from snapshots - not recover your entire system using snapshots. Snapper actually does have this feature - it’s called snapper rollback, but instead of replacing the running system, it leaves it in place (even though it’s presumably screwed up) and ignores it, using one of it’s subfolders to boot instead.

The article goes on to show you how to over come this problem.
Mount your system device:
mount /dev/sda1 /mnt (using dev names for brevity but not recommended)
On *Ubuntus a directory list will show
/mnt/@
/mnt/@home

Then create subvolumes called @rootsnapshots and @homesnapshots
btrfs subvolume create /mnt/@rootsnapshots
btrfs subvolume create /mnt/@homesnapshots

This is similar to what I do except I merely create a subdirectory (not subvolume) called /mnt/snapshots because I don't want it mounted into the running system where it can be accessed and it or its contents be damaged. And, I save both @ and @home snapshots in it. Under some circumstances, rolling back a snapper snapshot doesn't remove everything that was added after the pre snapshot. Add a user, for example, and then roll back the addition and you will still have to delete that user's home account.

Snapper config setup creates a subvolume under "/" as /.snapshots and under /home as /home/.snapshots
snapper -c root create-config /
snapper -c home create-config /home That's the problem.

You delete those using "btrfs subvolume delete ..." and replace them with regular subdirectories:
mkdir /home/.snapshots
mkdir /.snapshots

Then, make entries in /etc/fstab c which binds /.snapshot to subvol=@rootsnapshots and /home/.snapshots to subvol=@homesnapshots created under /mnt, i,e, at level ID5.

Then snapper will save its snapshots at the <ROOT_FS> (ID5) level, which can be accessed outside of @ or @home.

Doing all that is a pain, from my POV. Especially since creating snapshots manually is so easy.

And, if I inadvertently delete a file or directory from my system I can run mc (and maybe Dolphin later) as root on /mnt/snapshots/@YYYYMMDD or /mnt/@homeYYYYMMDD and copy the file back to its former location and make sure it is rw. When I roll back using my snapshots I know that EVERYTHING is reversed to the condition of the snapshot.

Want a list of my snapshots?

Code:

$ [B]sudo btrfs subvolume list -ap /[/B]
ID 397 gen 38125 parent 5 top level 5 path <FS_TREE>/snapshots/@_20180525
ID 398 gen 38127 parent 5 top level 5 path <FS_TREE>/snapshots/@home_20180525
ID 401 gen 61016 parent 5 top level 5 path <FS_TREE>/@
ID 402 gen 61016 parent 5 top level 5 path <FS_TREE>/@home
ID 409 gen 43208 parent 5 top level 5 path <FS_TREE>/snapshots/@_20180530
ID 410 gen 43209 parent 5 top level 5 path <FS_TREE>/snapshots/@home_20180530
ID 412 gen 45374 parent 5 top level 5 path <FS_TREE>/snapshots/@_20180531
ID 413 gen 45374 parent 5 top level 5 path <FS_TREE>/snapshots/@home_20180531
ID 416 gen 51670 parent 5 top level 5 path <FS_TREE>/snapshots/@_20180604
ID 417 gen 51672 parent 5 top level 5 path <FS_TREE>/snapshots/@home_20180604

IF I wanted to I could attach a description to the ending when I create them, but what I usually do if I need to do that is create a special name for them that isn't dated. Those snapshots are only temporary for my uses.

Announcement

installing snapper-gui

installing snapper-gui

Comment

Comment

Comment

Comment

Comment

Comment