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

[Viktor Jaep]

Strange, but it completes now, with AIprotection active and the exclusion removed.

tar -zvcf /tmp/mnt/UNCDRIVE/backupfolder/jffs.tar.gz -X /pathtoexlusionfile/file.txt -C /jffs .

Here's the command using an exclusion file...

 

[Ripshod]

My server's samba shares aren't mounted, so the file was saved locally. could that be why?

 

[Viktor Jaep]

My server's samba shares aren't mounted, so the file was saved locally. could that be why?

I would try to replicate the normal backup process as closely as you possibly can... mounting your network samba shares, running the command with the exclusion file (that both includes or doesn't include that TM exclusion), and using the 'v' verbose flag...

But I would have thought it would error out if it couldn't write to an unmounted drive.

 

[Ripshod]

But I would have thought it would error out if it couldn't write to an unmounted drive.

Without a drive actually mounted there's still a directory, and that gets written to.
I'm gonna leave it for now, it's giving me a headache lol

An Afterthought. When this error occurs backupmon just closes without attempting a secondary backup. Is that correct behaviour?

 

[Viktor Jaep]

Without a drive actually mounted there's still a directory, and that gets written to.
I'm gonna leave it for now, it's giving me a headache lol

I guess it would be writing it locally onto USB storage? Interesting. Yeah, I just wrote a test file to my unmounted primary backup mount that is currently unmounted. Wonder if those files will ever clear, or if they just hang there in the ether.

An Afterthought. When this error occurs backupmon just closes without attempting a secondary backup. Is that correct behaviour?

That's correct... if a significant error occurs, it quits entirely. The thought was, if something major is out of whack, to step back and let you investigate a cause before attempting another backup.

 

[Ripshod]

To fully replicate what I was experiencing I'm going to run AIprotection and Network Analyzer for a couple of days, just like when the problem first appeared. Catch up Tuesday.

 

[Implement3443]

Thanks for making this! Easy to set up and works flawlessly.

I'm new to ASUS Routers, so when Backupmon mentions it backups JFFS, will this include the settings set in the ASUS GUI such as SSID etc, basically making the backup function of settings in the GUI redundant or backupmon only includes a backup of all the setup done through AMTM?

Thanks!

 

[Viktor Jaep]

Thanks for making this! Easy to set up and works flawlessly.

I'm new to ASUS Routers, so when Backupmon mentions it backups JFFS, will this include the settings set in the ASUS GUI such as SSID etc, basically making the backup function of settings in the GUI redundant or backupmon only includes a backup of all the setup done through AMTM?

Thanks!

Yes, it backs up everything. JFFS typically include scripts whereas the NVRAM contains settings like SSID. The GUI is more manual but essentially the same process. The only thing the GUI doesn't do is also back up your external USB drive, which is essential, and typically holds your entware environment and other scripts/settings.

 

[Viktor Jaep]

Some small yet important fixes in this release as it pertains to the new 3006 firmware for our BE users out there! Enjoy!

What's new?
v1.8.7 - (June 29, 2024)
- PATCH: In further compliance with the 3006 firmware and the new BE devices, @visortgw wisely noted that a "modprobe cifs" might just fix everything... and it sure did. Thanks for that! As of BACKUPMON v1.8.7, you should have full CIFS functionality on the 3006 level firmware. Also, thanks to @RMerlin for adding the CIFS libraries back in and making BACKUPMON functional again.
- PATCH: In further troubleshooting BACKUPMON on 3006 with his beefy GT-BE98_Pro, @ExtremeFiretop came across a bug that allowed backups to run if the UNC path was blank, but the drive had been manually mounted in the background. BACKUPMON will now come to a halt if it finds UNC or UNCDRIVE values being blank. Thanks for the heads-up and the testing. A free bug bounty BACKUPMON swag shirt is on its way to you!! (LOL jk)

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

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;

Sadly, backups can no longer run if your UNC or UNCDRIVE values are blank. Sorry guys!

 

[Just Started]

Sadly, backups can no longer run if your UNC or UNCDRIVE values are blank. Sorry guys!

I'm backing up only to a flash drive that is plugged in directly to the router via USB. Backupmon was working for me until the latest update, now it fails as Viktor warned.

Newbie questions:

1. What value should I use for UNC, given that I'm not using a network drive?
2. Is editing backupmon.cfg the right way to set it?

I tried deleting the line UNC="" in backupmon.cfg, but that didn't solve the problem. I also tried putting in a dummy value for UNC, but that didn't change the error message either, even though it was no longer blank.

UNCDRIVE was already set to my USB drive mount point (like /tmp/mnt/Drive2_USB).

Thank you for any help!

 

[Viktor Jaep]

I'm backing up only to a flash drive that is plugged in directly to the router via USB. Backupmon was working for me until the latest update, now it fails as Viktor warned.

Newbie questions:

1. What value should I use for UNC, given that I'm not using a network drive?
2. Is editing backupmon.cfg the right way to set it?

I tried deleting the line UNC="" in backupmon.cfg, but that didn't solve the problem. I also tried putting in a dummy value for UNC, but that didn't change the error message either, even though it was no longer blank.

UNCDRIVE was already set to my USB drive mount point (like /tmp/mnt/Drive2_USB).

Thank you for any help!

Ah dang. Sorry... let me work on this.

 

[Viktor Jaep]

For those of you backing up your environment to your local USB drive, you will want to install this new version. Thanks to @Just Started for reporting this, and my sincere apologies for not considering what the v1.8.7 changes would do to this backup scenario. I just tested this and seems to be working. Please give it a go!

What's new?
v1.8.8 - (June 30, 2024)
- PATCH: Looks like my last update didn't take into consideration the folks using BACKUPMON to back up their environment to their local USB drive. Thanks much to @Just Started for reporting this! New logic added to only consider erroring out on blank UNC/UNCDRIVE values when the backup media type is NOT a USB target.

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

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

 

[Just Started]

Wow! Amazingly fast response!

I updated to v1.8.8, ran a manual backup, and it worked perfectly!

Thank you, Viktor!

 

[Viktor Jaep]

Wow! Amazingly fast response!

I updated to v1.8.8, ran a manual backup, and it worked perfectly!

Thank you, Viktor!

Absolutely. So sorry about that...

 

[visortgw]

Wow! Amazingly fast response!

I updated to v1.8.8, ran a manual backup, and it worked perfectly!

Thank you, Viktor!

Get used to it — that's the way that @Viktor Jaep rolls!

 

[vibroverbus]

Super minor feedback on the update input processing - the confirm [y/n] prompt for updates uses is a single keystroke read... thats not consistent with most amtm addon update procedures, so I tend to reflexively type "y" and "\n" so the \n gets blasted into the next prompt ("Do you want to restart") so I get skipped over the 2nd prompt. Not a huge deal, its just different than most updates which do a regular \n terminated read for the update confirmation.

 

[vibroverbus]

BTW just did full backup to USB attached drive and seems to have worked perfectly.

 

[Viktor Jaep]

Super minor feedback on the update input processing - the confirm [y/n] prompt for updates uses is a single keystroke read... thats not consistent with most amtm addon update procedures, so I tend to reflexively type "y" and "\n" so the \n gets blasted into the next prompt ("Do you want to restart") so I get skipped over the 2nd prompt. Not a huge deal, its just different than most updates which do a regular \n terminated read for the update confirmation.

I shall take a look at my inconsistent ways! Thanks for the feedback!

 

[visortgw]

I just discovered (a long-standing?) issue with BACKUPMON. If mounting the primary backup destination network share fails, BACKUPMON exits without attempting the secondary backup. Apparently, my local Synology NAS went offline due to a power/network issue (AiMesh node that it's attached to didn't come back up after network reboot) — I'm away from home, and I can't address it for several days. In the meantime, a remote Synology NAS is available as the destination for secondary backup, but BACKUPMON never attempts to mount it.

IMO, if mounting the primary backup destination fails, BACKUPMON should continue to attempt the secondary backup before exiting.

 

[Ripshod]

I just discovered (a long-standing?) issue with BACKUPMON. If mounting the primary backup destination network share fails, BACKUPMON exits without attempting the secondary backup. Apparently, my local Synology NAS went offline due to a power/network issue (AiMesh node that it's attached to didn't come back up after network reboot) — I'm away from home, and I can't address it for several days. In the meantime, a remote Synology NAS is available as the destination for secondary backup, but BACKUPMON never attempts to mount it.

IMO, if mounting the primary backup destination fails, BACKUPMON should continue to attempt the secondary backup before exiting.

As Viktor posted earlier

That's correct... if a significant error occurs, it quits entirely. The thought was, if something major is out of whack, to step back and let you investigate a cause before attempting another backup.

Did you get the failure email?