That is convenient and can help with redistribution by fetching directly from github archives.

The snapper cli should report actions, e.g. when a snapshot is created, esp. for the rollback command. The output should be suppressed if the already existing --quiet parameter is provided.

Following commit in btrfs-progs requires a change in snapper/Btrfs.cc:
http://git.kernel.org/cgit/linux/kernel/git/mason/btrfs-progs.git/commit/?id=46de1a6ec3dbb0db203baa6c46cb64ba9b000ea2

The error is

Btrfs.cc: In member function 'bool snapper::StreamProcessor::dumper(int)':
Btrfs.cc:1066:70: error: too few arguments to function 'int btrfs_read_and_process_send_stream(int, btrfs_send_ops*, void*, int)'
      int r = btrfs_read_and_process_send_stream(fd, &send_ops, &*this);
                                                                      ^
In file included from Btrfs.cc:36:0:
/usr/include/btrfs/send-stream.h:59:5: note: declared here
 int btrfs_read_and_process_send_stream(int fd,
     ^

This seems to work:

diff --git a/snapper/Btrfs.cc b/snapper/Btrfs.cc
index 49cd0ba..9e11f71 100644
--- a/snapper/Btrfs.cc
+++ b/snapper/Btrfs.cc
@@ -1063,7 +1063,7 @@ namespace snapper
        {
            boost::this_thread::interruption_point();

-           int r = btrfs_read_and_process_send_stream(fd, &send_ops, &*this);
+           int r = btrfs_read_and_process_send_stream(fd, &send_ops, &*this, 0);

            if (r < 0)
            {

Hi, i am getting an error every time i call a method from the dbus interface in python

ERROR:dbus.proxies:Introspect error on :1.127:/org/opensuse/Snapper: dbus.exceptions.IntrospectionParserException: Error parsing introspect data: <class 'xml.parsers.expat.ExpatError'>: not well-formed (invalid token): line 90, column 33

Even from the examples i get the same error.

I'm building from master at 0b20a20 and using python3.
Also were can i find documentation about the dbus interface? A small description of the methods and signals would be nice specially the CreateSingleSnapshotV2 and CreateSingleSnapshotOfDefault

Thanks.

Allow to specify the diff command used by snapper, like external diff in svn or git.

Please correct me if I'm wrong, but there appears to be no end user option for specifying the location of the .snaphots directory.

I would like to be able to pick an alternate location for integration with the mkinitcpio-btrfs package on Arch linux. https://github.com/xtfxme/mkinitcpio-btrfs

Can this feature please be added if it's not too much of a headache to program?

Seeing that snapper includes cron files for cleanup tasks, and that systemd is currently used in most distributions, I think it would be a nice idea to include systemd timer files, instead of the cron scripts, if the user has systemd installed.
Oh, and I noticed that the cron scripts also have hardcoded paths, but I don't suppose autotools can dynamically change such script files, right?

In frontpage of http://snapper.io/ site I see the screenshot: http://snapper.io/images/snapper_yast2_diff.png
But after installing snapper package I didn't see how to run this GUI interface of snapper. I use Ubuntu linux. Is there any command-line option of additional software needed for run snapper GUI? Can you describe this in documentation?

On debian 6:

aptitude install snapper
[...]
root@testes:/etc/snapper/configs# snapper list-configs
Falha (org.freedesktop.DBus.Error.ServiceUnknown).

It seems that the python binding are not build in the current master branch. How can this be enabled?

At now there are snapper repository only for too old Ubuntu versions:
http://software.opensuse.org/download/package?project=filesystems:snapper&package=snapper
here is repository only for older versions
xUbuntu 13.02
xUbuntu 13.04

This versions is too old, and many Ubuntu users must use old version 0.1.8 of snapper from distibutive: http://packages.ubuntu.com/search?keywords=snapper&searchon=names&suite=all&section=all

Please create repository with fresh snapper versions (0.2.4 and newer) for new Ubuntu versions 14.04 LTS and 14.10

And maybe will be easier to do this via PPA using launchpad.net https://help.launchpad.net/Packaging/PPA ?

It would be nice if ZFS filesystems running through FUSE or ZFSOnLinux were supported, in addition to BTRFS and LVM.

I would like to suggest a feature where Snapper avoids creating snapshots on disks
which are on standby, preventing the disks to spin up.

I have performance issues with btrfs. I use snapper to version control my system. There are about 40-50 snapshots for root and home subvolumes.

In the morning I open laptop lid. Within 1 hour snapper removes about 15 outdated snapshots - mostly hourly ones. After that heavy btrfs cleaning occurs that fully loads laptop ssd so other tasks that require IO operations get blocked.

To distribute load over time snapper may support limits for subvolume cleanup per given period. For example cleanup no more than 1 subvolume per 10 minutes.

Currently snapper recycles the snapshot directory name e.g. /xyz/.snapshots/1..n/snapshot and this can be a problematic for some applications like for example SAMBA. E.g. consider the following example where some snapshot directories exposed as shares by SAMBA are deleted and then recreated outside of SAMBA

the following snapshots;

/xyz/.snapshots/1/snapshot
/xyz/.snapshots/2/snapshot
/xyz/.snapshots/3/snapshot

are exposed as SAMBA shares named respectively
'shadowable@{0a0df48e-35d1-48df-8c03-0ba52767be34}',
'shadowable@{0ad619ff-a8f2-4789-823b-f9a70be7bb08}' &
'shadowable@{9893c614-a98e-495f-8040-6eea8af1ac61}'

say an administrator deletes /xyz/.snapshots/3/snapshot via 'snapper delete 3' and creates a new snapshot via 'snapper create' now samba thinks the samba share named 'shadowable@{9893c614-a98e-495f-8040-6eea8af1ac61}' still exists (as the associated /xyz/.snapshots/3/snapshot directory exists but isn't actually the same snapshot)

Possible solutions:
a) A new api that allows a uuid to be retrieved for a particular snapshot. (such a uuid could be obtained from the underlying filesystem if it already provides such and/or snapper could generate it's own)
b) snapper could implement a different naming scheme that doesn't resuse the id and provides a unique name instead.

Very often users want to know, how much size use each snapshot, for understand which snapshots eats most of space. At now I can't find human-understandable report that show this information.

On ZFS there are command:

# zfs list -t snapshot

that shows total snapshot size and used size in easy and human-readable way:

zfs-disks/home@zfs-auto-snap_monthly-2014-01-23-0800   1,44G      -  21,9G  -
zfs-disks/home@zfs-auto-snap_daily-2014-02-04-0915     17,3M      -  21,7G  -
zfs-disks/home@zfs-auto-snap_weekly-2014-02-04-0916    12,8M      -  21,7G  -
zfs-disks/home@zfs-auto-snap_daily-2014-02-05-1010      304M      -  21,9G  -
zfs-disks/home@zfs-auto-snap_daily-2014-02-06-0914      466M      -  21,9G  -
zfs-disks/home@zfs-auto-snap_daily-2014-02-10-0934      199M      -  21,3G  -

Will be good to have utility like this on btrfs snapper package.

Which other package need ?

  CXXLD  CmpDirs
/usr/bin/ld: CmpDirs.o: undefined reference to symbol '_ZN5boost6system15system_categoryEv'
/usr/bin/ld: note: '_ZN5boost6system15system_categoryEv' is defined in DSO /usr/lib/libboost_system.so.1.50.0 so try adding it to the linker command line
/usr/lib/libboost_system.so.1.50.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status

Actually there is no documentation or hint in how contribute translation and translation fixes (or fix "miswrittings") in a easy way.

A hint on how or what to do to help the project to get translated.

Maybe in the README something like "If you want contribute you can fork and send request the fixes or translations updates" (really generic text example, I know).

What are the plans on supporting the Ceph RBD and CephFS snapshots?
https://ceph.com/docs/master/rbd/rbd-snapshot/

Snapper marks files with unreadable xattributes as different.
A call to "snapper status 39..40" lists a lot of xattribute changes:

Ragnarok-Micro ~ # snapper status 39..40
....x /dev/core
....x /dev/hda
....x /dev/hda1
....x /dev/hda10
....x /dev/hda11
....x /dev/hda12
....x /dev/hda13
....x /dev/hda14
....x /dev/hda15
...

The log contains:

2013-05-29 14:28:44 MIL libsnapper(30497) Compare.cc(cmpDirs):442 - path1://.snapshots/39/snapshot path2://.snapshots/40/snapshot
2013-05-29 14:28:44 MIL libsnapper(30497) Compare.cc(cmpDirs):465 - dev1:82 dev2:83
2013-05-29 14:28:45 ERR libsnapper(30497) XAttributes.cc(XAttributes):119 - Couldn't get xattributes names-list size. link: //.snapshots/39/snapshot/dev/core, error: No such device or address
2013-05-29 14:28:45 ERR libsnapper(30497) Compare.cc(cmpFilesXattrs):486 - extended attributes compare failed
2013-05-29 14:28:45 ERR libsnapper(30497) XAttributes.cc(XAttributes):119 - Couldn't get xattributes names-list size. link: //.snapshots/39/snapshot/dev/hda, error: No such device or address
2013-05-29 14:28:45 ERR libsnapper(30497) Compare.cc(cmpFilesXattrs):486 - extended attributes compare failed
...

A xadiff shows nothing:

Ragnarok-Micro ~ # snapper xadiff 39..40
Ragnarok-Micro ~ # 

This change should fix it:

diff --git a/snapper/Compare.cc b/snapper/Compare.cc
index 29c66b7..edb2fbb 100644
--- a/snapper/Compare.cc
+++ b/snapper/Compare.cc
@@ -484,7 +484,7 @@ namespace snapper
        catch (const XAttributesException& e)
         {
             y2err("extended attributes compare failed");
-           return false;
+           return true;
        }
     }

DNF is coming to F22 as default package manager.

I think would be great to integrate snapper with dnf. I can help with writing this, but I don't know how snapper works and don't have time to investigating.

Would it be very hard to match up the output of btrfs qgroup show / and the list of snapshots in the output of snapper list (in particular the exclusive disk space used)? I think that'd be a great help trying to understand which snapshot to remove when you want to free up disk space.

Can you create a dbus signal for when snapper ends comparing two snapshots so we can know when to GetFiles?
Using the dbus interface in python i frequently get an exception saying org.freedesktop.DBus.Error.NoReply.

thanks in advance
Ricardo Vieira

OpenSUSE 13.2 includes a GRUB menu entry that allows the user to select a snapshot and boot into it (read only). This is a fantastic system recovery tool. I'd like to set this up on Ubuntu / Linux Mint.

Can you please include instructions in a blog post and/or the snapper documentation?

configure.in name is deprecated an will probably become fatal in automake-1.14

http://www.flameeyes.eu/autotools-mythbuster/forwardporting/automake.html

Snapshots is good, but when free space is going down, users don't have easy ways to free-up space.
They can delete some files, but free space will not increased, and they will be very confused, because they don't know anything about snapshots and how to cleanup them, which snapshot must be deleted for free-up space.

For solve this problem will be good add cron job that checks current free space, and when free space is less than custom limit, do remove older snapshots.

The best way will be detect lacking free space in realtime and report to user ways for free-up space, but I don't know how to do this, so at first cron check will be good.

What do you think about described problem and my solution?

Maybe you have other ideas how we can solve this problem better?

Allow to reload configs. Maybe even do so automatically.

Title says it all. After running, snapper create, I get an IO error message. Then systemd begins throwing a bunch of errors about not being able ro journal because the filesystem is read only. I've had to temporarily uninstall snapper because of this

Today I upgraded from 0.1.8 to 0.2.6 version of snapper and want to see what's new are added to snapper, but can't find this on site http://snapper.io/news.html or other pages. Is there any changelog with list of changes in each release available?

The snapper cli should prompt the user for some actions before doing the actual task, e.g. undochange, rollback and delete-config.

Also add an option to avoid the prompt when called from scripts.

Hi Arvin,

the bug is easy to reproduce. No empty pre-post couple can be removed by the cleanup algorithm.

Its's caused be the fact that reference is being held from Comparison object in server. In client we call do_cleanup_empty_pre_post() in cleanup.cc:

• first, we create comparison (command_create_xcomparison())
• second, with same dbus connection still open, we call command_delete_xsnapshots()

in server:

• Comparison object is still valid and it holds the reference to MetaSnapper object during the call of delete_snapshots method. So delete_snapshots fails on check_config_in_use() with ConfigInUse exception

I think it could be fixed by adding call for delete_comparison after we verify the comparison of pre-post couple is empty in client. The method is already in introspect method. What do you think?

Example: cleanup.cc, line 352:

if (it2 != snapshots.end())
        {
        command_create_xcomparison(conn, config_name, it1->getNum(), it2->getNum());

        list<XFile> files = command_get_xfiles(conn, config_name, it1->getNum(), it2->getNum());

        if (files.empty())
        {
            tmp.push_back(it1);
            tmp.push_back(it2);
        }
--->>> add delete_comparison <<<---
        }

I'm seeing failure messages in /var/log/snapper.log everytime I create a pre/post snapshot. Just curious as to why it's failing everytime?

# snapper create --command "sleep 2 && echo hi && sleep 3

The following error messages are reported in the snapper.log:

1. open failed path://---
2. send ioctl failed errno:2 (No such file or directory)

After executing the command, I am able to traverse the .snapshot directries (e.g: .snapshots/14/snapshot), so I don't know why it's throwing an error in the log.

2014-01-08 00:35:17 MIL libsnapper(1678) snapperd.cc(main):270 - Requesting DBus name
2014-01-08 00:35:17 MIL libsnapper(1678) snapperd.cc(main):274 - Loading snapper configs
2014-01-08 00:35:17 MIL libsnapper(1678) Snapper.cc(getConfigs):251 - Snapper get-configs
2014-01-08 00:35:17 MIL libsnapper(1678) Snapper.cc(getConfigs):252 - libsnapper version 0.1.8
2014-01-08 00:35:17 MIL libsnapper(1678) AsciiFile.cc(reload):114 - loading file /etc/conf.d/snapper
2014-01-08 00:35:17 MIL libsnapper(1678) AsciiFile.cc(getValue):228 - key:SNAPPER_CONFIGS value:root home
2014-01-08 00:35:17 MIL libsnapper(1678) AsciiFile.cc(reload):114 - loading file /etc/snapper/configs/root
2014-01-08 00:35:17 MIL libsnapper(1678) AsciiFile.cc(getValue):228 - key:SUBVOLUME value:/
2014-01-08 00:35:17 MIL libsnapper(1678) AsciiFile.cc(reload):114 - loading file /etc/snapper/configs/home
2014-01-08 00:35:17 MIL libsnapper(1678) AsciiFile.cc(getValue):228 - key:SUBVOLUME value:/home
2014-01-08 00:35:17 MIL libsnapper(1678) AsciiFile.cc(getValue):228 - key:ALLOW_USERS value:
2014-01-08 00:35:17 MIL libsnapper(1678) AsciiFile.cc(getValue):228 - key:ALLOW_GROUPS value:
2014-01-08 00:35:17 MIL libsnapper(1678) AsciiFile.cc(getValue):228 - key:ALLOW_USERS value:
2014-01-08 00:35:17 MIL libsnapper(1678) AsciiFile.cc(getValue):228 - key:ALLOW_GROUPS value:
2014-01-08 00:35:17 MIL libsnapper(1678) snapperd.cc(main):278 - Listening for method calls and signals
2014-01-08 00:35:17 MIL libsnapper(1678) Snapper.cc(Snapper):78 - Snapper constructor
2014-01-08 00:35:17 MIL libsnapper(1678) Snapper.cc(Snapper):79 - libsnapper version 0.1.8
2014-01-08 00:35:17 MIL libsnapper(1678) Snapper.cc(Snapper):80 - config_name:root disable_filters:false
2014-01-08 00:35:17 MIL libsnapper(1678) AsciiFile.cc(reload):114 - loading file /etc/snapper/configs/root
2014-01-08 00:35:17 MIL libsnapper(1678) AsciiFile.cc(getValue):228 - key:SUBVOLUME value:/
2014-01-08 00:35:17 MIL libsnapper(1678) AsciiFile.cc(getValue):228 - key:FSTYPE value:btrfs
2014-01-08 00:35:17 MIL libsnapper(1678) Snapper.cc(Snapper):96 - subvolume:/ filesystem:btrfs
2014-01-08 00:35:17 MIL libsnapper(1678) Snapper.cc(loadIgnorePatterns):147 - number of ignore patterns:8
2014-01-08 00:35:17 MIL libsnapper(1678) Snapshot.cc(read):258 - found 13 snapshots
2014-01-08 00:35:17 ERR libsnapper(1678) FileUtils.cc(SDir):84 - open failed path://.snapshots/13 (No such file or directory)
2014-01-08 00:35:22 ERR libsnapper(1678) FileUtils.cc(SDir):84 - open failed path://.snapshots/14 (No such file or directory)
2014-01-08 00:35:22 MIL libsnapper(1678) AsciiFile.cc(getValue):228 - key:BACKGROUND_COMPARISON value:yes
2014-01-08 00:35:22 MIL libsnapper(1678) Comparison.cc(Comparison):54 - num1:13 num2:14
2014-01-08 00:35:22 MIL libsnapper(1678) Comparison.cc(load):147 - num1:13 num2:14
2014-01-08 00:35:22 MIL libsnapper(1678) Comparison.cc(create):118 - num1:13 num2:14
2014-01-08 00:35:22 MIL libsnapper(1678) Btrfs.cc(cmpDirs):1125 - special btrfs cmpDirs
2014-01-08 00:35:22 MIL libsnapper(1678) Btrfs.cc(process):1096 - dir1:'//.snapshots/13/snapshot' dir2:'//.snapshots/14/snapshot'
2014-01-08 00:35:22 ERR libsnapper(1678) Btrfs.cc(do_send):1041 - send ioctl failed errno:2 (No such file or directory)
2014-01-08 00:35:22 ERR libsnapper(1678) Btrfs.cc(cmpDirs):1139 - special btrfs cmpDirs failed, Btrfs send/receive error
2014-01-08 00:35:22 MIL libsnapper(1678) Btrfs.cc(cmpDirs):1140 - cmpDirs fallback
2014-01-08 00:35:22 MIL libsnapper(1678) Compare.cc(cmpDirs):439 - path1://.snapshots/13/snapshot path2://.snapshots/14/snapshot
2014-01-08 00:35:22 MIL libsnapper(1678) Compare.cc(cmpDirs):462 - dev1:59 dev2:60
2014-01-08 00:35:25 MIL libsnapper(1678) Compare.cc(cmpDirs):466 - stopwatch 2.826882s for comparing directories
2014-01-08 00:35:25 MIL libsnapper(1678) Comparison.cc(create):140 - found 2 lines
2014-01-08 00:35:25 MIL libsnapper(1678) Comparison.cc(save):205 - num1:13 num2:14
2014-01-08 00:35:56 MIL libsnapper(1678) Snapper.cc(~Snapper):107 - Snapper destructor
2014-01-08 00:36:22 MIL libsnapper(1678) snapperd.cc(main):282 - Exiting

[root@Vaio-Saad ~]# snapper --version snapper 0.1.8

[root@Vaio-Saad ~]# btrfs subvolume list /
ID 257 gen 769 top level 5 path root
ID 258 gen 769 top level 5 path home
ID 259 gen 716 top level 5 path pacpkg
ID 300 gen 765 top level 257 path .snapshots
ID 301 gen 733 top level 5 path home/.snapshots
ID 302 gen 768 top level 257 path .snapshots/1/snapshot
ID 303 gen 768 top level 257 path .snapshots/2/snapshot
ID 304 gen 768 top level 257 path .snapshots/3/snapshot
ID 305 gen 768 top level 257 path .snapshots/4/snapshot
ID 306 gen 731 top level 5 path home/.snapshots/1/snapshot
ID 307 gen 732 top level 5 path home/.snapshots/2/snapshot
ID 308 gen 768 top level 257 path .snapshots/5/snapshot
ID 309 gen 768 top level 257 path .snapshots/6/snapshot
ID 310 gen 768 top level 257 path .snapshots/7/snapshot
ID 311 gen 768 top level 257 path .snapshots/8/snapshot
ID 312 gen 768 top level 257 path .snapshots/9/snapshot
ID 313 gen 768 top level 257 path .snapshots/10/snapshot
ID 314 gen 768 top level 257 path .snapshots/11/snapshot
ID 315 gen 768 top level 257 path .snapshots/12/snapshot
ID 316 gen 768 top level 257 path .snapshots/13/snapshot
ID 317 gen 768 top level 257 path .snapshots/14/snapshot

[root@Vaio-Saad ~]# cat /proc/cmdline 
initrd=\EFI\arch\initramfs-arch.img root=/dev/sda2 rootfstype=btrfs rootflags=subvol=root rw elevator=noop

fstab:
LABEL=Arch_Linux        /               btrfs           rw,noatime,compress=lzo,ssd,space_cache,inode_cache,autodefrag  0 0

Snapshots very often used for backup home folders. But each home folder contains .cache folder with files that changes very often, and they eats free space for each snapshots.

Also many users use "temp" folder in home, that contains garbage files, that don't need backups too.

For solve those problems will be good to have ability to exclude specific files and folders from snapshots.

As I understand, btrfs snapshots (and other snapshots realisation) don't have build-in function for excluding something, they creates only full snapshots.

But btrfs support Writable snapshots, so we can create snapshot and after this remove (or maybe re-link to last version?) unnecessary files from it via script.

So this way will solve problem with wasting free space for unnecessary files in snapshots. What do you think about this idea?

I have deleted many snapshots yesterday from non-root btrfs volume using Yast. One was left with number 1772. There are new snapshots created starting with 1,2,3, numbers it looks like snapper lost track about that one snapshot. It is not listed in snapshots anymore and could not be deleted. The directory in .snapshots cannot be deleted too.

Is there any way I can get rid of this snapshot? Using kernel 3.10.4

Here is part of the log file when it happened:

2013-08-24 00:27:27 MIL libsnapper(5146) snapperd.cc(main):270 - Requesting DBus name
2013-08-24 00:27:27 MIL libsnapper(5146) snapperd.cc(main):274 - Loading snapper configs
2013-08-24 00:27:27 MIL libsnapper(5146) Snapper.cc(getConfigs):202 - Snapper get-configs
2013-08-24 00:27:27 MIL libsnapper(5146) Snapper.cc(getConfigs):203 - libsnapper version 0.1.2
2013-08-24 00:27:27 MIL libsnapper(5146) AsciiFile.cc(reload):114 - loading file /etc/sysconfig/snapper
2013-08-24 00:27:27 MIL libsnapper(5146) AsciiFile.cc(getValue):208 - key:SNAPPER_CONFIGS value:root
2013-08-24 00:27:27 MIL libsnapper(5146) AsciiFile.cc(reload):114 - loading file /etc/snapper/configs/root
2013-08-24 00:27:27 MIL libsnapper(5146) AsciiFile.cc(getValue):208 - key:SUBVOLUME value:/home1
2013-08-24 00:27:27 MIL libsnapper(5146) snapperd.cc(main):278 - Listening for method calls and signals
2013-08-24 00:27:27 MIL libsnapper(5146) Snapper.cc(Snapper):54 - Snapper constructor
2013-08-24 00:27:27 MIL libsnapper(5146) Snapper.cc(Snapper):55 - libsnapper version 0.1.2
2013-08-24 00:27:27 MIL libsnapper(5146) Snapper.cc(Snapper):56 - config_name:root disable_filters:false
2013-08-24 00:27:27 MIL libsnapper(5146) AsciiFile.cc(reload):114 - loading file /etc/snapper/configs/root
2013-08-24 00:27:27 MIL libsnapper(5146) AsciiFile.cc(getValue):208 - key:SUBVOLUME value:/home1
2013-08-24 00:27:27 MIL libsnapper(5146) AsciiFile.cc(getValue):208 - key:FSTYPE value:btrfs
2013-08-24 00:27:27 MIL libsnapper(5146) Snapper.cc(Snapper):74 - subvolume:/home1 filesystem:btrfs
2013-08-24 00:27:27 MIL libsnapper(5146) Snapper.cc(loadIgnorePatterns):124 - number of ignore patterns:8
2013-08-24 00:27:27 ERR libsnapper(5146) Snapshot.cc(read):251 - loading 1772 failed
2013-08-24 00:27:27 MIL libsnapper(5146) Snapshot.cc(read):257 - found 4 snapshots
2013-08-24 00:27:27 ERR libsnapper(5146) FileUtils.cc(SDir):75 - open failed path:/home1/.snapshots/3416 (No such file or directory)
2013-08-24 00:27:58 MIL libsnapper(5146) Snapper.cc(~Snapper):85 - Snapper destructor
2013-08-24 00:28:04 MIL libsnapper(5146) Snapper.cc(Snapper):54 - Snapper constructor
2013-08-24 00:28:04 MIL libsnapper(5146) Snapper.cc(Snapper):55 - libsnapper version 0.1.2
2013-08-24 00:28:04 MIL libsnapper(5146) Snapper.cc(Snapper):56 - config_name:root disable_filters:false
2013-08-24 00:28:04 MIL libsnapper(5146) AsciiFile.cc(reload):114 - loading file /etc/snapper/configs/root
2013-08-24 00:28:04 MIL libsnapper(5146) AsciiFile.cc(getValue):208 - key:SUBVOLUME value:/home1
2013-08-24 00:28:04 MIL libsnapper(5146) AsciiFile.cc(getValue):208 - key:FSTYPE value:btrfs
2013-08-24 00:28:04 MIL libsnapper(5146) Snapper.cc(Snapper):74 - subvolume:/home1 filesystem:btrfs
2013-08-24 00:28:04 MIL libsnapper(5146) Snapper.cc(loadIgnorePatterns):124 - number of ignore patterns:8
2013-08-24 00:28:04 ERR libsnapper(5146) Snapshot.cc(read):251 - loading 1772 failed
2013-08-24 00:28:04 MIL libsnapper(5146) Snapshot.cc(read):257 - found 1 snapshots
2013-08-24 00:28:35 MIL libsnapper(5146) Snapper.cc(~Snapper):85 - Snapper destructor
2013-08-24 00:29:04 MIL libsnapper(5146) snapperd.cc(main):282 - Exiting
2013-08-24 01:15:06 MIL libsnapper(8342) snapperd.cc(main):270 - Requesting DBus name
2013-08-24 01:15:06 MIL libsnapper(8342) snapperd.cc(main):274 - Loading snapper configs
2013-08-24 01:15:06 MIL libsnapper(8342) Snapper.cc(getConfigs):202 - Snapper get-configs
2013-08-24 01:15:06 MIL libsnapper(8342) Snapper.cc(getConfigs):203 - libsnapper version 0.1.2
2013-08-24 01:15:06 MIL libsnapper(8342) AsciiFile.cc(reload):114 - loading file /etc/sysconfig/snapper
2013-08-24 01:15:06 MIL libsnapper(8342) AsciiFile.cc(getValue):208 - key:SNAPPER_CONFIGS value:root
2013-08-24 01:15:06 MIL libsnapper(8342) AsciiFile.cc(reload):114 - loading file /etc/snapper/configs/root
2013-08-24 01:15:06 MIL libsnapper(8342) AsciiFile.cc(getValue):208 - key:SUBVOLUME value:/home1
2013-08-24 01:15:06 MIL libsnapper(8342) snapperd.cc(main):278 - Listening for method calls and signals
2013-08-24 01:15:06 MIL libsnapper(8342) Snapper.cc(Snapper):54 - Snapper constructor
2013-08-24 01:15:06 MIL libsnapper(8342) Snapper.cc(Snapper):55 - libsnapper version 0.1.2
2013-08-24 01:15:06 MIL libsnapper(8342) Snapper.cc(Snapper):56 - config_name:root disable_filters:false
2013-08-24 01:15:06 MIL libsnapper(8342) AsciiFile.cc(reload):114 - loading file /etc/snapper/configs/root
2013-08-24 01:15:06 MIL libsnapper(8342) AsciiFile.cc(getValue):208 - key:SUBVOLUME value:/home1
2013-08-24 01:15:06 MIL libsnapper(8342) AsciiFile.cc(getValue):208 - key:FSTYPE value:btrfs
2013-08-24 01:15:06 MIL libsnapper(8342) Snapper.cc(Snapper):74 - subvolume:/home1 filesystem:btrfs
2013-08-24 01:15:06 MIL libsnapper(8342) Snapper.cc(loadIgnorePatterns):124 - number of ignore patterns:8
2013-08-24 01:15:06 ERR libsnapper(8342) Snapshot.cc(read):251 - loading 1772 failed
2013-08-24 01:15:06 MIL libsnapper(8342) Snapshot.cc(read):257 - found 1 snapshots
2013-08-24 01:15:06 ERR libsnapper(8342) FileUtils.cc(SDir):75 - open failed path:/home1/.snapshots/1 (No such file or directory)
2013-08-24 01:15:37 MIL libsnapper(8342) Snapper.cc(~Snapper):85 - Snapper destructor
2013-08-24 01:16:09 MIL libsnapper(8342) snapperd.cc(main):282 - Exiting
2013-08-24 01:47:15 MIL libsnapper(9087) snapperd.cc(main):270 - Requesting DBus name
2013-08-24 01:47:15 MIL libsnapper(9087) snapperd.cc(main):274 - Loading snapper configs
2013-08-24 01:47:15 MIL libsnapper(9087) Snapper.cc(getConfigs):202 - Snapper get-configs
2013-08-24 01:47:15 MIL libsnapper(9087) Snapper.cc(getConfigs):203 - libsnapper version 0.1.2
2013-08-24 01:47:15 MIL libsnapper(9087) AsciiFile.cc(reload):114 - loading file /etc/sysconfig/snapper
2013-08-24 01:47:15 MIL libsnapper(9087) AsciiFile.cc(getValue):208 - key:SNAPPER_CONFIGS value:root
2013-08-24 01:47:15 MIL libsnapper(9087) AsciiFile.cc(reload):114 - loading file /etc/snapper/configs/root
2013-08-24 01:47:15 MIL libsnapper(9087) AsciiFile.cc(getValue):208 - key:SUBVOLUME value:/home1
2013-08-24 01:47:15 MIL libsnapper(9087) snapperd.cc(main):278 - Listening for method calls and signals
2013-08-24 01:47:15 MIL libsnapper(9087) Snapper.cc(Snapper):54 - Snapper constructor
2013-08-24 01:47:15 MIL libsnapper(9087) Snapper.cc(Snapper):55 - libsnapper version 0.1.2
2013-08-24 01:47:15 MIL libsnapper(9087) Snapper.cc(Snapper):56 - config_name:root disable_filters:false
2013-08-24 01:47:15 MIL libsnapper(9087) AsciiFile.cc(reload):114 - loading file /etc/snapper/configs/root
2013-08-24 01:47:15 MIL libsnapper(9087) AsciiFile.cc(getValue):208 - key:SUBVOLUME value:/home1
2013-08-24 01:47:15 MIL libsnapper(9087) AsciiFile.cc(getValue):208 - key:FSTYPE value:btrfs
2013-08-24 01:47:15 MIL libsnapper(9087) Snapper.cc(Snapper):74 - subvolume:/home1 filesystem:btrfs
2013-08-24 01:47:15 MIL libsnapper(9087) Snapper.cc(loadIgnorePatterns):124 - number of ignore patterns:8
2013-08-24 01:47:15 ERR libsnapper(9087) Snapshot.cc(read):251 - loading 1772 failed
2013-08-24 01:47:16 MIL libsnapper(9087) Snapshot.cc(read):257 - found 2 snapshots
2013-08-24 01:47:16 ERR libsnapper(9087) FileUtils.cc(SDir):75 - open failed path:/home1/.snapshots/2 (No such file or directory)
2013-08-24 01:47:47 MIL libsnapper(9087) Snapper.cc(~Snapper):85 - Snapper destructor
2013-08-24 01:47:55 MIL libsnapper(9087) Snapper.cc(Snapper):54 - Snapper constructor
2013-08-24 01:47:55 MIL libsnapper(9087) Snapper.cc(Snapper):55 - libsnapper version 0.1.2
2013-08-24 01:47:55 MIL libsnapper(9087) Snapper.cc(Snapper):56 - config_name:root disable_filters:false
2013-08-24 01:47:55 MIL libsnapper(9087) AsciiFile.cc(reload):114 - loading file /etc/snapper/configs/root
2013-08-24 01:47:55 MIL libsnapper(9087) AsciiFile.cc(getValue):208 - key:SUBVOLUME value:/home1

Hi,

I'm trying to build snapper on Ubuntu 14.04 x64 & I'm getting the following errors:

In file included from Btrfs.cc:34:0:
/usr/include/libmount/libmount.h:345:28: error: expected ',' or '...' before 'new'
struct libmnt_table *new);
^
Btrfs.cc: In constructor 'snapper::MntTable::MntTable()':
Btrfs.cc:1386:40: error: 'mnt_table_enable_comments' was not declared in this scope
mnt_table_enable_comments(table, 1);
^
Btrfs.cc: In member function 'void snapper::MntTable::replace_file()':
Btrfs.cc:1402:52: error: 'mnt_table_replace_file' was not declared in this scope
if (mnt_table_replace_file(table, "/etc/fstab") != 0)
^
What am I missing?

Thanks.

-John

The "ALLOW_GROUP" entry in snapper config file should be able to accept group names with space such as "Domain/Domain Admins" which is possible via Samba.

It would be nice if snapper would support weekly cleanup and minutely snapshot creation.
I think that a weekly snapshot retention could be much more usefull as daily or monthly because the workflow of many enterprises is organized on a weekly basis.
Minutely snapshoting might be useless for most scenarios, but nevertheless there are some applications for this.
It shoudn't be too complicated to implement.

Sincerly,
Roland R.

Build log: http://hydra.nixos.org/build/16420291/nixlog/1/raw

Btrfs.cc: In member function 'bool snapper::StreamProcessor::dumper(int)':
Btrfs.cc:1153:69: error: too few arguments to function 'int btrfs_read_and_process_send_stream(int, btrfs_send_ops_, void_, int, u64)'
r = btrfs_read_and_process_send_stream(fd, &send_ops, &*this, 0);

downstream bug: https://bugs.gentoo.org/show_bug.cgi?id=522656

I for one can't figure it out. Created snapshots seem to be have no parent subvol to increment against. What is the process here?

$ sudo btrfs send -p /.snapshots/630/snapshot /.snapshots/893/snapshot | sudo btrfs receive /mnt/backup
At subvol /.snapshots/630/snapshot
At snapshot snapshot
ERROR: could not find parent subvolume

Just to test out the rollback feature of snapper I took a snapshot and then moved /usr/bin/bash to /usr/bin/bash.bak which of course broke a bunch of things upon reboot. I edited my kernel parameters to boot from the snapshot I just took, logged in as root and ran 'snapper rollback'. Snapper then printed "IO error". Did I do something wrong? I was only saved by the fact that knew exactly what the problem was and could move /use/bin/bash back to where it should have been. If it matters, I'm using snapper on Arch rather than openSUSE.

Hello.
I'm using snapper (0.2.3) on a debian system with btrfs.

Every time snapper is called (except to get version number), 4 lines are created in /var/log/syslog:
org.opensuse.Snapper[1562]: :1: parser error : Document is empty
org.opensuse.Snapper[1562]: ^
org.opensuse.Snapper[1562]: :1: parser error : Start tag expected, '<' not found
org.opensuse.Snapper[1562]: ^

AFAIK, snapper still works properly, but it fills my logs...

I quickly grep-ped in the code but found nothing. I copied zypp-plugin.conf into /etc/snapper but the problem remains.

Thanks

The number of options for the snapper command line tool is increasing so a configuration
file seems reasonable. Option should include: config name, diff command, table style,
utc and iso.

For scripts there should also be an option to not read the configuration file.

I want to use snapper to create a "Time Machine" that can take me arbitrarily far back in time. This works fine provided I don't run out of disk space. In my early trials, I ran out of disk space rapidly because of large, changing files. I reorganized my user directory so that most of these now live in ~/.local/var, which is a symlink to /usr/local/var/$HOME, which is outside my @home volume, but unfortunately, I still find myself filling my (reasonably capacious) disk from time to time with "mistakes", and currently all I can do is erase all my snapshots, and reboot the Time Machine.

If I could use read-write snapshots (as snapper once supported, before btrfs added support for read-only snapshots), then I would be able to fix my mistakes by hand: potentially tedious, but at least I'd have the choice. Deleting a few large files in a number of snapshots is not so bad after all.

The build breaks with

Makefile:540: recipe for target 'BtrfsUtils.lo' failed
make[2]: *** [BtrfsUtils.lo] Error 1

The full build log is provided in a separate gist:
https://gist.github.com/holgersson32644/11188222

If you need more information, please ask :)

Kind regards

Hi! I'm maintaining an ArchLinux package for snapper, and we're already served with boost-1.52 there.

└» /usr/sbin/snapperd -h
usage: snapperd [--options]

    Options:
        --stdout, -s                    Log to stdout.
        --debug, -d                     Turn on debugging.

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::thread_resource_error> >'
  what():  boost thread: thread not joinable: Invalid argument
Abgebrochen (Speicherabzug geschrieben)

Following patch fixes the issue, but to be honest I didn't really know what I'm doing there with boost threads, so not doing a real pull request, just inline

--- server/Client.cc.orig       2013-02-05 19:48:22.584228010 +0100
+++ server/Client.cc    2013-02-05 19:49:59.878490624 +0100
@@ -46,7 +46,10 @@
 Client::~Client()
 {
     thread.interrupt();
-    thread.join();
+    if (thread.joinable())
+    {
+        thread.join();
+    }

     for (list<Comparison*>::iterator it = comparisons.begin(); it != comparisons.end(); ++it)
     {
--- server/Background.cc.orig   2013-02-05 19:57:53.403603576 +0100
+++ server/Background.cc        2013-02-05 19:58:40.808202658 +0100
@@ -42,7 +42,10 @@
 Backgrounds::~Backgrounds()
 {
     thread.interrupt();
-    thread.join();
+    if (thread.joinable())
+    {
+        thread.join();
+    }
 }

Would be nice if you could review and fix it.
Thanks!

Allow users to extend snapper with custom scripts. E.g. scripts should be executed before and after snapshot creation and deletion.

Hi Arvin,

Just bouncing the RFE I got today. side note: I enabled systemd timer files (and services) in Fedora 21+, so it's not literally an upstream issue since AFAIK it's not enabled by default yet. Just for the record.

Here's the original RFE:

In Fedora 20, automated hourly snapshots were created thru the use of a /etc/cron.hourly/snapper script.

This script created snapshots with a Description of "timeline", which is plain useless especially because next field "Cleanup" also displays "timeline", which is far enough to visually identify a timeline entry. No need for seing "timeline timeline" ;-)

So I used to customize the description string to the much more useful output of "uname -r" just by editing said /etc/cron.hourly/snapper script.

In Fedora 21, all those cron files are gone and the automated snapshots are managed using pure systemd timers.

With the result that I cannot customize the description the way I used to do.

It looks like that the involved systemd helper files are all-binary, so I cannot edit them easily.

I believe that the used string resides in binary "/usr/lib/snapper/systemd-helper".

I'd love a fix allowing to customize the "description" string for generated snapshots, including the output of a command such as uname -r...

Kind regards.

$ sudo apt-get install snapper
[sudo] password for eddie:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 snapper : Depends: libboost-thread1.49.0 (>= 1.49.0-1) but it is not installable
           Depends: libsnapper but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

I have libboost-thread >= 1.49.0-1 installed:

$ dpkg -l libboost-thread*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  libboost-threa 1.54.0-4ubun amd64        portable C++ multi-threading
ii  libboost-threa 1.55.0-1     amd64        portable C++ multi-threading