What's new

BACKUPMON BACKUPMON v1.10.0 [2026-Apr-19] - Backup/Restore your Router: JFFS + NVRAM + External USB Drive! Encrypt/CIFS/SMB/NFS! (Available in AMTM!)

@Ripshod... please let me know what you think of this addendum to the instructions.txt file:

Code:
RESTORE INSTRUCTIONS

IMPORTANT:
Asus Router Model: RT-AX88U
Firmware/Build Number: 3004.388.11_0
EXT USB Drive Label Name: SANDISK

WARNING: Do NOT attempt to restore if your Asus Router Model or Firmware/Build Numbers differ from your backups!

Please ensure your have performed the following before restoring your backups:
1.) Enable SSH in router UI, and connect via an SSH Terminal (like PuTTY).
2.) Run "AMTM" and format a new USB drive on your router - label it exactly the same name as before (see above)! Reboot.
3.) After reboot, SSH back in to AMTM, create your swap file (if required). This action should automatically enable JFFS.
4.) From the UI, verify JFFS scripting enabled in the router OS, if not, enable and perform another reboot.
5.) Restore the backupmon.sh & backupmon.cfg files (located under your backup folder) into your /jffs/scripts folder.
6.) Run "sh backupmon.sh -setup" and ensure that all of the settings are correct before running a restore.
7.) Run "sh backupmon.sh -restore", pick which backup you want to restore, and confirm before proceeding!
8.) After the restore finishes, a forced reboot occurs. Everything should be restored as normal!

**NOTE** FOR THOSE USING THE ENCRYPTED BACKUP OPTION:
1.) Follow the same steps as listed above.
2.) Ensure all encrypted (.enc) files (NVRAM, JFFS, EXT Backup and symkey.enc) are in their original backup location.
3.) Do not generate a new Public/Private Key Pair. These are stored in your backupmon.cfg file.
4.) During the restore, you will be prompted for your Private Key password. Do not lose this.
 
Quick update to BACKUPMON v1.10.0b14 that addresses the issue @Ripshod was mentioning above:

- PATCH: Per suggestion from @Ripshod, firmed up the language in the instructions.txt file to address encrypted backup restores. Also, firmed up some of the language and logic around unsuccessful restores due to missing files, or wrong Private Key passwords.

Download Link (BETA) v1.10.0b14
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/develop/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

Download Link (STABLE/RELEASE) v1.9.1
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/main/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"
 
Quick update to BACKUPMON v1.10.0b16 that addresses the issue @Ripshod was mentioning above, as well as a great suggestion from @Radon :

- PATCH: Per suggestion from @Ripshod, firmed up the language in the instructions.txt file to address encrypted backup restores. Also, firmed up some of the language and logic around unsuccessful restores due to missing files, or wrong Private Key passwords.
- PATCH: Per suggestion from @Radon, added the total backup disk space consumed under the specified backup folder location in the on-screen status messaging and the log, now showing something like "INFO: Total Backup Space Consumed: 4.05GB". Additionally, added more backup space stats before and after a purge, showing total space reclaimed.

Download Link (BETA) v1.10.0b16
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/develop/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

Download Link (RELEASE) v1.9.1
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/main/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

Screenshot:

Now showing total backup space consumed under your backup folder structure:

1776618669989.png
 
Last edited:
@Ripshod... please let me know what you think of this addendum to the instructions.txt file:

Code:
RESTORE INSTRUCTIONS

IMPORTANT:
Asus Router Model: RT-AX88U
Firmware/Build Number: 3004.388.11_0
EXT USB Drive Label Name: SANDISK

WARNING: Do NOT attempt to restore if your Asus Router Model or Firmware/Build Numbers differ from your backups!

Please ensure your have performed the following before restoring your backups:
1.) Enable SSH in router UI, and connect via an SSH Terminal (like PuTTY).
2.) Run "AMTM" and format a new USB drive on your router - label it exactly the same name as before (see above)! Reboot.
3.) After reboot, SSH back in to AMTM, create your swap file (if required). This action should automatically enable JFFS.
4.) From the UI, verify JFFS scripting enabled in the router OS, if not, enable and perform another reboot.
5.) Restore the backupmon.sh & backupmon.cfg files (located under your backup folder) into your /jffs/scripts folder.
6.) Run "sh backupmon.sh -setup" and ensure that all of the settings are correct before running a restore.
7.) Run "sh backupmon.sh -restore", pick which backup you want to restore, and confirm before proceeding!
8.) After the restore finishes, a forced reboot occurs. Everything should be restored as normal!

**NOTE** FOR THOSE USING THE ENCRYPTED BACKUP OPTION:
1.) Follow the same steps as listed above.
2.) Ensure all encrypted (.enc) files (NVRAM, JFFS, EXT Backup and symkey.enc) are in their original backup location.
3.) Do not generate a new Public/Private Key Pair. These are stored in your backupmon.cfg file.
4.) During the restore, you will be prompted for your Private Key password. Do not lose this.
I think that has it covered. Good work 😎
 
Let's make this happen! BACKUPMON v1.10.0 out now! Huge additions made to BACKUPMON's functionality this time around, introducing the ability to encrypt your backups, with many thanks to @salvo for his push in that direction. This was an absolute joy to bring these capabilities into the script, and right up my alley. Also some cool late additions thanks to @Radon to include stats about backup space currently being consumed. Really glad to see BACKUPMON continue to grow in different directions! Enjoy!

What's new!?
v1.10.0 - (April 19, 2026)
- MINOR:
Added the ability to apply enterprise-strength encryption to your primary and secondary backup sets. Huge thanks to @salvo for the encouragement, and lighting a fire under me. This was a fun exercise. ;) New item under the main setup and operations menu, using option (en)cryption. Complete sub-menu that allows you to configure your encryption options for both your primary and secondary backups, as well as choosing between the AES-256 and AES-128 ciphers. The latter is still a very strong and secure encryption, but may perform better on older devices, or larger backup sets. Major rework had to be done to ensure integrity can still be checked, now needing to decrypt before checking for this.
- PATCH: Reworked the encryption methodology after some suggestions from @salvo. BACKUPMON no longer saves your master password in the config file, but uses a combination of a salt, hash and nonce file to uniquely encrypt each backup. You will now see a unique enc.nonce file being written along with your backups that is used to decrypt your backups when needed. Don't delete these!
- PATCH: Reworked the encryption methodology a 3rd time after some discussion with @rung, and replaced the salt/hash/nonce method in favor of using PKI RSA-4096/AES-256-CBC (public/private key pairs). These key pairs are located in the backupmon.cfg for ease of use and encryption/decryption purposes. Your private key is encrypted with a Master Password that you must know to successfully decrypt any file.
- PATCH: Added functionality to the main setup and operations menu that allows for the selection and decryption of a single file in a location of your choosing. This option is available using (de)crypt, and will prompt you through a successful file decryption.
- PATCH: Various bugfixes, wording changes and cleanup!
- PATCH: Added "unset LD_LIBRARY_PATH" statement due to the latest Entware binaries using the RUNPATH embedded library search path mechanism instead of the previous RPATH method. RUNPATH is searched *AFTER* the LD_LIBRARY_PATH definitions, whereas RPATH has higher priority than the LD_LIBRARY_PATH environment variable, so it's searched FIRST. Thanks to @Martinski for his advice.
- PATCH: Made BACKUPMON compliant with the amtmupdate functionality to allow for autoupdates through AMTM.
- PATCH: Per suggestion from @visortgw, removed the functionality that doesn't allow you to set up encryption on the Secondary backup if the Secondary backup is currently disabled. This feature will also not automatically remove any previously set Public/Private keys if it sees that the Secondary backups are disabled, and leaves them in place unless you specifically disable the Secondary backup encryption settings.
- PATCH: Per suggestion from @Ripshod, firmed up the language in the instructions.txt file to address encrypted backup restores. Also, firmed up some of the language and logic around unsuccessful restores due to missing files, or wrong Private Key passwords.
- PATCH: Per suggestion from @Radon, added the total backup disk space consumed under the specified backup folder location in the on-screen status messaging and the log, now showing something like "INFO: Total Backup Space Consumed: 4.05GB". Additionally, added more backup space stats before and after a purge, showing total space reclaimed.

Download link (or update directly within AMTM or BACKUPMON):
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:

Encryption showing on default backup:
1776636581988.png


(en) Encryption Configuration Menu added, as well as the (de) Decrypt single backup file item:
1776636401564.png


New Backup Encryption Configuration menu allowing you to set your preferences for both the primary and secondary backups:
1776636460467.png


New messaging indicating Total Backup Space Consumed, as well as additional stats after a purge completes (this has actually changed a bit more, but didn't have any further backups to purge, so it wasn't able to be shown... but it shortens the messaging a bit, and also specifies whether the space it's referring to is primary or secondary backup space):
1776636500362.png
 
Last edited:
- MINOR: Added the ability to apply enterprise-strength encryption to your primary and secondary backup sets.
Surely this cannot be classified as a minor update? 😎
 
Surely this cannot be classified as a minor update? 😎
I know. This major.minor.patch scheme sometimes doesn't seem fair. Else we'd be on BACKUPMON v12.9.1 at this point. Lol
 
What's new!?
v1.10.0 - (April 19, 2026)

...
- PATCH: Reworked the encryption methodology a 3rd time after some discussion with @rung, and replaced the salt/hash/nonce method in favor of using PKI RSA-4096/AES-256-CBC (public/private key pairs).
Given that in some routers, generating 4096-bit RSA keys may take between 30 and 60 seconds, have you considered giving users the option to select Elliptic Curve Cryptography (ECC) keys?

Generating ECC keys is much more efficient and extremely fast when compared to generating RSA keys, and the security strength of a 256-bit ECC key is considered at least equivalent to a 3072-bit RSA key, which, in today's standards, is very secure. ECC keys are used in blockchain, cryptocurrency technologies, and in messaging apps like Signal and WhatsApp, so their security is well established and tested.

Here are a couple of screenshots using my old RT-AC86U test router to compare the time it took to generate some 256-bit ECC keys (prime256v1 and secp256k1) vs a 4096-bit RSA key. Essentially, ECC keys are generated instantly, every single time.

OpenSSL_Generate_RSA_Keys.jpg


OpenSSL_Generate_ECC_Keys.jpg


Just my 2 cents.
 
Given that in some routers, generating 4096-bit RSA keys may take between 30 and 60 seconds

Personally, I like giving my computers tough problems to solve. You don't want to go easy on them too often - they'll go soft.
 
Personally, I like giving my computers tough problems to solve. You don't want to go easy on them too often - they'll go soft.
🤣😂
 
Given that in some routers, generating 4096-bit RSA keys may take between 30 and 60 seconds, have you considered giving users the option to select Elliptic Curve Cryptography (ECC) keys?

Generating ECC keys is much more efficient and extremely fast when compared to generating RSA keys, and the security strength of a 256-bit ECC key is considered at least equivalent to a 3072-bit RSA key, which, in today's standards, is very secure. ECC keys are used in blockchain, cryptocurrency technologies, and in messaging apps like Signal and WhatsApp, so their security is well established and tested.

Here are a couple of screenshots using my old RT-AC86U test router to compare the time it took to generate some 256-bit ECC keys (prime256v1 and secp256k1) vs a 4096-bit RSA key. Essentially, ECC keys are generated instantly, every single time.

View attachment 71372

View attachment 71373

Just my 2 cents.
I like the idea, @Martinski... but even though it warns you that it could take 30-60sec, I've only seen it take a few seconds max. Even on that old RT-AC86U of yours, 7 seconds isn't bad. We must be talking about some seriously old routers if it takes more than a few seconds.

Since it's pretty much a set it (once) and forget it, I don't think it is too much to ask for. But if the complaints start rolling in, I'll be ready. 😋
 

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!

Members online

Back
Top