Rsnapshot change start time

  • Is there anyway to change when Rsnapshot start running?

    Not in a permanent way for the OMV 4.x version of the plugin. For OMV 5.x, I added a start hour variable (OMV_RSNAPSHOT_STARTING_HOUR) that can be set in /etc/default/openmediavault

    omv 5.5.5 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • I found these two files /etc/cron.d/openmediavault-rsnapshot and /etc/cron.d/rsnapshot, will none of them make rsnapshot run at the specified times?

    Yes but as I mentioned previously, changing those will not be a permanent change. Any change to the plugin will overwrite your changes. The most permanent way you can change it on OMV 4.x is to change the code in /usr/share/openmediavault/mkconf/rsnapshot - lines 48-52. Any plugin update will overwrite this change though.

    omv 5.5.5 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • You could try it, but they are likely to be overwritten when updating.


    See this thread: Does anyone know how to make RSnapshot's cron file stick


    Also, we are discussing the rsnapshot plugin. I assume that you could simply install rsnapshot proper and use that without the OMV GUI.


    Or you could do as I do, roll your own rsync snapshot scripts and run them whenever you like from entries in crontab. And do everything the super-cool command line way.


    https://github.com/WikiBox/snapshot.sh

    Be smart - be lazy. Clone your rootfs.
    OMV 5: 9 x Odroid HC2 + 1 x Odroid HC1 + 1 x Raspberry Pi 4

  • Then perhaps one option would be to first copy /usr/share/openmediavault/mkconf/rsnapshot to some other folder and then edit lines 48-52, and then have a scheduled job copy it back to /usr/share/openmediavault/mkconf/ and overwrite the rsnapshot file in case it has ben updated?
    Or maybe that will just mess things up?

  • Then perhaps one option would be to first copy /usr/share/openmediavault/mkconf/rsnapshot to some other folder and then edit lines 48-52, and then have a scheduled job copy it back to /usr/share/openmediavault/mkconf/ and overwrite the rsnapshot file in case it has ben updated?
    Or maybe that will just mess things up?

    You would only need to update it when there is a plugin update. I'm hoping to not update any OMV 4.x plugins again. So, you may never have to worry about it. Moving to OMV 5.x would eliminate worries...

    omv 5.5.5 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Hi there,


    I have recently been looking into this as well, because I had the following requirements:


    - have weekly backup job 1 run on Sunday nights

    - have weekly backup job 2 run on Monday nights

    - have backup job 3 run every 4th week on Wednesday nights


    So, in this case, it is not just about adjusting the starting hour, but a general customisation of the schedule (which I believe is a fairly common use case, by the way). I found out that in OMV 5, the rsnapshot script (/var/lib/openmediavault/cron.d/rsnapshot), the cron table (/etc/cron.d/openmediavault-rsnapshot) and the config files (/var/lib/openmediavault/rsnapshot.d/rsnapshot-${uuid}.conf) are re-created from scratch during the salt deploy phase with hard-coded content from /usr/sbin/omv-rsnapshot-conf.


    To implement my schedule in a (somewhat) permanent way, I am using this workaround:
    I put the desired cron schedule in a master template file (/etc/default/openmediavault-rsnapshot), making use of selective execution by UUID:



    I modified the /usr/sbin/omv-rsnapshot-conf script so that it does not re-create the cron table, but duplicates the master template to /etc/cron.d/ instead (replace lines 46-57 by cp /etc/default/openmediavault-rsnapshot /etc/cron.d/openmediavault-rsnapshot). That way, my custom schedule will survive the salt deploy updates, and should only need to be maintained when there is an update of the rsnapshot plugin itself. This works fine for me so far.


    Firstly, I would like to give this as a hint to everybody who might be facing the same challenge.


    Secondly, I would like to understand why this needs to be so cumbersome. I am not speaking of GUI integration; but why is everything hard-coded into the deploy script, when there would be possibilities to make it flexible (like using user-adaptable templates; they could be checked for, and if not present, it could still be re-created in the current way)? Particularly, I don't understand why on the one hand there is a feature of UUID-selective job execution implemented in the rsnapshot script (which is a great thing I am happy to have now), while on the other hand its use is generally prevented by discarding any modifications to the cron table that might try to apply it. The same goes for modifications to the .conf files, like setting loglevel or other options. I just can't make a real sense of it and think this is unnecessarily limiting rsnapshot's power and flexibility inside the plugin.


    What do you think of this? Wouldn't that be an opportunity for improvement with little effort?

  • Secondly, I would like to understand why this needs to be so cumbersome. I am not speaking of GUI integration; but why is everything hard-coded into the deploy script, when there would be possibilities to make it flexible (like using user-adaptable templates; they could be checked for, and if not present, it could still be re-created in the current way)? Particularly, I don't understand why on the one hand there is a feature of UUID-selective job execution implemented in the rsnapshot script (which is a great thing I am happy to have now), while on the other hand its use is generally prevented by discarding any modifications to the cron table that might try to apply it. The same goes for modifications to the .conf files, like setting loglevel or other options. I just can't make a real sense of it and think this is unnecessarily limiting rsnapshot's power and flexibility inside the plugin.

    What do you think of this? Wouldn't that be an opportunity for improvement with little effort?

    The rsnapshot plugin has been around a long time. I didn't write but I do maintain it. I use it myself. Very few people have had a problem with the scheduling. In my opinion, rsnapshot is really meant to run hourly. If your server isn't on all the time, no problem. It will run hourly when it is on. If you want extra jobs run, you could just scheduled in Scheduled jobs tab or put them in a different cron tab. I guess I could add a value to defaults that would allow you to disable cron job management but still the rsnapshot job files.

    omv 5.5.5 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • ryecoaaron,

    thank you for your reply.

    Yes, it is possible to do it all without the rsnapshot plugin, like Adoby suggested before. But that would mean manually replaying the configuration and scripting work that the plugin does quite well. That's why I really like your idea of optionally switching off the cron job management only, this would just do what I want it to. Don't know if I'm alone with it, but I would appreciate if such a switch could be implemented.

  • If you set OMV_RSNAPSHOT_DISABLE_CRON=1, the plugin will no longer create/modify/delete the cron job. Version 5.0.4 is in the repo now.

    omv 5.5.5 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!