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

[vibroverbus]

There's several ways... You could notice by poking through your backups on occasion that they weren't complete... or just scrolling through the log and finding anything that begins with "ERROR"... or when manually running a backup, you would see a big red error in the middle of the backup output... but what would really help here is by enabling AMTM email. You would have been notified the first time it happened.

Thanks Viktor. In re: your 3 ways...

1. Look at log file

Please notice I just told you I did that and it worked great.

Perhaps my 'could' got misread, I very much DID find the error in the log once I realized something was amiss

of course I could find the error in the log...

2. Look at the screen

Yes, this is what I'm posting about - just trying to suggest a quick tweak too...
Yes its in big red text but its only there for a few seconds, it goes away instantly and then clears the screen.
If like me and you're working away in other screens at the time and glance away - you think its fine but it wasn't.

Its not a big deal, just 'would be nice' if you trapped for errors in the manual interactive code to stick a pause there.

as you backup doesn't trap for error and then pause... so if there's an error it flashes by (and if you're paged away or looking elsewhere you miss it)

3. emails

Yeah, OK but it'd be nice when you're doing manual interactive to actually know there was an error and be able to read it instead of missing it entirely or (as happened on my 2nd or 3rd runs) "hey wait theres a red error message what does it say O.F. no now its gone again... OK go look at the log..."

 

[Viktor Jaep]

Thanks Viktor. In re: your 3 ways...

1. Look at log file

Please notice I just told you I did that and it worked great.

Perhaps my 'could' got misread, I very much DID find the error in the log once I realized something was amiss



2. Look at the screen

Yes, this is what I'm posting about - just trying to suggest a quick tweak too...
Yes its in big red text but its only there for a few seconds, it goes away instantly and then clears the screen.
If like me and you're working away in other screens at the time and glance away - you think its fine but it wasn't.

Its not a big deal, just 'would be nice' if you trapped for errors in the manual interactive code to stick a pause there.



3. emails

Yeah, OK but it'd be nice when you're doing manual interactive to actually know there was an error and be able to read it instead of missing it entirely or (as happened on my 2nd or 3rd runs) "hey wait theres a red error message what does it say O.F. no now its gone again... OK go look at the log..."

I do like where you're going with this. I can build something that shows that "errors were encountered during the last backup" or something. Thanks! I'd prefer not to interrupt the script if an issue comes up.

 

[visortgw]

I do like where you're going with this. I can build something that shows that "errors were encountered during the last backup" or something. Thanks! I'd prefer not to interrupt the script if an issue comes up.

Or, history of errors, creating unique file each time error(s) are encountered. Yes, I do use the e-mail option which helps immensely.

 

[Viktor Jaep]

Great ideas! I'm running with it.

 

[vibroverbus]

I do like where you're going with this. I can build something that shows that "errors were encountered during the last backup" or something. Thanks! I'd prefer not to interrupt the script if an issue comes up.

Yeah so if the script closes but then there's an alert on the main menu screen when it returns... totally works. Then you know to check logs etc. .

 

[Wendigogo]

OMG... I forgot to include that in my copy & paste... Thanks @ColinTaylor!

Is there a chance it could also be forgotten in Backupmon (1.7.2)?

I got an issue with my external drive. Here is the log:

Jun 04 2024 15:29:08 RT-AX88U-B540 BACKUPMON[3867] - INFO: Starting backup of EXT Drive on Tue Jun  4 15:29:08 CEST 2024
24 Jun 04 2024 15:29:08 RT-AX88U-B540 BACKUPMON[386bm7] - **ERROR**: Errors detected creating EXT Drive tar file.

And if I'm using your line

tar -zcf /tmp/mnt/backups/router/AX88U-Backup/usbdrive-test.tar.gz -C /tmp/mnt/4Go .

it works flawlessly.

Enjoy!

 

[Viktor Jaep]

Is there a chance it could also be forgotten in Backupmon (1.7.2)?

I got an issue with my external drive. Here is the log:

Jun 04 2024 15:29:08 RT-AX88U-B540 BACKUPMON[3867] - INFO: Starting backup of EXT Drive on Tue Jun  4 15:29:08 CEST 2024
24 Jun 04 2024 15:29:08 RT-AX88U-B540 BACKUPMON[386bm7] - **ERROR**: Errors detected creating EXT Drive tar file.

And if I'm using your line

tar -zcf /tmp/mnt/backups/router/AX88U-Backup/usbdrive-test.tar.gz -C /tmp/mnt/4Go .

it works flawlessly.

Enjoy!

Looks like it bombs out right away. Sounds like a path issue. I double-checked all tar commands, and they check out. Could you please share what your backupmon configuration screen looks like, so we can compare apples to apples?

 

[Wendigogo]

Looks like it bombs out right away. Sounds like a path issue. I double-checked all tar commands, and they check out. Could you please share what your backupmon configuration screen looks like, so we can compare apples to apples?

My bad, I managed to solve this issue while grabbing a screenshot of the encountered error :

It's waaaay more explicit than the log :

Jun 05 2024 09:28:01 RT-AX88U-B540 BACKUPMON[2721] - INFO: Starting backup of EXT Drive on Wed Jun  5 09:28:01 CEST 2024
53 Jun 05 2024 09:28:01 RT-AX88U-B540 BACKUPMON[2721] - **ERROR**: Errors detected creating EXT Drive tar file.

Using an existing source path is a good thing for sure.

And it could be a good option to use "2>&1" to grab stderr and stdout into logs. But it may fill it with a lot of stuff if tar is verbose…

Enjoy!

 

[Viktor Jaep]

My bad, I managed to solve this issue while grabbing a screenshot of the encountered error :

Glad you resolved it!

It's waaaay more explicit than the log :

Jun 05 2024 09:28:01 RT-AX88U-B540 BACKUPMON[2721] - INFO: Starting backup of EXT Drive on Wed Jun  5 09:28:01 CEST 2024
53 Jun 05 2024 09:28:01 RT-AX88U-B540 BACKUPMON[2721] - **ERROR**: Errors detected creating EXT Drive tar file.

This is the reason I've kept verbose logging on for TAR, so it would show stuff like this. RTRMON just tells you what happened in its logs, because I'm just capturing the error state after something runs. Hopefully after seeing errors in the logs, or getting an email about it, that would be enough to go on for the person to try running it manually and looking at the TAR errors on screen to get a better idea of why its complaining.

Also, this stuff would come to light when running it in the "Test your network backup target" item under the setup/configuration menu.

 

[vibroverbus]

My bad, I managed to solve this issue while grabbing a screenshot of the encountered error :

It's waaaay more explicit than the log :

Jun 05 2024 09:28:01 RT-AX88U-B540 BACKUPMON[2721] - INFO: Starting backup of EXT Drive on Wed Jun  5 09:28:01 CEST 2024
53 Jun 05 2024 09:28:01 RT-AX88U-B540 BACKUPMON[2721] - **ERROR**: Errors detected creating EXT Drive tar file.

Using an existing source path is a good thing for sure.

And it could be a good option to use "2>&1" to grab stderr and stdout into logs. But it may fill it with a lot of stuff if tar is verbose…

Yeah this is exactly what I was saying about the error screen blasting past when there's an error...

My thoughts are:
1. Agree grab the stderr/stdout so that same message appears in logs
2. I still would like a 'pause' WHEN running manually. I totally understand Viktor why you might not want a hard pause in the script (haven't looked at your source but I assume you call the same script file(s) for both interactive and scheduled?) but maybe you can pass an argument that is 'interactive vs unattended' and then there's a "press any key to continue" if its in manual/interactive mode?

 

[Viktor Jaep]

Yeah this is exactly what I was saying about the error screen blasting past when there's an error...

My thoughts are:
1. Agree grab the stderr/stdout so that same message appears in logs
2. I still would like a 'pause' WHEN running manually. I totally understand Viktor why you might not want a hard pause in the script (haven't looked at your source but I assume you call the same script file(s) for both interactive and scheduled?) but maybe you can pass an argument that is 'interactive vs unattended' and then there's a "press any key to continue" if its in manual/interactive mode?

I will need to do some thinking on this one... Because here's a scenario: On my backups, tar explicitly complains that it can't back up 5 individual screen-related temp files because they're locked. Having a feature like this would want me to pull my hair out if I had to get interrupted 5x each time I do a backup.

This is why I rely heavily on email so I can dig deeper if needed. But if your environment is stable, errors are extremely few and far between.

I'll see what I can do to include these tar errors in the error log.

 

[visortgw]

I will need to do some thinking on this one... Because here's a scenario: On my backups, tar explicitly complains that it can't back up 5 individual screen-related temp files because they're locked. Having a feature like this would want me to pull my hair out if I had to get interrupted 5x each time I do a backup.

This is why I rely heavily on email so I can dig deeper if needed. But if your environment is stable, errors are extremely few and far between.

I'll see what I can do to include these tar errors in the error log.

In your scenario, is it possible to genericize the five (5) screen-related files so that they could be added to the exclude file, further reducing known warnings/errors?

 

[vibroverbus]

I will need to do some thinking on this one... Because here's a scenario: On my backups, tar explicitly complains that it can't back up 5 individual screen-related temp files because they're locked. Having a feature like this would want me to pull my hair out if I had to get interrupted 5x each time I do a backup.

I'll see what I can do to include these tar errors in the error log.

Oh yeah I DEFINITELY wouldn't have it pause on each error... just pause before the return to the menu so you can review the total screen.

I would just add up the returns as you go then if $SUMERR > 0, echo "Damn son check this out there's an error", read, etc. etc.

 

[Wendigogo]

Interesting points of view here.

Maybe grabbing only sdterr into logs.
Or in each part of the backup process, grabbing stderr/stdout in a temp file (in ram) and add it in log file only if there's an error.

My 0.02 cents.

 

[Viktor Jaep]

Here comes a new beta your way with some of these stderr logging features being requested by @vibroverbus and @Wendigogo ... give me your thoughts!

What's new?
v1.7.4b1- (TBA)
- PATCH: Some logging additions being made based on feedback from @vibroverbus and @Wendigogo. Now, BACKUPMON will redirect any stderr error-specific messages into a separate "error log". This log is viewable from the setup/configuration menu using the command "(ve)". It will basically dump any tar-related warnings or any other errors into this log, in addition to the error messages that BACKUPMON generates.
- PATCH: Should any sort of error occur, you will get visual feedback in various locations: (1) When manually running a backup job from the menu, it will display the warning that an error occurred and will ask for a keypress to continue. (2) When automatedly running, it will include a warning at the end of the job to let you know something occurred. (3) When opening BACKUPMON to the setup/configuration menu, it will display that an error occurred during the last backup, and to take a look at the error log.

v1.7.4 BETA1 download link (execute from SSH client):

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

v1.7.2 Stable download link (or download through BACKUPMON/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:

When running an automated backup (or scheduled backup), or using the command "sh /jffs/scripts/backupmon.sh", or just "backupmon", or "sh backupmon.sh -backup" a message appears at the end of the backup to inform you that an error happened:

When running a manual (bk) backup from the setup/config menu, it will prompt for a key-press after displaying the warning that an error happened:

If you didn't happen to catch an error, or do not have AMTM email setup to catch things like this, a visual warning appears next time you open the setup/configuration menu:

The error log will show all relevant stderr errors that are captured through TAR or other means. BACKUPMON will also insert its own errors here as well to paint a complete picture of the events

 

[visortgw]

Here comes a new beta your way with some of these stderr logging features being requested by @vibroverbus and @Wendigogo ... give me your thoughts!

What's new?
v1.7.4b1- (TBA)
- PATCH: Some logging additions being made based on feedback from @vibroverbus and @Wendigogo. Now, BACKUPMON will redirect any stderr error-specific messages into a separate "error log". This log is viewable from the setup/configuration menu using the command "(ve)". It will basically dump any tar-related warnings or any other errors into this log, in addition to the error messages that BACKUPMON generates.
- PATCH: Should any sort of error occur, you will get visual feedback in various locations: (1) When manually running a backup job from the menu, it will display the warning that an error occurred and will ask for a keypress to continue. (2) When automatedly running, it will include a warning at the end of the job to let you know something occurred. (3) When opening BACKUPMON to the setup/configuration menu, it will display that an error occurred during the last backup, and to take a look at the error log.

v1.7.4 BETA1 download link (execute from SSH client):

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

v1.7.2 Stable download link (or download through BACKUPMON/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:

When running an automated backup (or scheduled backup), or using the command "sh /jffs/scripts/backupmon.sh", or just "backupmon", or "sh backupmon.sh -backup" a message appears at the end of the backup to inform you that an error happened:
View attachment 59241

When running a manual (bk) backup from the setup/config menu, it will prompt for a key-press after displaying the warning that an error happened:
View attachment 59242

If you didn't happen to catch an error, or do not have AMTM email setup to catch things like this, a visual warning appears next time you open the setup/configuration menu:
View attachment 59245

The error log will show all relevant stderr errors that are captured through TAR or other means. BACKUPMON will also insert its own errors here as well to paint a complete picture of the events
View attachment 59244

If email notifications are enabled for automatic backups, will the error details be included in the email message?

 

[Viktor Jaep]

If email notifications are enabled for automatic backups, will the error details be included in the email message?

No... just the general error that was detected by backupmon... You have do so *SOME* work to see what the error was! Can't make it too easy! LOL

 

[vibroverbus]

Here comes a new beta your way with some of these stderr logging features being requested by @vibroverbus and @Wendigogo ... give me your thoughts!

Absolute perfection sir. EVEN better than I could have suggested.

 

[Viktor Jaep]

My bad, I managed to solve this issue while grabbing a screenshot of the encountered error :
View attachment 59221

It's waaaay more explicit than the log :

Jun 05 2024 09:28:01 RT-AX88U-B540 BACKUPMON[2721] - INFO: Starting backup of EXT Drive on Wed Jun  5 09:28:01 CEST 2024
53 Jun 05 2024 09:28:01 RT-AX88U-B540 BACKUPMON[2721] - **ERROR**: Errors detected creating EXT Drive tar file.

Using an existing source path is a good thing for sure.

And it could be a good option to use "2>&1" to grab stderr and stdout into logs. But it may fill it with a lot of stuff if tar is verbose…

Enjoy!

So @Wendigogo ... if you can duplicate that tar error you were getting, and validate that BACKUPMON is functioning as it should when it comes to displaying error notifications and entries in the error log, then I will close this out and get it out the door...

 

[Viktor Jaep]

Actually... stand by. I found a flaw in the way that exit codes are being collected with all the error logging pipes tacked onto the tar command. This will take a bit of time to fix... give me a few.