[suggestion] replace snapper with btrbk

[zilexa]

A few reasons for this:

• snapraid-btrfs is a good solution as part of a backup strategy and btrbk allows for simple config files, supporting nearly every backup method, source and destination one can imagine.
• snapraid is often used together with MergerFS for pooling. Btrbk supports backup of a pool to btrfs disk with timeline/retention policies.

Also, I often experience non-documented or poorly documented issues with snapper:

• snapper has extremely annoying quirks: you can have your snapper configs set up perfectly in the right location. Still I have experienced with every setup, snapper just does not work out of the box. It often cannot even find the configs placed in /etc/snapper/configs.
• Snapper requires the folder /etc/sysconfig to exist, but during install this folder is not created and it is not part of the OS. During uninstall, the folder is deleted! Leading to the infamous DBus error.
• Snapper does not give clear errors when sysconfig folder does not exist.
• Snapper requires you to manually fix /etc/sysconfig/snapper file when you add/remove files from /etc/snapper/configs.

And also, the single most important reason:

• storing snapshots within the snapped subvolume makes absolutely no sense. I you delete the subvolume or it becomes inaccessible, so does the snapshot folder within. Snapshots belong next to the snapped subvolume, not within. btrbk does this neatly.

btrbk seems so much more straightforward (and catches errors).

I am trying to start fresh (new parity disk, deleted all content files). I created new config files via snapper CLI, snapper works. snapraid-btrfs still doesn't find any configs:

$ snapraid-btrfs ls --verbose
Snapper configs found:

snapraid-btrfs: No snapper configs found for any data drives in /etc/snapraid.conf 

Even though snapraid.conf:

data d1 /mnt/disks/cache/data
data d2 /mnt/disks/data1/data
data d3 /mnt/disks/data2/data

/etc/snapper/configs has files cache, data, data2 each containing the exact path that d1, d2, d3 have in the snapraid.conf.

[aprayoga]

hi @zilexa , I recently got similar issue as yours. snapraid-btrfs could not find config even though it is listed on snapper and snapraid.conf. After some time debugging, I found out for some reason the subvolume mount point got extra trailing space. My solution is to insert following line into line 688 to strip the trailing space subvol="${subvol%"${subvol##*[![:space:]]}"}"

the full code for your reference

find_configs_try() {
    local config field1 field2 field3 found subvol
    config="$1"
    found=
    if subvol="$("$my_snapper" -c "$config" get-config 2>/dev/null |
        sed -e '/^SUBVOLUME /!d' -e 's/^SUBVOLUME[ ]*| //')"
    then
        subvol="${subvol%"${subvol##*[![:space:]]}"}"
        while IFS=$' \t' read -r field1 field2 field3 ; do
            if [[ "$field1" =~ ^(data|disk)$ ]] &&
                   [[ "$field3" -ef "$subvol" ]]
            then
                found=1
                snapper_configs+=( "$config" )
                snapper_subvols[$config]="$subvol"
                snapraid_names[$config]="$field2"
            fi
        done < "$config_file"
        if [[ "$found" ]] ; then
            verbose \
                "Found $subvol in $config_file - using snapper config $config"
            return 0
        else
            return 1
        fi
    else
        return 2
    fi
}

[dim-geo]

And also, the single most important reason:

storing snapshots within the snapped subvolume makes absolutely no sense. I you delete the subvolume or it becomes >inaccessible, so does the snapshot folder within. Snapshots belong next to the snapped subvolume, not within. btrbk does this >neatly.

This can be addressed by an alternative snapshot layout of snapper