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

[Ripshod]

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

 

[ColinTaylor]

but what happens when the clocks roll back? Two backups?

No, crond compensates for DST changes.

asuswrt-merlin.ng/release/src/router/busybox/miscutils/crond.c at 4c689dffeb71ecbd30cea003ec0c3ea55085a150 · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

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.

 

[Ripshod]

No, crond compensates for DST changes.

However, this morning it didn't(?).

*EDIT*
Neither did Diversion_WeeklyStats and uiDivStats_trim.

 

[Viktor Jaep]

However, this morning it didn't(?).

Didn't for me either two weeks ago... EST timezone.

 

[ColinTaylor]

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?

 

[Viktor Jaep]

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.

 

[visortgw]

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.

 

[Viktor Jaep]

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):

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:

New look and layout for the Setup + Operations Menu:

And an example of the configurations menu changes...

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

Enjoy!

 

[Ripshod]

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.

 

[ExtremeFiretop]

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):

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.

 

[Viktor Jaep]

@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.

View attachment 57428

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

 

[thelonelycoder]

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.

 

[ExtremeFiretop]

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:

- 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:

_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

_ScriptVersionStrToNum_ "1.5.14"
1005014

And

_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.

 

[Viktor Jaep]

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:

- 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:

_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

_ScriptVersionStrToNum_ "1.5.14"
1005014

And

_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!

 

[ExtremeFiretop]

That's an ingenious way to approach it! Nice work @ExtremeFiretop!

Just know I only make these suggestions as a way to improve the overall general experience for the user base!

 

[thelonelycoder]

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:

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 -->

 

[ExtremeFiretop]

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:

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.

 

[thelonelycoder]

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

Done in my dev version:

 

[ExtremeFiretop]

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!)

 

[thelonelycoder]

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!