hunleyd / btrfs-auto-snapshot Goto Github PK

I just updated to master and am receiving the following warning:

/usr/local/btrfs-auto-snapshot/btrfs-auto-snapshot: line 230: test: freqly: integer expression expected

The executed command is the following:

/usr/local/btrfs-auto-snapshot/btrfs-auto-snapshot --label=freqly --keep=4  '//'

Reason is the following code:

while test "${label}" -gt 0

-gt has the following docs:

NTEGER1 -gt INTEGER2
INTEGER1 is greater than INTEGER2

So, what's the reason for using while and -gt? I had expected a simple check for an empty string or alike?

                if test -n "${label}"
                then
                    case $label in
                        ([![:alnum:]_.:\ -]*)
                            log error "The $1 parameter must be alphanumeric."
                            argsp_cmdline_exit=${ERR_PREFIX_WRONG}
                            kill -SIGUSR1 $$
                        ;;
                    esac
                    prefix="${prefix#?}"
                fi

The check for --prefix has the same implementation.

Running version 2.0.3 on Ubuntu 20.04.5. My configuration:

root@ercole:/# btrfs subvolume list /
ID 364 gen 10654 top level 5 path veeam-repo
ID 8843 gen 10650 top level 5 path sub-test
ID 8850 gen 10628 top level 8843 path sub-test/.btrfs/btrfs-auto-snap_daily_2022-12-10-1608
ID 8851 gen 10631 top level 8843 path sub-test/.btrfs/btrfs-auto-snap_daily_2022-12-10-1610
ID 8852 gen 10648 top level 8843 path sub-test/.btrfs/btrfs-auto-snap_daily_2022-12-10-1635

When I run btrfs-auto-snapshot, the current working directory must be / and the subvolume name must always be written in relative format. If the current directory is any other directory, the command fails:

root@ercole:/opt# /opt/btrfs-auto-snapshot --dry-run --keep=3 --label=daily sub-test
ERROR: cannot find real path for 'veeam-repo': No such file or directory
ERROR: cannot find real path for 'sub-test': No such file or directory
Error: It appears that 'sub-test' is not a BTRFS file system!

Is this the expected behavior?

Thank you very much in advance
Massimo

Issue with variable definition
They are missing a / in between mount path and subvolume name

The error seems to be within the sed statement on line 446 (but I'am not 100% sure)

The issue of my error message
ERROR: cannot find real path for '/srv/databackups': No such file or directory
Definetly comes from a missing / (slash) between the mount path and the subvolume (backup in this example)

abs_path="$(echo "${subvol}" | sed -r "s!^${mp_subvol}!${mp}!")"

bash -x btrfs-auto-snapshot --keep=1 --label=daily --verbose --dry-run /srv/data
...
+++ btrfs subvolume list -o /srv/data
+++ awk '{print $9}'
++ mp_subvols='backups
db
webroot
.btrfs/btrfs-auto-snap_daily_2023-02-07-1807'
++ IFS=
++ read -r subvol
++ '[' -z backups ']'
++ local abs_path
++ local pattern
++ local matches
+++ echo backups
+++ sed -r 's!^!/srv/data!'
++ abs_path=/srv/databackups
+++ echo /srv/databackups
+++ sed -r 's!^//!/!'
++ abs_path=/srv/databackups
+++ printf '%s\n' /srv/data
++ pattern=/srv/data
+++ echo /srv/data
+++ grep --count -F -f - -x /dev/fd/63
++++ echo /srv/databackups
++ matches=0
++ '[' 0 '!=' 0 ']'
++ local show
++ local sp
++ local no_parent_uuid
++ local is_read_only
+++ btrfs subvolume show /srv/databackups
ERROR: cannot find real path for '/srv/databackups': No such file or directory
...

Software used

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

$ btrfs --version
btrfs-progs v5.10.1 

$ uname -a
Linux rockpi 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/Linux

I have a subvolume at /, /home, and /usr. When I run the script:

> ./btrfs-auto-snapshot -n /
ERROR: cannot find real path for '/@': No such file or directory
ERROR: cannot find real path for '/@home': No such file or directory
ERROR: cannot find real path for '/usr/@': No such file or directory
ERROR: cannot find real path for '/usr/@/usr': No such file or directory
ERROR: cannot find real path for '/usr/@home': No such file or directory
ERROR: cannot find real path for '/home/@': No such file or directory
ERROR: cannot find real path for '/home/@/usr': No such file or directory
ERROR: cannot find real path for '/home/@home': No such file or directory
Doing snapshots of /
mkdir //.btrfs
Notice: btrfs subvolume snapshot / /.btrfs/btrfs-auto-snap_-2022-07-07-2121

If I try to backup everything

> ./btrfs-auto-snapshot -n //
ERROR: cannot find real path for '/@': No such file or directory
ERROR: cannot find real path for '/@home': No such file or directory
ERROR: cannot find real path for '/usr/@': No such file or directory
ERROR: cannot find real path for '/usr/@/usr': No such file or directory
ERROR: cannot find real path for '/usr/@home': No such file or directory
ERROR: cannot find real path for '/home/@': No such file or directory
ERROR: cannot find real path for '/home/@/usr': No such file or directory
ERROR: cannot find real path for '/home/@home': No such file or directory
Doing snapshots of / /usr /usr /home
mkdir //.btrfs
Notice: btrfs subvolume snapshot / /.btrfs/btrfs-auto-snap_-2022-07-07-2122
mkdir /usr/.btrfs
Notice: btrfs subvolume snapshot /usr /usr/.btrfs/btrfs-auto-snap_-2022-07-07-2122
mkdir /usr/.btrfs
Notice: btrfs subvolume snapshot /usr /usr/.btrfs/btrfs-auto-snap_-2022-07-07-2122
mkdir /home/.btrfs
Notice: btrfs subvolume snapshot /home /home/.btrfs/btrfs-auto-snap_-2022-07-07-2122

Snapshots themselves mostly seem to work. Though, keep isn't reliably deleting the old backups.

When running btrfs-auto-snapshot on Ubuntu 20.04 LTS with --syslog option, I get the following error:

logger: invalid option -- 'r'
Try 'logger --help' for more information.

this project needs a new maintainer. I no longer run BTRFS on my personal device and cannot give the sporadic issues that are filed the timeliness nor the thoroughness they deserve. Anyone want to step up?

I came across this in the past already: Snapshots are created with a resolution of a minute, while especially during tests one might need to create snaps far more often. Waiting a minute during tests is cumbersome. Though, when not doing so with the original code, it seems that different problems might happen. In my older Ubuntu 18.03 I got error messages regarding read-only file systems and the snapshots simply wasn't created. While the error message was a bit difficult to understand without any useful context in the error message, it didn't really harm.

When implementing #9 OTOH, I have the feeling that behaviour of BTRFS tools changed in those cases. Whenever a snapshot target directory is already available, it seems like BTRFS simply adds the directory name of the snapshot source as additional child directory. This makes creating the snapshot complete, but is a problem when snapshotting / itself, as that isn't a compatible child name. This leads to the following error message:

localhost:/usr/local/btrfs-auto-snapshot # ./btrfs-auto-snapshot --keep=50 //
localhost:/usr/local/btrfs-auto-snapshot # ./btrfs-auto-snapshot --keep=2 //
ERROR: invalid snapshot name '/'
localhost:/usr/local/btrfs-auto-snapshot # ./btrfs-auto-snapshot --keep=20 //

But even if things succeed the automatically created directory makes the formerly available snapshots directory not being a snapshots directory only anymore, but contain content. This makes deleting the snapshot directory as snapshot fail and instead one needs to delete the content first, empty the directory that way and afterwards can delete the snapshot itself as usual. Otherwise the following error is printed:

localhost:/usr/local/btrfs-auto-snapshot # ./btrfs-auto-snapshot --keep=5 //
ERROR: Could not destroy subvolume/snapshot: Directory not empty
ERROR: Could not destroy subvolume/snapshot: Directory not empty
[...]

Though, according to my tests it seems that deleting snapshots with rm -r * works as well now. Did that on the problematic snapshots and the additional content and the snap dirs themself were properly removed. And really removed, not only "hidden" or alike, as btrfs subvolume list / didn't show them anymore.

I've implemented a workaround simply based on deleting a possibly already existing snapshots and creating it afterwards again. The argument simply is that with the current limitation in place, it makes test easier and if one creates new snapshots, user's interest is to have the most current per minute instead of the oldest one. That would especially defeat tests as simply nothing would be done in case of existing snaps per minute, while creating them might the test itself.

log notice "$( ${dry_run} btrfs subvolume delete -c "${snap_path}" 2> '/dev/null' )"
log notice "$( ${dry_run} btrfs subvolume snapshot   ${snap_opts} )"

So, we have the following options in the long term:

1. keep things as they are: delete+create
2. look for existing snaps and don't create new ones.
3. add seconds to the directory names, which is enough most likely.