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

[Viktor Jaep]

I am happy that it works, too. Yes, it happens every time I choose to send a test mail. Moreover, you are actually correct. I also receive the "bad decrypt" error with a test email in AMTM.

 10. Edit SSL flag:       --insecure

Since this error most likely has to do with openssl... how about change that #10 to the default (which is blank). Right now it says "--insecure", which may be having an impact and giving you this error?

 

[Quoc Huynh]

Since this error most likely has to do with openssl... how about change that #10 to the default (which is blank). Right now it says "--insecure", which may be having an impact and giving you this error?

Thanks @Viktor Jaep. Unfortunately, the error still persists even when I leave the SSL flag to blank:

Common SMTP Server settings
 Provider    Server                 Port Protocol
 ------------------------------------------------
 Gmail       smtp.gmail.com         465  smtps
 mail.com    smtp.mail.com          587  smtp
 Yahoo!      smtp.mail.yahoo.com    465  smtps
 outlook.com smtp-mail.outlook.com  587  smtp

  1. Edit From address:   quocxxx@gmail.com
  2. Edit To name:        Quoc Huynh
  3. Edit To address:     quocxxx@gmail.com
  4. Edit Router name:    xxx
  5. Edit User name:      quocxxx@gmail.com
  6. Edit Password:       select Edit to view
  7. Edit SMTP Server:    smtp.gmail.com
  8. Edit Server port:    465
  9. Edit Protocol:       smtps
 10. Edit SSL flag:       Set to --insecure if curl problems occur
 11. Send testmail to confirm settings

 Enter your selection [1-11 e=Exit] 11
_____________________________________________

 This will send a testmail

 From: quocxxx@gmail.com
 To:   Quoc Huynh <quocxxx@gmail.com>

 1. Send testmail
 2. Send testmail, verbose output

 Enter your selection [1-2 e=Exit] 2

bad decrypt
4150263824:error:0606506D:lib(6):func(101):reason(109):NA:0:
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 172.217.194.109:465...
* Connected to smtp.gmail.com (172.217.194.109) port 465
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [6 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [4003 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [78 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*  subject: CN=smtp.gmail.com
*  start date: Jan 29 08:19:39 2024 GMT
*  expire date: Apr 22 08:19:38 2024 GMT
*  subjectAltName: host "smtp.gmail.com" matched cert's "smtp.gmail.com"
*  issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1C3
*  SSL certificate verify ok.
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [261 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [261 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
< 220 smtp.gmail.com ESMTP rs6-20020a17090b2b8600b00296fd5e0de1sm511212pjb.34 - gsmtp
} [5 bytes data]
> EHLO amtm-mail-body
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0{ [5 bytes data]
< 250-smtp.gmail.com at your service, [125.168.159.43]
< 250-SIZE 35882577
< 250-8BITMIME
< 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
< 250-ENHANCEDSTATUSCODES
< 250-PIPELINING
< 250-CHUNKING
< 250 SMTPUTF8
} [5 bytes data]
> AUTH PLAIN
{ [5 bytes data]
< 334
} [5 bytes data]
> AHF1b2NkdW5nM0BnbWFpbC5jb20AYWxjZW9zb2pzdGtlbmh0bw==
{ [5 bytes data]
< 235 2.7.0 Accepted
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0} [5 bytes data]
> MAIL FROM:<quocxxx@gmail.com> SIZE=265
{ [5 bytes data]
< 250 2.1.0 OK rs6-20020a17090b2b8600b00296fd5e0de1sm511212pjb.34 - gsmtp
} [5 bytes data]
> RCPT TO:<quocxxx@gmail.com>
{ [5 bytes data]
< 250 2.1.5 OK rs6-20020a17090b2b8600b00296fd5e0de1sm511212pjb.34 - gsmtp
} [5 bytes data]
> DATA
{ [5 bytes data]
< 354  Go ahead rs6-20020a17090b2b8600b00296fd5e0de1sm511212pjb.34 - gsmtp
  0   265    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0} [5 bytes data]
< 250 2.0.0 OK  1708124640 rs6-20020a17090b2b8600b00296fd5e0de1sm511212pjb.34 - gsmtp
104   265    0     0  104   277      0     77  0:00:03  0:00:03 --:--:--    77
* Connection #0 to host smtp.gmail.com left intact

 

[Viktor Jaep]

Thanks @Viktor Jaep. Unfortunately, the error still persists even when I leave the SSL flag to blank:

Darn. Well I'm at a loss... I'm sorry. Your settings and output look identical to mine, with the exception of that decrypt error at the very top. Perhaps @thelonelycoder has seen this one before?

 

[Quoc Huynh]

Darn. Well I'm at a loss... I'm sorry. Your settings and output look identical to mine, with the exception of that decrypt error at the very top. Perhaps @thelonelycoder has seen this one before?

Thanks @Viktor Jaep. Do not worry, the email notification still works like a charm. I may just leave it there and go ahead

 

[ExtremeFiretop]

You could still continue backing up to your USB drive, but you would just need to be sure to add the necessary exclusions so that your backups don't back up your existing backups, and start taking longer and longer exponentially.

Serious question. Sorry if this was asked already.
is there a reason that the path I specify in BACKUPMON under option 7 is not automatically added to the exclusions if it's a USB backup?

Is there anyone that has an actual valid use-case of backing up backups in a circular growing loop every night? If so, no worries we can add exclusions ourselves.
Just curious why it's not done automatically, seems logical to do something like: "if SOURCE USB (Option 1) and BACKUP TARGET USB (Option 6) paths match, automatically add the backup target path (Option 7) to the exclusions file. (Option 8)"

That way you completely eliminate the possibility of this being misconfigured.

 

[visortgw]

Serious question. Sorry if this was asked already.
is there a reason that the path I specify in BACKUPMON under option 7 is not automatically added to the exclusions if it's a USB backup?

Is there anyone that has an actual valid use-case of backing up backups in a circular growing loop every night? If so, no worries we can add exclusions ourselves.
Just curious why it's not done automatically, seems logical to do something like: "if SOURCE USB (Option 1) and BACKUP TARGET USB (Option 6) paths match, automatically add the backup target path (Option 7) to the exclusions file. (Option 8)"

View attachment 56534

View attachment 56536

That way you completely eliminate the possibility of this being misconfigured.

Because it is generally assumed that you would not define both source and destination as the same USB device. The suggestion was made that if you wish to do this, you may need to add some items to your exclusions list.

 

[ExtremeFiretop]

Because it is generally assumed that you would not define both source and destination as the same USB device. The suggesstion was made that if you wish to do this, you may need to add some items to your exclusions list.

You could potentially only have one USB device, and formatted with one partition.

You'd still get the backups of the nvram and JFFs, etc as you'd expect. But then you have to add the exclusion yourself which could be handled automatically.
I just ran a test based on how I figured he had it configured, and it seems it could potentially happen and can be avoided with a bit of simple logic at first time setup.

 

[visortgw]

You could potentially only have one USB device, and formatted with one partition.

You'd still get the backups of the nvram and JFFs, etc as you'd expect. But then you have to add the exclusion yourself which could be handled automatically.
I just ran a test based on how I figured he had it configured, and it seems it could potentially happen and can be avoided with a bit of simple logic at first time setup.

Yes, you could, but that is not an optimal configuration for backup — if the drive fails, you lose the backup as well as the source.

 

[ExtremeFiretop]

Yes, you could, but that is not an optimal configuration for backup — if the drive fails, you lose the backup as well as the source.

Agreed Not saying it's not. Just suggestions for improving the USB functionality for new users at first time setup.

Idea is so they aren't caught off guard if this is how they decided to proceed with backups, and weren't expecting the USB to fill so quickly (or take so long!).
Of course, in a perfect world they would not only use 2 USBs (or a network location) but configure the exclusions themselves, but to avoid hand holding it, could be done automatically and avoid all together.

 

[Viktor Jaep]

Agreed Not saying it's not. Just suggestions for improving the USB functionality for new users at first time setup.

Idea is so they aren't caught off guard if this is how they decided to proceed with backups, and weren't expecting the USB to fill so quickly.
Of course, in a perfect world they would not only use 2 USBs (or a network location) but configure the exclusions themselves, but to avoid hand holding it, could be done automatically and avoid all together.

Where's all the fun in learning, hitting a wall ("WTF did my backups stopped working!?"), identifying a problem ("WTF is my USB drive full!?"), and trying to figure out a solution in all that ("Ohhh maybe I should read the instructions - hey look there, an exclusion file will solve my issue")!!

From the -OP-

NOTE: If you do go down the path of backing your USB drive to your USB drive, it's possible, not recommended. If you accept this risk, you want to also make sure you exclude your backup folder name in the exclusion file, so you don't back up your backup folder, which will lead to exponential growth of your backup files. The safest way still is to store backups is far away from the device being backed up... so use at your own risk.

---

When people run backups against their backups... they should also be seeing a tar warning message stating that "filename.tar.gz is already part of the backup and skipping it" or something like it... hopefully that would throw up some red flags.

But I would agree with you, @ExtremeFiretop ... perhaps grepping to see if that path exists in the exclusion file, and if it doesn't, throw up a warning (along with the other adequate warnings on why it's a bad, bad idea to backup to your one and only local USB drive, and ask for input to see if they want to have backupmon add the exclusion in for them. Thanks for the idea!

 

[ExtremeFiretop]

Where's all the fun in learning, hitting a wall ("WTF did my backups stopped working!?"), identifying a problem ("WTF is my USB drive full!?"), and trying to figure out a solution in all that ("Ohhh maybe I should read the instructions - hey look there, an exclusion file will solve my issue")!!

From the -OP-

NOTE: If you do go down the path of backing your USB drive to your USB drive, it's possible, not recommended. If you accept this risk, you want to also make sure you exclude your backup folder name in the exclusion file, so you don't back up your backup folder, which will lead to exponential growth of your backup files. The safest way still is to store backups is far away from the device being backed up... so use at your own risk.

---

When people run backups against their backups... they should also be seeing a tar warning message stating that "filename.tar.gz is already part of the backup and skipping it" or something like it... hopefully that would throw up some red flags.

But I would agree with you, @ExtremeFiretop ... perhaps grepping to see if that path exists in the exclusion file, and if it doesn't, throw up a warning (along with the other adequate warnings on why it's a bad, bad idea to backup to your one and only local USB drive, and ask for input to see if they want to have backupmon add the exclusion in for them. Thanks for the idea!

Yeah a warning would work too! I saw the OP, I usually run with 2 USBs which is why my USB is called USB1, I just unplugged one for the test, and I saw the tar warnings when running my test, but that's not very clear. Something in human readable format would be more user friendly.

That's really all we are discussing, is increasing the user friendliness for first time users at setup. I realized the exclusions existed from the start, was just curious how this happened.

We do automate the exclusion of the swap file, why not the target path?

 

[Viktor Jaep]

Yeah a warning would work too! I saw the OP, I usually run with 2 USBs which is why my USB is called USB1, I just unplugged one for the test, and I saw the tar warnings when running my test, but that's not very clear. Something in human readable format would be more user friendly.

That's really all we are discussing, is increasing the user friendliness for first time users at setup. I realized the exclusions existed from the start, was just curious how this happened.

We do automate the exclusion of the swap file, why not the target path?

No, I totally agree with you... this could definitely help make sure someone doesn't go down the wrong path, and assume everything is working as it should. Great idea!

 

[ExtremeFiretop]

@Viktor Jaep

Did I give you an offer you couldn't refuse?
(Sorry little inside joke.)

 

[Viktor Jaep]

@Viktor Jaep

Did I give you an offer you couldn't refuse?
(Sorry little inside joke.)

<just keeping my head down in the code>

 

[Viktor Jaep]

Some new fresh mods with many thanks to @ExtremeFiretop for the suggestions! Enjoy!

What's new?
v1.5.6 - (February 18, 2024)
- PATCH: Thanks for @ExtremeFiretop's suggestion to provide guidance and automation to exclude the backup folder if EXT USB backups are backing up to the same EXT USB. Knowing that his is a risky scenario, should your EXT USB fail, you will lose all your backups in the process. Also, if your backup folder is not being excluded in the TAR exclusion file, your previous backups will be backed up each time, exponentially increasing their size and the time it takes to back them up. Warnings will now also be displayed on screen and in the logs indicating this risk, and whether or not the backup folder is being excluded. When choosing a source or target path, or backup folder path, BACKUPMON will evaluate whether or not your backup folder needs to be excluded, giving ample language describing the issue and allowing you to automatically add the exclusion.
- PATCH: Moved and added some items around on the setup menu, including now the ability to edit your primary and secondary exclusion files (options: 'ep' and 'es'). Performing this action will launch your exclusion files with the NANO text editor, allowing you to free-form edit any items you wish to add, delete or modify. Remember to save: CTRL-O + enter. To exit: CTRL-X.
- PATCH: Minor fixes around the secondary backup setup screen, to add some logic to prompt for a mount point should the backup media type change from USB to Network or vice versa.

Download link (or update directly within AMTM/BACKUPMON):

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

Significant screenshots:

Setup menu has been modified a bit, and moved 2 new items (TAR Exclusion File editing) into it.

When choosing a target media type of USB with a similar source and target mount point, you will get a warning message as the one below. Selecting 'yes' will automatically add your target folder to the TAR exclusion file.

This shows the visual warning that you are backing up from your EXT USB drive to itself, and lets you know if an exclusion is in place that would be preventing your backups from being backed up, which could cause significant backup sizes and time to take backups.

 

[Quoc Huynh]

Thank you @Viktor Jaep for the update. By the way, I think there is some typo here. Cheers.

 

[Viktor Jaep]

Thank you @Viktor Jaep for the update. By the way, I think there is some typo here. Cheers.

View attachment 56567

Thanks @Quoc Huynh... I can't stand typos. It's been fixed... please download over your same version and it will fix that. Thanks for finding this!

 

[ExtremeFiretop]

Thanks @Quoc Huynh... I can't stand typos. It's been fixed... please download over your same version and it will fix that. Thanks for finding this!

Nice work on the quick fix, and with the quick turnaround with this suggestion @Viktor Jaep !

 

[Quoc Huynh]

Thanks @Quoc Huynh... I can't stand typos. It's been fixed... please download over your same version and it will fix that. Thanks for finding this!

You’re welcome It would actually be harder for you to catch typos, particularly when coding and typing explanation at the same time.

 

[Viktor Jaep]

Hi everyone... I pushed a minor change through this morning... something didn't sit well with me with the menu layout... Please update from within AMTM and download the same version 1.5.6...

It now separates the "testing" items from the rest of the "backup operations" items. Ahhh much more organized!