What's new

BACKUPMON BACKUPMON v1.8.20 -Oct 12, 2024- Backup/Restore your Router: JFFS + NVRAM + External USB Drive! CIFS/SMB/NFS! (Now available in AMTM!)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Change time to 00:30.
Already set the new strategy. 02:15 seems good to me:
a. I'm guaranteed to be in bed
b. It's outside the twighlight zone

😁
 
but what happens when the clocks roll back? Two backups?
No, crond compensates for DST changes.


EDIT: After testing it appears there is a bug/feature in crond whereby it doesn't compensate for DST changes despite the comments to that effect in the source code. So yes, when the time goes forward one hour's worth of jobs are skipped, and when the time goes backward one hour's worth of jobs are repeated.
 
Last edited:
No, crond compensates for DST changes.
However, this morning it didn't(?).

*EDIT*
Neither did Diversion_WeeklyStats and uiDivStats_trim.
 
Last edited:
However, this morning it didn't(?).

*EDIT*
Neither did Diversion_WeeklyStats and uiDivStats_trim.
Didn't for me either two weeks ago... EST timezone.
Strange. I've never had a problem with this myself, but then I'm not using the same custom scripts as you. Perhaps there's a bug in busybox somewhere. Did you see any "time disparity" messages in the syslog at the time the clocks changed?
 
Last edited:
Strange. I've never had a problem with this myself, but then I'm not using the same custom scripts as you. Perhaps there's a bug in busybox somewhere. Did you see any "time disparity" messages in the syslog at the time the clocks changed?

Compensating for DST changes has been a core function of crond ever since it's inception decades ago. For caveats see the DST section of the man page, although I notice the grace period should "officially" be 3 hours rather than busybox's one hour.
You'd think something like 30 2 * * * sh /jffs/scripts/backupmon.sh -backup #RunBackupMon# would just work... DST or not... agree with you. Could be a bug of some sort. Unfortunately my logs have rolled over long ago... hopefully @Ripshod still has some fresh log data to peek through.
 
You'd think something like 30 2 * * * sh /jffs/scripts/backupmon.sh -backup #RunBackupMon# would just work... DST or not... agree with you. Could be a bug of some sort. Unfortunately my logs have rolled over long ago... hopefully @Ripshod still has some fresh log data to peek through.
2:30 doesn't exist as clocks roll forward at 2:00, directly to 3:00. In the fall, it should not be an issue.
 
So the big news of the day is that BACKUPMON now officially supports NFS! Many thanks to @smarthome-enthusiast for all his help getting this tested and working! Also big changes to the UI to bring it in-line with VPNMON-R3's look & feel! As always, please reach out if I can be of any help...

What's new?
v1.7.1 - (March 24, 2024)
- MINOR:
Thanks to a push from @smarthome-enthusiast, BACKUPMON now supports NFS in addition to the standard CIFS/SMB methods of transferring data across a network to an NFS network share to safely store your router backups in case of disaster! All necessary changes to the config menu have been considered in order to handle NFS. When choosing NFS, an additional field will become available that allows you to enter optional "NFS Mount Options", understanding that different NFS implementations may require special mount options/switches, this field allows you to customize your connection based on your needs. Also huge thanks to @Martinski for revamping his mount point selector functionality in order to handle USB, CIFS/SMB and NFS mount points if they exist. Huge shoutout to @smarthome-enthusiast for all the testing he's helped with in getting this NFS functionality over the finishline! :)
- MINOR: BACKUPMON has been given a complete UI makeover, and is now on par with VPNMON-R3's look and feel. Emphasis has been given on simplifying the UI design, to account for more screen space, less distracting colors, standardizing submenu design, making it more friendly to use across the board.
- PATCH: Found some variable name mismatches under the restore -> secondary backups logic that was looking at variables for the primary backups. This has been fixed!

Download link (or update directly within BACKUPMON or AMTM):
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

Significant Screenshots:

Base UI changes to the overall look & feel, bringing it on par with VPNMON-R3:
1711300983592.png


New look and layout for the Setup + Operations Menu:
1711300995545.png


And an example of the configurations menu changes...
1711301008494.png


Example of the standards applied to each submenu item, showing currently selected values:
1711301137176.png


Enjoy! :)
 
hopefully @Ripshod still has some fresh log data to peek through
Honestly doesn't show anything related, other than flipping between 01:00 and 02:00 a few times (possibly conflict between the router's ntpd and ntpMerlin)
2:30 doesn't exist as clocks roll forward at 2:00, directly to 3:00. In the fall, it should not be an issue.
Maybe where you are in the world.
There's only one report and one confirmation report so it's hardly a serious error. Let this thread get back on topic now.
 
So the big news of the day is that BACKUPMON now officially supports NFS! Many thanks to @smarthome-enthusiast for all his help getting this tested and working! Also big changes to the UI to bring it in-line with VPNMON-R3's look & feel! As always, please reach out if I can be of any help...

What's new?
v1.7.1 - (March 24, 2024)
- MINOR:
Thanks to a push from @smarthome-enthusiast, BACKUPMON now supports NFS in addition to the standard CIFS/SMB methods of transferring data across a network to an NFS network share to safely store your router backups in case of disaster! All necessary changes to the config menu have been considered in order to handle NFS. When choosing NFS, an additional field will become available that allows you to enter optional "NFS Mount Options", understanding that different NFS implementations may require special mount options/switches, this field allows you to customize your connection based on your needs. Also huge thanks to @Martinski for revamping his mount point selector functionality in order to handle USB, CIFS/SMB and NFS mount points if they exist. Huge shoutout to @smarthome-enthusiast for all the testing he's helped with in getting this NFS functionality over the finishline! :)
- MINOR: BACKUPMON has been given a complete UI makeover, and is now on par with VPNMON-R3's look and feel. Emphasis has been given on simplifying the UI design, to account for more screen space, less distracting colors, standardizing submenu design, making it more friendly to use across the board.
- PATCH: Found some variable name mismatches under the restore -> secondary backups logic that was looking at variables for the primary backups. This has been fixed!

Download link (or update directly within BACKUPMON or AMTM):
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

Significant Screenshots:

Base UI changes to the overall look & feel, bringing it on par with VPNMON-R3:
View attachment 57414

New look and layout for the Setup + Operations Menu:
View attachment 57415

And an example of the configurations menu changes...
View attachment 57416

Example of the standards applied to each submenu item, showing currently selected values:
View attachment 57417

Enjoy! :)

@Viktor Jaep and @thelonelycoder

The latest update is telling me it's a downgrade :( Small things but just an FYI incase you didn't notice.

1711307000569.png
 
Last edited:
Hum. Thanks for noticing! I'll have to take a look at the AMTM logic to see why it is determining that!

EDIT: @ExtremeFiretop ... I think I remember @thelonelycoder saying that when it looks at version numbers, that it strips punctuation and such ... which might be why 1514 > 171
Yup, it‘s a case of too many patches and no minors.
 
EDIT: @ExtremeFiretop ... I think I remember @thelonelycoder saying that when it looks at version numbers, that it strips punctuation and such ... which might be why 1514 > 171
Yup, it‘s a case of too many patches and no minors.

Naturally, when I hear this my first thought is to just follow the standard flow for semantic versioning (semver) scheme (1.5.14 -> 1.6.4) which is what MerlinAU's github workflow uses:

Code:
- name: Determine Next Version Tag
        id: nextver
        run: |
          TAG=$(git tag --sort=-v:refname | head -n 1)
          if [[ $TAG == '' ]]; then
            TAG='v0.1.0' # Start from v0.1.0 if no tags are found
          fi
          MAJOR=$(echo $TAG | cut -d '.' -f 1 | cut -c 2-)
          MINOR=$(echo $TAG | cut -d '.' -f 2)
          PATCH=$(echo $TAG | cut -d '.' -f 3)


          if [[ $PATCH -eq 9 ]]; then
            PATCH=0
            if [[ $MINOR -eq 9 ]]; then
              MINOR=0
              MAJOR=$((MAJOR+1))
            else
              MINOR=$((MINOR+1))
            fi
          else
            PATCH=$((PATCH+1))
          fi


          NEXT_TAG="v$MAJOR.$MINOR.$PATCH"
          echo "Next version tag: $NEXT_TAG"
          echo "tag=$NEXT_TAG" >> $GITHUB_OUTPUT

So for example, our next release after 1.0.9 will automatically be 1.1.0.
Edit: I modified this script above in Github now that I've reviewed it, so it gives us more control, it's now based on the script version.
MerlinAU can have a patch number like 1.0.10 now.

However technically speaking @Viktor Jaep doesn't need to change anything since it is generally following semantic versioning (now).
This could be solved in AMTM instead of doing a direct comparison (i.e 1514 > 171) by doing a arithmetic conversion step first before comparison such as:

Code:
_ScriptVersionStrToNum_()
{
   if [ $# -eq 0 ] || [ -z "$1" ] ; then echo ; return 1 ; fi
   local verNum  verStr


   verStr="$(echo "$1" | awk -F '_' '{print $1}')"
   verNum="$(echo "$verStr" | awk -F '.' '{printf ("%d%03d%03d\n", $1,$2,$3);}')"
   verNum="$(echo "$verNum" | sed 's/^0*//')"
   echo "$verNum" ; return 0
}

Which would convert: 1.5.14 into: 1005014

Code:
_ScriptVersionStrToNum_ "1.5.14"
1005014
And
Code:
_ScriptVersionStrToNum_ "1.7.1"
1007001

So now it compares: 1005014 < 1007001 instead of 1514 > 171
This is how MerlinAU compares the version strings of Backupmon.. since Viktor changed his standard some time ago ;) Hehe.

With this change in AMTM, he could technically use a patch number as high as he wants.. (i.e backupmon version 1.5.96) and it would still compare correctly.
This is why I tagged both @Viktor Jaep and @thelonelycoder just to review the situation incase it wasn't noticed. Just food for thought that's why I said it was only small things.
 
Last edited:
Naturally, when I hear this my first thought is to just follow the standard flow for semantic versioning (semver) scheme (1.5.14 -> 1.6.4) which is what MerlinAU's github workflow uses:

Code:
- name: Determine Next Version Tag
        id: nextver
        run: |
          TAG=$(git tag --sort=-v:refname | head -n 1)
          if [[ $TAG == '' ]]; then
            TAG='v0.1.0' # Start from v0.1.0 if no tags are found
          fi
          MAJOR=$(echo $TAG | cut -d '.' -f 1 | cut -c 2-)
          MINOR=$(echo $TAG | cut -d '.' -f 2)
          PATCH=$(echo $TAG | cut -d '.' -f 3)


          if [[ $PATCH -eq 9 ]]; then
            PATCH=0
            if [[ $MINOR -eq 9 ]]; then
              MINOR=0
              MAJOR=$((MAJOR+1))
            else
              MINOR=$((MINOR+1))
            fi
          else
            PATCH=$((PATCH+1))
          fi


          NEXT_TAG="v$MAJOR.$MINOR.$PATCH"
          echo "Next version tag: $NEXT_TAG"
          echo "tag=$NEXT_TAG" >> $GITHUB_OUTPUT

So for example, our next release after 1.0.9 will automatically be 1.1.0.

However technically speaking @Viktor Jaep doesn't need to change anything since it is generally following semantic versioning (now).
This could be solved in AMTM instead of doing a direct comparison (i.e 1514 > 171) by doing a arithmetic conversion step first before comparison such as:

Code:
_ScriptVersionStrToNum_()
{
   if [ $# -eq 0 ] || [ -z "$1" ] ; then echo ; return 1 ; fi
   local verNum  verStr


   verStr="$(echo "$1" | awk -F '_' '{print $1}')"
   verNum="$(echo "$verStr" | awk -F '.' '{printf ("%d%03d%03d\n", $1,$2,$3);}')"
   verNum="$(echo "$verNum" | sed 's/^0*//')"
   echo "$verNum" ; return 0
}

Which would convert: 1.5.14 into: 1005014

Code:
_ScriptVersionStrToNum_ "1.5.14"
1005014
And
Code:
_ScriptVersionStrToNum_ "1.7.1"
1007001

So now it compares: 1005014 < 1007001 instead of 1514 > 171
This is how MerlinAU compares the version strings of Backupmon.. since Viktor changed his standard some time ago ;) Hehe.

With this change in AMTM, he could technically use a patch number as high as he wants.. (i.e backupmon version 1.5.96) and it would still compare correctly.
This is why I tagged both @Viktor Jaep and @thelonelycoder just to review the situation incase it wasn't noticed. Just food for thought that's why I said it was only small things.
That's an ingenious way to approach it! Nice work @ExtremeFiretop! :)
 
This could be solved in AMTM instead of doing a direct comparison (i.e 1514 > 171) by doing a arithmetic conversion step first before comparison such as:
I don't remember where I picked up the reduction method of determining if a version is higher or lower, might be @Adamm 's code from back then.

Anyway, no need to get too complicated with version number comparisons, I have all necessary things built into amtm and Diversion. I just don't use it for the update check. Again, I don't remember why I used the simplification method instead of what is already there:
Code:
version_check(){ echo "$@" | awk -F. '{ printf("%d%03d%03d%03d\n", $1,$2,$3,$4); }';}
if [ "$(version_check 1.7.1)" -gt "$(version_check 1.5.14)" ]; then
    echo "-->"
else
    echo "<--"
fi
The output of above is expectedly -->
 
I don't remember where I picked up the reduction method of determining if a version is higher or lower, might be @Adamm 's code from back then.

Anyway, no need to get too complicated with version number comparisons, I have all necessary things built into amtm and Diversion. I just don't use it for the update check. Again, I don't remember why I used the simplification method instead of what is already there:
Code:
version_check(){ echo "$@" | awk -F. '{ printf("%d%03d%03d%03d\n", $1,$2,$3,$4); }';}
if [ "$(version_check 1.7.1)" -gt "$(version_check 1.5.14)" ]; then
    echo "-->"
else
    echo "<--"
fi
The output of above is expectedly -->

Happy to see it's already incorporated!

I myself would think it's better to use that than the simplified version we see in the screenshot above.

Just my 2 cents. 😊
 
Done in my dev version:

View attachment 57432

Your fast! 😳
(I know you said it was already incorporated so probably a simple copy and paste for you!)

Looks great! @thelonelycoder. Just know I mean no ill intent, just something I noticed while I was checking my push out this evening. Figured I'd mention something somewhere.

(Didn't mean to step on anyone's toes!)
 
Your fast! 😳
(I know you said it was already incorporated so probably a simple copy and paste for you!)
More or less.
And for now, we are in the same time zone!
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top