Changes in rsnapshot behavior

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Changes in rsnapshot behavior

      Hello,


      I started using the rsnapshot plugin some weeks ago. Everything was fine.

      The backup files were stored under the label-ID of the source HDD on my backup HDD ([BACKUP-HDD]/[LABEL]/weekly.0/[folder]).

      Today I added a new backup job. I saw, also the old job were rewritten in /var/lib/openmediavault/rsnapshot.d/rsnapshot-*.conf.

      Now all the backups are using the UUID of the source HDD. They want to be stored in [BACKUP-HDD]/media/[UUID]/weekly.0/[folder].

      This breaks with the previous backups. The monthly can't be done, because it didn't find the weekly.3 and the weekly starts from source with copying the real files instead of hardlinking them.

      Is this a bug or was the behavior changed with an update? Is it from the plugin or form the way OMV submit the paths to the plugin? Will it changed back or will it stay like this?

      I don't want to reorder the structure of the backups now, for rolling it back in a couple of days/weeks...


      thanks,

      will;
    • Re: Changes in rsnapshot behavior

      None of the core functionality has been changed since the plugin was released. I use the plugin myself and it isn't having any issues??
      omv 4.1.6 arrakis | 64 bit | 4.16 backports kernel | omvextrasorg 4.1.7
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please read this before posting a question.
      Please don't PM for support... Too many PMs!
    • Re: Changes in rsnapshot behavior

      Okay. How are the backups stored on your mashine? The way with the label or with /media/UUID ??

      What is the planned behavior of the plugin?

      Did you add, remove or change one of your rsnapshot job in between the last two or four weeks?

      Because, everything was fine for me too. I played around a little bit with anacron this morning and did a weekly snapshot to the old supposed directory (LABEL). Then I add a new job and the storage target changed. I figured out, that also the old jobs were rewritten in /var/lib/openmediavault/rsnapshot.d/, by saving the new one. This was the point the target changed.

      will;
    • Re: Changes in rsnapshot behavior

      Mine are stored by label. I haven't changed anything in quite a while. Does your source drive have a label? What filesystem is the source drive?
      omv 4.1.6 arrakis | 64 bit | 4.16 backports kernel | omvextrasorg 4.1.7
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please read this before posting a question.
      Please don't PM for support... Too many PMs!
    • Re: Changes in rsnapshot behavior

      The backup drive has a label too.

      I suspect you could reproduce the (miss)behavior, when you backup your confs form /var/lib/openmediavault/rsnapshot.d/ and add, remove or change a rsnapshot job in the webgui and then compare the *.conf files. would you be so kind to test this?

      will;
    • Re: Changes in rsnapshot behavior

      I already have reproduced it in a VM.

      It uses path instead of label if the source drive is xfs because the script uses e2label to get the drive label.

      For some reason, even if I use a labeled ext4 partition, it still uses the path. The test to determine if it uses label is the following:

      # if mountpoint exists, sourcedevice is block and filesystem has a label, use the label as backup subdir name

      My VM is failing the "sourcedevice is block" test which makes it uses the path instead of label. I'm not sure what changed but I am wondering why it checks if it is a block device. If I remove the block check, it works for ext4 partitions.
      omv 4.1.6 arrakis | 64 bit | 4.16 backports kernel | omvextrasorg 4.1.7
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please read this before posting a question.
      Please don't PM for support... Too many PMs!
    • Re: Changes in rsnapshot behavior

      Okay, well... I'm using ext4 file system, of course. It has a label. Everything seems to be alright...

      What does it mean? Is it a bug, that will be fixed someday?

      Where can I remove this "sourcedevice is block"-check? Or should I wait for an update.

      At the moment I deactivated all my backup jobs... no good.

      will;
    • Re: Changes in rsnapshot behavior

      Fixed someday? I thought that's what we were discussing how to do and I am one that can change it :) I will remove the block check and we will see if any problems arise. Update should be there in a few minutes.
      omv 4.1.6 arrakis | 64 bit | 4.16 backports kernel | omvextrasorg 4.1.7
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please read this before posting a question.
      Please don't PM for support... Too many PMs!
    • Re: Changes in rsnapshot behavior

      I thought you were using OMV 0.6/1.0. The 1.0.2 version won't work with 0.5. If you want to make the change manually, do this:

      Source Code

      1. nano +86 /usr/share/openmediavault/mkconf/rsnapshot


      Change the line to this:

      Source Code

      1. if [ -e "${mountpoint}" ] && [ -n "$(e2label ${sourcedevice})" ]; then


      ctrl-o to save, ctrl-x to exit
      omv 4.1.6 arrakis | 64 bit | 4.16 backports kernel | omvextrasorg 4.1.7
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please read this before posting a question.
      Please don't PM for support... Too many PMs!
    • Re: Changes in rsnapshot behavior

      Hello,

      Oh no, I'm very sorry. I forgot to mention, that I'm on stable. OMV is 0.5.53, OMV-Extras is 0.6.22.1 and openmediavault-rsnapshot is 0.5.6.2.

      Now I chagend the line like you described. But now something really scary happened! The source drive suddenly lost/changed its label! Now it uses the first part of the uuid with the prefix "/media/":

      Source Code

      1. /dev/sda1: LABEL="/media/9bc82394-" UUID="9bc82394-033a-4bd4-8c45-22b9daa785f5" TYPE="ext4"


      I'm very sure, that yesterday the label still was "Glotze4T"...

      I don't think this is related to rsnapshot or change in the conf file I did. But I've little anxiety, now...

      I'm going to check my log files.

      will;
    • Re: Changes in rsnapshot behavior

      All you did was remove an statement in the if statement. Not sure how that would change the drive label??
      omv 4.1.6 arrakis | 64 bit | 4.16 backports kernel | omvextrasorg 4.1.7
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please read this before posting a question.
      Please don't PM for support... Too many PMs!
    • Re: Changes in rsnapshot behavior

      Hi ryecoaaron,

      at first I did a separate backup of my files, because this really strange behavior makes me fear. This took a while.

      This morning i figured out how to change back the label (I never needed to do this before) and now I understand what happened.

      Source Code

      1. e2label ${sourcedevice}

      changes the label!

      from "/usr/share/openmediavault/mkconf/rsnapshot"

      Source Code

      1. sourcedevice="$(cat /etc/mtab | grep ${mountpoint} | cut -d " " -f 1)"

      gives me

      Source Code

      1. root@rumpelkiste:~# cat /etc/mtab | grep /media/9bc82394-033a-4bd4-8c45-22b9daa785f5 | cut -d " " -f 1
      2. /dev/sda1
      3. /media/9bc82394-033a-4bd4-8c45-22b9daa785f5/Filme

      The second line (/media/9bc82394-033a-4bd4-8c45-22b9daa785f5/Filme) is from a shared folder for FTP. See my mtab below.

      by executing the script I have

      Source Code

      1. e2label /dev/sda1 /media/9bc82394-033a-4bd4-8c45-22b9daa785f5/Filme

      what says change the label...

      Here is my complete mtab. Where you caan see the two entries for the mount point.

      Source Code

      1. root@rumpelkiste:~# cat /etc/mtab
      2. /dev/sdf1 / ext4 rw,errors=remount-ro 0 0
      3. tmpfs /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
      4. proc /proc proc rw,noexec,nosuid,nodev 0 0
      5. sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
      6. udev /dev tmpfs rw,mode=0755 0 0
      7. tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
      8. devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
      9. tmpfs /tmp tmpfs rw 0 0
      10. /dev/sdf6 /media/75ce456e-51cc-4ad7-8864-f1f91ba5ff15 ext4 rw,noexec,_netdev,acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 0 0
      11. /dev/sdc1 /media/09e225a1-1518-4274-a444-8339d2cfb907 ext4 rw,noexec,_netdev,acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 0 0
      12. /dev/sdb1 /media/dbaf6442-82a4-489a-9014-de555f73b16f ext4 rw,noexec,_netdev,acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 0 0
      13. /dev/sdd1 /media/4bdd7dd7-9a23-4b18-a7bf-090fb816ea45 ext4 rw,noexec,_netdev,acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 0 0
      14. /dev/sde1 /media/d044340f-0554-4c3d-aaf7-f0739a2f2925 ext4 rw,noexec,_netdev,acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 0 0
      15. /dev/sda1 /media/9bc82394-033a-4bd4-8c45-22b9daa785f5 ext4 rw,noexec,_netdev,acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 0 0
      16. /media/4bdd7dd7-9a23-4b18-a7bf-090fb816ea45 /home/ftp/Data1T none rw,bind 0 0
      17. /media/09e225a1-1518-4274-a444-8339d2cfb907/Musik/Alben /home/ftp/Alben none rw,bind 0 0
      18. /media/9bc82394-033a-4bd4-8c45-22b9daa785f5/Filme /home/ftp/Filme_FTP none rw,bind 0 0
      Display All


      will;
    • Re: Changes in rsnapshot behavior

      Hi ryecoaaron,

      I tried a few things to handle multiple occurrence of UUIDs in the mtab.

      Source Code

      1. sourcedevice="$(cat /etc/mtab | grep ${mountpoint} -m 1 | cut -d " " -f 1)"

      This would use only the first line. But I don't know, if the FTP mounts will always appear at the end of mtab.
      If not you could use an additional grep pattern "/dev/"

      Source Code

      1. sourcedevice="$(cat /etc/mtab | grep ${mountpoint} | grep "/dev/" | cut -d " " -f 1)"


      I fiddle around a little bit to find a way, which is not possibly changing something.

      Source Code

      1. sourcedevice=$(ls -l /dev/disk/by-uuid | grep ${mountpoint#/media/} | cut -d "/" -f 3);
      2. # Returns only the "sdxx". Needs a "/dev/" in front, if it is used somwhere else.;
      3. ls -l /dev/disk/by-label | grep $sourcedevice | cut -d " " -f 10
      4. # Returns the label.

      But this will have some problems with special characters or spaces in the label. They are replaced with "\x**". I don't know what convention is.

      Maybe you could also include a check for spaces like

      Source Code

      1. if [[ " echo $sourcedevice" =~ " " ]]
      2. then
      3. # stop and warn
      4. else
      5. # proceed
      6. fi


      What do you think?

      will;
    • Re: Changes in rsnapshot behavior

      Spaces would be easy to change to underscores. I am fine with using the by-uuid and by-label method. I will check it out :)
      omv 4.1.6 arrakis | 64 bit | 4.16 backports kernel | omvextrasorg 4.1.7
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please read this before posting a question.
      Please don't PM for support... Too many PMs!
    • Re: Changes in rsnapshot behavior

      Okay, I just recognized, that the "cut -d " " -f 10" is not correct, because the number of spaces in "ls -l" is not constant. Sorry.

      edit:

      Source Code

      1. ls -l /dev/disk/by-label | grep $sourcedevice | cut -d ":" -f 2 | cut -d " " -f 2


      should work!?

      edit2: No it doesn't. Because the time/date can differ too.

      Source Code

      1. ls -l /dev/disk/by-label --time-style=long-iso | grep $sourcedevice | cut -d ":" -f 2 | cut -d " " -f 2