BACKUPMON BACKUPMON v1.5.10 -Mar 1, 2024- Backup/Restore your Router: JFFS + NVRAM + External USB Drive! (**Thread closed due to age**)

[Ripshod]

Remove the /tmp/mnt/primary mount you manually created and let BACKUPMON create it for you.

 

[Viktor Jaep]

In fact... it might be a good idea to add a ping test to this as well. Just to see if the router can ping the backup target... Might add that to my list!

 

[Viktor Jaep]

@Goobi ... your post disappeared, but this is the mount statement:

  mount -t cifs \\10.0.100.90\Backups /tmp/mnt/primary -o "vers=2.1,username=admin,password=admin"

 

[ColinTaylor]

@Goobi ... your post disappeared, but this is the mount statement:

  mount -t cifs \\10.0.100.90\Backups /tmp/mnt/primary -o "vers=2.1,username=admin,password=admin"

Indeed. You were using NFS shared directories on your NAS whereas this script only supports SMB. I guess you've realised that which is why you deleted your post.

 

[Goobi]

I would try making sure that your 10.0.100.90 device is correctly configured. Seems that it's refusing your connection from the router. Could be network share permission issues? Could be username/pwd issues? What kind of device is .90?

PS. I'm so glad I built this tester functionality in... this is exactly what it's useful for!

It is a Qnap NAS and I am able to ping it from the router. I currently run rsync from my router to it, but was considering changing to your solution.

When I run the exportfs command on the NAS, I can see that I allowed the NAS to accept router's IP address and attach to the share:

/share/CACHEDEV1_DATA/Backups
                10.0.100.1(async,wdelay,hide,no_subtree_check,fsid=04d973109165951ada4e99d847f91064,sec=sys,rw,insecure,no_root_squash,no_all_squash)

/share/NFSv=4/Backups
                10.0.100.1(async,wdelay,nohide,no_subtree_check,fsid=058ec201d704c71e6e9713e205279b89,sec=sys,rw,insecure,no_root_squash,no_all_squash)

I also deleted the directory I created, but still the same error persists:

Selection: t

Messages:
ALERT: External Drive directory not set. Created test directory under: /tmp/mnt/primary
mount: mounting \\10.0.100.90\Backups on /tmp/mnt/primary failed: Connection refused
WARNING: Unable to mount to external drive. Retrying...
mount: mounting \\10.0.100.90\Backups on /tmp/mnt/primary failed: Connection refused
WARNING: Unable to mount to external drive. Retrying...
ERROR: Unable to mount to external drive (/tmp/mnt/primary). Please check your configuration. Exiting.
ERROR: Failed to run Network Connect Test Script -- Drive mount failed. Please check your configuration!
Press any key to acknowledge...

 

[ColinTaylor]

@Goobi See my previous post. This script does not support NFS.

 

[Goobi]

I totally missed that it is CIFS vs NFS. Thanks for pointing that out @ColinTaylor!

 

[Goobi]

@Goobi ... your post disappeared, but this is the mount statement:

  mount -t cifs \\10.0.100.90\Backups /tmp/mnt/primary -o "vers=2.1,username=admin,password=admin"

Thanks @Viktor Jaep totally missed this post! All set!

 

[Viktor Jaep]

Thanks @Viktor Jaep totally missed this post! All set!

From the looks of it, the Qnap NAS is able to support CIFS/SMB... might just be a quick config change?

 

[Viktor Jaep]

I had an idea, @Goobi ... wondering if this statement works for you? Let me know... because then I could make this an option to pick from (CIFS/NFS)

mount -t nfs \\10.0.100.90\Backups /tmp/mnt/primary -o "vers=2.1,username=admin,password=admin"

 

[ColinTaylor]

I had an idea, @Goobi ... wondering if this statement works for you? Let me know... because then I could make this an option to pick from (CIFS/NFS)

mount -t nfs \\10.0.100.90\Backups /tmp/mnt/primary -o "vers=2.1,username=admin,password=admin"

That syntax is completely wrong for NFS.

 

[Viktor Jaep]

That syntax is completely wrong for NFS.

I'm finding so much conflicting information... some say you don't need usernames/passwords, others say you do... and I unfortunately don't seem to have a good way to test this... What's your take on this one? Does anyone here in this forum mount with NFS that would please be willing to share their mount statement?

mount -t nfs -O user=root,pass=mypass 192.168.100.10:/backups /tmp/mnt/primary

 

[Viktor Jaep]

Adding a new BACKUPMON Beta out there to catch up on some recent changes and fixes I've made... There's some really important ones in here that will require you to save your configurations... please read carefully! I have tested as many different variations as I could, but looking to you for any input/feedback!

What's new?
v1.23b - (TBA)
- FIXED: BACKUPMON will now remove any remaining copy of backupmon.cfg in the /jffs/scripts folder should you have performed a restore. This was causing some conflicts between it and a similar copy that was located under the /jffs/addons/backupmon.d/ folder. Thanks to @Ripshod for finding this!
- FIXED: Now testing to see if your EXT USB drive label is blank, and will require having at least a 2-char value before being able to run. It is important to name your devices, and not keep them blank/null. This wreaks havoc on all kinds of stuff. Please use this as a best-practice for any device you interact with. Just give it a name. All one word, no spaces, no crazy special characters. It's certainly easier to identify what device is having problems should you ever need to troubleshoot.
- CHANGED: Incorporated changes to the way passwords are being saved, now using the base64 method suggested by @PeterT and @ColinTaylor. Passwords are now encoded via base64 and saved to your config file. PLEASE NOTE: this change will require you to go into your config, and resave your passwords into proper base64 encoding. I've added a test to the script to determine if your passwords need to be resaved, and will direct you to the setup menu. This means your passwords can now be overly complex, using special characters, including the \ and $ characters, which normally cause all kinds of trouble in these kinds of scripts. Many thanks goes to @SomeWhereOverTheRainBow for his help coming up with a clever way to grep openssl to determine valid base64 passwords or invalid plaintext passwords!
- ADDED: Included the current model/firmware/build in the instructions.txt file, including a warning not to restore your router from an older firmware/build or model type, or you may face possibly bricking your router. This info is now also shown within the setup menu, and is written to a routerfw.txt file located under each of your backup folders. This is to keep track what router model/firmware build each backup was taken with. When going through a restore, BACKUPMON will compare your router's current model/firmware/build and compare it to the model/firmware/build found in the backup folder's routerfw.txt file... if they match, it proceeds with an uninterrupted restore. If it notices a difference, it will give you explicit warnings not to proceed, and asks you whether or not you want to continue, but won't stop you from overwriting your router with an older configuration from a previous firmware. This is done at your own risk. I built this roadblock to prevent people from possibly unknowingly damaging their routers if they happen to restore an older firmware, or think they can restore a backup from an RT-AC86U to a GT-AX6000 (or the like).
- ADDED: Included a ping test in the backup target network connection tester functionality. Thought this would be a worthy add-on when troubleshooting getting your router talking to your backup target. Please note, your backup target must have capabilities of returning icmp/ping requests to show valid results, but this won't stop the testing process.

Beta Download Link:

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon-1.23b1.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

 

[PeterT]

Adding a new BACKUPMON Beta out there to catch up on some recent changes and fixes I've made... There's some really important ones in here that will require you to save your configurations... please read carefully! I have tested as many different variations as I could, but looking to you for any input/feedback!

Seemed to work. Have you considered making the test network connection option default to using the configured values from the setup and config menu?

 

[visortgw]

Adding a new BACKUPMON Beta out there to catch up on some recent changes and fixes I've made... There's some really important ones in here that will require you to save your configurations... please read carefully! I have tested as many different variations as I could, but looking to you for any input/feedback!

What's new?
v1.23b - (TBA)
- FIXED: BACKUPMON will now remove any remaining copy of backupmon.cfg in the /jffs/scripts folder should you have performed a restore. This was causing some conflicts between it and a similar copy that was located under the /jffs/addons/backupmon.d/ folder. Thanks to @Ripshod for finding this!
- FIXED: Now testing to see if your EXT USB drive label is blank, and will require having at least a 2-char value before being able to run. It is important to name your devices, and not keep them blank/null. This wreaks havoc on all kinds of stuff. Please use this as a best-practice for any device you interact with. Just give it a name. All one word, no spaces, no crazy special characters. It's certainly easier to identify what device is having problems should you ever need to troubleshoot.
- CHANGED: Incorporated changes to the way passwords are being saved, now using the base64 method suggested by @PeterT and @ColinTaylor. Passwords are now encrypted via base64 and saved to your config file. PLEASE NOTE: this change will require you to go into your config, and resave your passwords into proper base64 encoding. I've added a test to the script to determine if your passwords need to be resaved, and will direct you to the setup menu. This means your passwords can now be overly complex, using special characters, including the \ and $ characters, which normally cause all kinds of trouble in these kinds of scripts. Many thanks goes to @SomeWhereOverTheRainBow for his help coming up with a clever way to grep openssl to determine valid base64 passwords or invalid plaintext passwords!
- ADDED: Included the current model/firmware/build in the instructions.txt file, including a warning not to restore your router from an older firmware/build or model type, or you may face possibly bricking your router. This info is now also shown within the setup menu, and is written to a routerfw.txt file located under each of your backup folders. This is to keep track what router model/firmware build each backup was taken with. When going through a restore, BACKUPMON will compare your router's current model/firmware/build and compare it to the model/firmware/build found in the backup folder's routerfw.txt file... if they match, it proceeds with an uninterrupted restore. If it notices a difference, it will give you explicit warnings not to proceed, and asks you whether or not you want to continue, but won't stop you from overwriting your router with an older configuration from a previous firmware. This is done at your own risk. I built this roadblock to prevent people from possibly unknowingly damaging their routers if they happen to restore an older firmware, or think they can restore a backup from an RT-AC86U to a GT-AX6000 (or the like).
- ADDED: Included a ping test in the backup target network connection tester functionality. Thought this would be a worthy add-on when troubleshooting getting your router talking to your backup target. Please note, your backup target must have capabilities of returning icmp/ping requests to show valid results, but this won't stop the testing process.

Beta Download Link:

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon-1.23b1.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

View attachment 53759

The encrypted password functionality works! I was able to revert to passwords using special characters that failed in the past.

 

[SomeWhereOverTheRainBow]

Many thanks goes to @SomeWhereOverTheRainBow for his help coming up with a clever way to grep openssl to determine valid base64 passwords or invalid plaintext passwords!

No worries! No one on team jaep was harmed in the production of this method.

 

[SomeWhereOverTheRainBow]

The encrypted password functionality works! I was able to revert to passwords using special characters that failed in the past.

I am glad it works .

 

[Martinski]

...

- CHANGED: Incorporated changes to the way passwords are being saved, now using the base64 method suggested by @PeterT and @ColinTaylor. Passwords are now encrypted via base64 and saved to your config file. PLEASE NOTE: this change will require you to go into your config, and resave your passwords into proper base64 encoding. ...

The encrypted password functionality works! ...

This post will probably sound pedantic to some readers, and I know it's fairly common for people to use the terms encryption & encoding interchangeably in everyday conversation, but as a s/w dev. who has worked with many encryption & encoding schemes in different projects over the years, and this being a technical forum, I should clarify that those terms are not interchangeable. For example, base64 is an encoding algorithm, not an encryption algorithm. This means that when base64 is used to transform a password string into another set of text chars, the password has been encoded, not encrypted.

In general terms, one of the primary differences is that to decrypt a previously encrypted text, you not only need to know the specific encryption algorithm used, but you must also have the specific secret key required for decryption. OTOH, to decode a previously encoded text no secret key is required; you only need to know the encoding scheme, which is normally publicly available.

 

[Viktor Jaep]

This post will probably sound pedantic to some readers, and I know it's fairly common for people to use the terms encryption & encoding interchangeably in everyday conversation, but as a s/w dev. who has worked with many encryption & encoding schemes in different projects over the years, and this being a technical forum, I should clarify that those terms are not interchangeable. For example, base64 is an encoding algorithm, not an encryption algorithm. This means that when base64 is used to transform a password string into another set of text chars, the password has been encoded, not encrypted.

In general terms, one of the primary differences is that to decrypt a previously encrypted text, you not only need to know the specific encryption algorithm used, but you must also have the specific secret key required for decryption. OTOH, to decode a previously encoded text no secret key is required; you only need to know the encoding scheme, which is normally publicly available.

How correct you are... seems I had used both interchangeably in my update above. Fixed!

 

[visortgw]

This post will probably sound pedantic to some readers, and I know it's fairly common for people to use the terms encryption & encoding interchangeably in everyday conversation, but as a s/w dev. who has worked with many encryption & encoding schemes in different projects over the years, and this being a technical forum, I should clarify that those terms are not interchangeable. For example, base64 is an encoding algorithm, not an encryption algorithm. This means that when base64 is used to transform a password string into another set of text chars, the password has been encoded, not encrypted.

In general terms, one of the primary differences is that to decrypt a previously encrypted text, you not only need to know the specific encryption algorithm used, but you must also have the specific secret key required for decryption. OTOH, to decode a previously encoded text no secret key is required; you only need to know the encoding scheme, which is normally publicly available.

Thanks. I stand corrected.