What's new

BACKUPMON BACKUPMON v1.5.9 -Feb 21, 2024- Backup/Restore your Router: JFFS + NVRAM + External USB Drive! (Now available in AMTM!)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Viktor Jaep

Part of the Furniture
BACKUPMON v1.5.9
Released February 21, 2024

First off -- HUGE thanks to @Jeffrey Young for sharing his original backup script. His script is the main engine of BACKUPMON, and all credit goes to him! BACKUPMON is simply a wrapper around Jeff's backup script functionality, adding easy-to-use menus, more status feedback, and the ability to launch a restore based on your previous backups. Also, big thanks to @Martinski for his many contributions as well as his extremely helpful AMTM email library script, and huge props to @visortgw for contributing to the backup methodologies thread with his scripts and wisdom!

Executive Summary: BACKUPMON is a shell script that provides backup and restore capabilities for your Asus-Merlin firmware router's JFFS, NVRAM and external USB drive environments. By creating a network share off a NAS, server, or other device, BACKUPMON can point to this location, and perform a daily backup to this mounted drive. To perform daily, unattended backups, simply add a statement to your cron schedule, and launch backupmon.sh at any time you wish. During a situation of need to restore a backup after a catastrophic event with either your router or attached USB storage, simply copy the backupmon.sh & .cfg files over to a newly formatted /jffs/scripts folder, ensuring that your external USB storage was formatted with the same exact name (which is retrievable from the instructions.txt in your backup folder), and perform the restore by running the "backupmon.sh -restore" command, selecting the backup you want to use, and going through the prompts to complete the restoration of both your JFFS, NVRAM and external USB drive environments.

Use-case: BACKUPMON was designed to backup from, and restore to an already configured router from an external network resource, given a situation of a corrupted USB drive, botched Entware environment, or other general corruption issues. It can, however, also restore you back to a previous state if you decide to completely wipe your router or external drive from scratch. You can use it to move from one external USB drive to another... say, upgrading from a flashdrive to an SSD! You could also use it to restore your environment to a similar router if your old one dies, and you pick up the same model + firmware level as a replacement.

Here are a couple of different network/USB backup scenarios that it is able to handle (as of v1.35):

Router USB Drive -> External Network Device/Share (on your local network)
Router USB Drive -> Local Router Network Share (could be mounted to a secondary partition on your USB Drive, or secondary USB Drive)
Router USB Drive -> Secondary Router USB Drive (plugged into the secondary USB port)
Router USB Drive -> Router USB Drive (backing up to itself into a separate folder... of course, not recommended, but possible)
Router USB Drive Partition 1 -> Router USB Drive Partition 2 (kinda like the one above, but gives it a little more separation)

NOTE: If you do go down the path of backing your USB drive to your USB drive, it's possible, but 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.

What it should NOT be used for: It is not meant to restore backups from one particular model of router (ex: RT-AC86U), to a different shiny new model (ex: GT-AX6000) that you just picked up. In this case, it's still best to set your new router up from scratch, and selectively import any critical files manually from your .TAR backups to your new router if needed. Also, please do not restore your settings/backups from an older firmware to a newer firmware. Your router's CFG (settings) file is meant for the current firmware you're on, so if you do restore, make sure it's still on the same firmware as before.

Requirements:
  • This script will allow you to back up one partition of your choice. You are no longer limited to sda1.
  • Your Network Backup Target must be able to speak the CIFS/SMB protocol, as that is the method currently used to back up your files across the network. CIFS (Common Internet File System) is a dialect of the SMB (Server Message Block) protocol, and is a very broad standard supported by Windows, Linux and Apple devices. I am looking into supporting NFS as well in the very near future.
  • You now have the option to backup from USB1 to USB2, or USB to itself... though not recommended.
  • Your External USB should have a valid drive label. Having a blank label may create issues backing up or restoring.

BACKUPMON is free to use under the GNU General Public License version 3 (GPL 3.0).

This project is hosted on GitHub

Latest release notes updated here

Changelog here | What's new: Exclusion file guidance, AMTM Email Notifications, tar.gz Integrity Checks, Integration with MerlinAU!, Swap File Exclusion, Multiple SMB Protocol Support, Dedicated Log File, USB Backup Options/BW Mode, Base64 Pwd Encoding & More!, Added to AMTM!, EXT USB optional, Secondary Backups + Connection Tester, Auto Purge, Timer bypass, Forced Reboot/Source-Target Checks, NVRAM backup/restore!, NVRAM Extract, Go Live!, Perpetual Backup Purging, Perpetual Frequency added, Basic vs Advanced Backup Modes, Scheduled backups & Weekly/Monthly/Yearly Frequencies!, Release Candidate!

Screenshots:


In normal backup mode, a backup will launch after 10 seconds, giving you a chance to enter setup mode, or restore mode. Normally, you would be running this command from an automated CRON job, to back up your environment unattended each day.
1708302144240.png


In a normal backup scenario, you will get STATUS feedback after each major item is completed. TAR status messages are left on to help you with any troubleshooting should something not work right, or be locked.
1708302201045.png


In a restore scenario (by executing 'backupmon.sh -restore" or hitting the X key within 10 seconds of a backup, you are presented with a list of information to successfully accomplish a restore.
1699677076522.png


How is this script supposed to run?​

In a normal, daily mode, this script would run from a CRON job, in order to back router completely on a daily basis. Instructions:
  1. Download and install directly using your favorite SSH tools, copy & paste this command (or update from within 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"

  2. Configure it using this command:
    Code:
    sh /jffs/scripts/backupmon.sh -setup

  3. Run a backup manually in an SSH window with this command:
    Code:
    sh /jffs/scripts/backupmon.sh -backup (or simply just execute 'backupmon')

  4. Run a restore manually in an SSH window with this command (or hit the X button with 10 seconds of a backup starting):
    Code:
    sh /jffs/scripts/backupmon.sh -restore

  5. To make things easier, you can now just type the script name itself (without the path/extension), like so:
    Code:
    backupmon
 
Last edited:

Do I need to configure anything?​

You can enter the setup screen with the command 'backupmon.sh -setup' or by hitting the 's' key within 10 seconds of the backup starting:
1708373521657.png


Hitting the "sc" option, there are currently 15 items you can configure.
1708288041307.png


I'm definitely looking for your feedback... what works, what doesn't... what else would you like to see. But all-in-all, as good ideas come up for things to possibly add, very much a WIP (work-in-progress). ;) Lots more stuff to come... I'm looking at adding a way to add some functionality to schedule the backups in CRON... so check back soon!

More Information:

1.) How does it all work? In TLDR; format, when BACKUPMON runs a regular backup, it will create a daily folder under the folder structure you have defined for it to connect to on your network share. So for example today, on September 4, 2023, it would create a /04 folder (if you're on a "Monthly" frequency), where its backups will get dumped into.

2.) Backup Frequencies - there are 4 different kinds depending on your preference:
  • "Weekly" frequency would write "Mon, Tue... Sun" folders.
  • "Monthly" would write daily "01, 02, 03... 30, 31" folders for each day of the month,
  • "Yearly" would write "001, 002, 003... 364, 365" folders for each day of the year.
  • "Perpetual" would write a unique folder based on date/time, such as "20230909-092511".
At this time, "basic mode" (explained below in more detail) will back everything up in 1 week, month or year cycles, and will overwrite the backup files each time it comes across the same day in its cycle, unless you've chosen the "Perpetual" frequency, in which case it keeps backups forever under its unique folder structure. In "advanced mode", it does not overwrite backups in your weekly, monthly and yearly folders, and keeps everything forever... Here's a screenshot of what your backup folders on your network share might look like (please note there's a bit of a mix between "Monthly" and "Perpetual" frequency backups as I was testing... :)

1694267466886.png


3.) Backup copies - During a backup, BACKUPMON will also copy over a copy of 'backupmon.sh', 'backupmon.cfg', any optional TAR exceptions list you have defined, a text dump of your NVRAM, and a copy of restore "instructions.txt". (see above) Within this instructions.txt file, you will find the same instructions you see on screen during a restore, telling you what steps need to be taken for a successful restore. In it, is also your latest external USB drive label, which must be duplicated when you format a new USB drive, and want to restore your backup to it.

4.) The optional TAR exclusion list can be placed in a directory of your choice. PLEASE NOTE: By default, backupmon will back up everything, swap files, log files, included! It is a good idea to exclude these using this exclusion list file. You may encounter issues restoring backups if you try to restore a swap file to an already existing swap file on your router. You can create this file anywhere, but I prefer to keep things in /jffs/addons/backupmon.d and named it "exclusions.txt", just to clear the clutter. The contents of this file is simply a list of files that TAR can safely ignore during a backup. Certain files, like your swap file, or other temporary files, aren't needed when restoring a backup, and get recreated after a restore. As of v1.42, the swap file is being excluded from backups unless you override this option (#9) in the config menu. Huge thanks to @visortgw for sharing his exclusion file... the default exclusion items list looks something like this:

exclusions.txt
Code:
myswap.swp
entware/var/log/*
skynet/skynet.log
entware/var/lib/unbound/unbound.log
*.tar
*.gz

Save this file somewhere on your router, and make sure it's properly referenced in BACKUPMON. Eliminating swap and other temp files could really speed up your backups tremendously, and save you from headaches down the road on a restore.

5.) The Basic vs Advanced Mode differences are described below:

BASIC
- Only backs up one backup set per daily folder
- Backup file names have standard names based on jffs and USB drive label names
- Self-prunes the daily backup folders by deleting contents before backing up new set (N/A when 'Perpetual Frequency' is enabled)
- Will overwrite daily backups, even if multiple are made on the same day (N/A when 'Perpetual Frequency' is enabled)
- Restore more automated, and only required to pick which day to restore from

ADVANCED
- Backs up multiple daily backup sets per daily folder
- Backup file names contain extra unique date and time identifiers
- Keeps all daily backups forever, and no longer self-prunes
- Will not overwrite daily backups, even if multiple are made on the same day
- Restore more tedious, and required to type exact backup file names before restore

6.) Manually Purging Perpetual Backups -- Under the config menu, when selecting "perpetual" backup frequency, you will have the option to choose whether you want to enable backup purging for everything older than a certain number of days. Once configured, you can manually access the purge backups functionality under the operations area under the setup menu. This function will step you through multiple prompts before committing to delete any backups, and will show you which backups are affected. PLEASE NOTE: deleting backups is permanent, and advise caution on what you are deleting, and ensure that the list presented to you is what you want deleted. Also, PLEASE NOTE: if there are any backups that you want to save or store for later use, PLEASE move these to a SAFE and otherwise secure location outside of the backup folder structure that BACKUPMON utilizes, else there will be a chance these backups will get deleted.

Automatically Purging Perpetual Backups -- if you have enabled "Perpetual Backups", and "Purge backups", and run BACKUPMON with the -backup switch (ie. "sh backupmon.sh -backup"), then it will auto purge your backups after it finishes your normal backup. This was done to make it simpler when running this under a daily CRON job to not only back up but purge as well with one command.

See screenshot below as an example:
1699677535562.png


7.) Commandline switches - When running backupmon with a switch, you can utilize other functionality that is normally only available through the UI. Here is an explanation of what each switch does:

sh /jffs/scripts/backupmon.sh -- Running the script with no switches simply runs the primary and secondary backups (no auto purge).
sh /jffs/scripts/backupmon.sh -setup -- This displays the setup + operations menu
sh /jffs/scripts/backupmon.sh -backup -- This runs the normal primary and secondary backups, and runs auto purge!
sh /jffs/scripts/backupmon.sh -restore --This initiates the restore procedure, allowing you to pick from primary or secondary backups
sh /jffs/scripts/backupmon.sh -purge -- This runs the auto purge routine against the perpetual backup folders

B&W Mode: You can now optionally run a monochrome color scheme for those who are capturing screen output by using a secondary -bw switch after any of the other primary switches. Example:

sh /jffs/scripts/backupmon.sh -backup -bw -- This runs the normal primary and secondary backups, and runs auto purge in B&W mode!
 
Last edited:
How do I restore a backup?

As per the instructions.txt file that is automatically copied to your backup folders, the restore instructions are as follows:

Code:
RESTORE INSTRUCTIONS

IMPORTANT:
Asus Router Model: GT-AX6000
Firmware/Build Number: 3004.388.4
EXT USB Drive Label Name: ASUS-SSD

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, perform another reboot.  Everything should be restored as normal!

PLEASE NOTE: The USB Drive Label name is included in this file for you to remember what your drive was called, so when you format a new USB drive, you can label it with the same exact name. If you really want to call it something different, try changing the label after you have restored all your files.

Post-restore activities

I don't have an overly complex environment on my test router, and after testing out a restore on my test router using the instructions above, I didn't have any post-restore issues.

The key is, once all files are restored, virtually any complex environment should continue to run, even if you're also running Diversion, YazFi, Unbound, x3mrouting, etc... If you run across any other gotchas, please post them below, and I'll add to the instructions.

Automation
BACKUPMON now has the option to schedule your daily backup routine, and will add a CRON command to kick things off. Please refer to the configuration menu to set the hour and minute. Once enabled, it will automatically schedule your backup job. If you want to get creative and add other jobs, please use the instructions below to create a backup job in CRON... You can look up how to properly format a scheduled event using tools like these: https://crontab.guru/

To run a daily job at 2:30am, BACKUPMON will add this line to your services-start file (located under your /jffs/scripts folder), and it will automatically be scheduled after your next router reboot:

Code:
cru a RunBackupMon "30 2 * * * sh /jffs/scripts/backupmon.sh"

1695849002867.png

:p
 
Last edited:
For all those who were wondering... I had to go with <insertscriptnamehere>MON. Couldn't give up my streak.

Plus it would have really upset my OCD. LOL :p
 
Well that was quick... Added a few more feature I thought would be nice-to-haves... One being a CRON job scheduler, and the other allowing you to choose between weekly, monthly or yearly backups! Enjoy!

What's new!
v0.6RC - (September 5, 2023)
- ADDED:
Ability to set a scheduled daily CRON job with the time of your choice. This function will create the necessary cru statement in your /jffs/scripts/service-start file, and add it to CRON as well. Unselecting this choice will remove it from both CRON and the service-start file. This item can be configured under the config menu, item #7.
- ADDED: Ability to choose between 3 different backup frequency strategies. You get to choose between cycling through a week, a month, or a year. The week selection, it will create folders from Mon - Sun. With the month (standard), it creates folder from day 01 through day 31... and with the year, day 001 all the way through day 365. You better be prepared to allocate some space. ;) You can pick your backup frequency under the config menu, item #8.

Download link (or update through the setup menu):
Code:
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon-0.6.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

Significant screenshots:
On the setup menu, you will now see new items #7 and #8 added to handle the scheduling of backup jobs, as well as being able to select a frequency.
1693955204475.png


On the normal backup screen, you will see an additional item show what kind of frequency is selected.
1693955274372.png
 
Last edited:
@Viktor Jaep you’ve done it again …
Terrific idea and executed with your trademark panache!

Here is the output of my initial manual run, after configuration, for your perusal.
I have a “/jffs/addons/backupmon.d/exclusions” file set up with contents as per your example at this stage for testing.

Code:
BACKUPMON v0.6

Normal Backup starting in 10 seconds. Press [S]etup or [X] to override and enter RESTORE mode

Backing up to \\192.168.1.200\NetBackup mounted to /tmp/mnt/backups
Backup directory location: /asusrouter -- Frequency: Weekly

[Normal Backup Commencing]...

Messages:
ALERT: External Drive directory not set. Newly created under: /tmp/mnt/backups
modprobe: module md4 not found in modules.dep
STATUS: External Drive (\\192.168.1.200\NetBackup) mounted successfully under: /tmp/mnt/backups
STATUS: Daily Backup Directory successfully created.
STATUS: Finished backing up JFFS to /tmp/mnt/backups/asusrouter/Wed/jffs.tar.gz.
tar: ./entware/var/syslog-ng.ctl: socket ignored
tar: ./entware/var/run/syslog-ng/syslog-ng.ctl: socket ignored
STATUS: Finished backing up EXT Drive to /tmp/mnt/backups/asusrouter/Wed/AMTM-USB.tar.gz.
STATUS: Finished copying backupmon.sh script to /tmp/mnt/backups/asusrouter.
STATUS: Finished copying backupmon.cfg script to /tmp/mnt/backups/asusrouter.
STATUS: Finished copying exclusions script to /tmp/mnt/backups/asusrouter.
STATUS: Finished copying restore instructions.txt to /tmp/mnt/backups/asusrouter.
STATUS: External Drive (\\192.168.1.200\NetBackup) unmounted successfully.

Seemed to go well mostly but not sure what the “socket ignored” errors are about though?

Suggestion to think about …

If I was just going to run Manual backups occasionally, or even going to enable the weekly or monthly rotating backups, I’d probably like the confidence of being sure about the date/time of the “snapshot” rather than it just saying “Wed” like the one I just did, so maybe have the option of naming the backup directory in some sort of ISO date format such as “2023-09-06 T124206” to represent 6th September 2023 at 12:42:06, or the like?

But congratulations on BackupMon anyway!
😁
 
Output of my 2nd run …

Code:
BACKUPMON v0.6

Normal Backup starting in 10 seconds. Press [S]etup or [X] to override and enter RESTORE mode

Backing up to \\192.168.1.200\NetBackup mounted to /tmp/mnt/backups
Backup directory location: /asusrouter -- Frequency: Weekly

[Normal Backup Commencing]...
BACKUPMON v0.6

Normal Backup starting in 10 seconds. Press [S]etup or [X] to override and enter RESTORE mode

Backing up to \\192.168.1.200\NetBackup mounted to /tmp/mnt/backups
Backup directory location: /asusrouter -- Frequency: Weekly

[Normal Backup Commencing]...

Messages:
modprobe: module md4 not found in modules.dep
STATUS: External Drive (\\192.168.1.200\NetBackup) mounted successfully under: /tmp/mnt/backups
STATUS: Finished backing up JFFS to /tmp/mnt/backups/asusrouter/Wed/jffs.tar.gz.
tar: ./entware/var/syslog-ng.ctl: socket ignored
tar: ./entware/var/run/syslog-ng/syslog-ng.ctl: socket ignored
STATUS: Finished backing up EXT Drive to /tmp/mnt/backups/asusrouter/Wed/AMTM-USB.tar.gz.
STATUS: Finished copying backupmon.sh script to /tmp/mnt/backups/asusrouter.
STATUS: Finished copying backupmon.cfg script to /tmp/mnt/backups/asusrouter.
STATUS: Finished copying exclusions script to /tmp/mnt/backups/asusrouter.
STATUS: Finished copying restore instructions.txt to /tmp/mnt/backups/asusrouter.
STATUS: External Drive (\\192.168.1.200\NetBackup) unmounted successfully.

Note the errors again for:-

“modprobe: module md4 not found in modules.dep”
And the
“Socket ignored” X 2

Also, the 2nd backup overwrote the previous “Wed” backup, which is probably not what I’d want if I’d done a manual backup prior to an update of some kind and then another after the update, and then a few hours later realised I needed to “roll back” for example, which is how I tend to operate?

But interested as always in your thoughts.
 
Hi there,

I also saw @Jeffrey Young script and nicked it for my own use BUT I had problems...

The weird thing was that the router would reboot around 12 hours or so after I ran the backup. This was consistent and no longer happened when I stopped running the backup script. There was nothing in syslog to suggest anything amiss.

-- I noticed also the umount would always fail leaving the NAS drive mounted. The failure would be "umount: can't unmount /tmp/mnt/NAS/public: Device or resource busy"

-- I noticed that for the first time ever, my router would use some swap space - not much about 20Mb.

So, I've just configured and run your script manually. The same two things happened - the umount failed in the same way and the router has used some swap space (0.92Mb).

I'll leave it and see if the router reboots overnight.
EDIT - It crashed after about 15 minutes
 
Last edited:
Well - that didn't work - Router crashed after about 15 minutes!!!
Are you seeing any errors in your syslog before or after the crash/reboot? Sounds like there's more going on. You should be able to run a command to mount and dismount a drive without adverse effects. Have you tried creating a different share on your NAS/server? Perhaps there's some permissions issue on the other end that's preventing it from closing correctly, and causing your router to crash?
 
Note the errors again for:-

“modprobe: module md4 not found in modules.dep”
And the
“Socket ignored” X 2
Thanks for giving it a whirl, @Stephen Harrington! I'll have to send you some code to see why you'd get that modprobe message. I thought I had that nixed, but it's not a huge issue.

Also, the 2nd backup overwrote the previous “Wed” backup, which is probably not what I’d want if I’d done a manual backup prior to an update of some kind and then another after the update, and then a few hours later realised I needed to “roll back” for example, which is how I tend to operate?

But interested as always in your thoughts.
That's a great suggestion, because yeah, right now it overwrites itself on each day if you run it successively. Creating a file with this extra info shouldn't be a problem, but subsequently selecting it will be a bit trickier, since I'm relying on the filename being named a static name. I will definitely look into this!
 
Are you seeing any errors in your syslog before or after the crash/reboot

Nothing in syslog, just the "BusyBox" entry, which is usually the first thing after a reboot.

Code:
Sep  6 11:25:29 RT-AC86U-admin: BACKUPMON - Successfully wrote a new config file
Sep  6 11:26:41 RT-AC86U-admin: Backup Script: Finished backing up JFFS to /tmp/mnt/NAS/public/BACKUPS/Routers/SCHED_BU/AX86U/06/jffs.tar.gz
Sep  6 11:26:54 RT-AC86U-admin: Backup Script: Finished backing up EXT Drive to /tmp/mnt/NAS/public/BACKUPS/Routers/SCHED_BU/AX86U/06/USB_120GB.tar.gz
Sep  6 11:27:12 wlceventd: wlceventd_proc_event(685): eth5: Auth 28:CD:C1:06:48:F4, status: Successful (0), rssi:0
Sep  6 11:27:12 wlceventd: wlceventd_proc_event(722): eth5: Assoc 28:CD:C1:06:48:F4, status: Successful (0), rssi:-62
Sep  6 11:27:46 wlceventd: wlceventd_proc_event(685): eth5: Auth 28:CD:C1:04:2A:EC, status: Successful (0), rssi:0
Sep  6 11:27:46 wlceventd: wlceventd_proc_event(722): eth5: Assoc 28:CD:C1:04:2A:EC, status: Successful (0), rssi:-72
Sep  6 11:47:59 wlceventd: wlceventd_proc_event(662): eth5: Disassoc 28:CD:C1:06:48:F4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
May  5 06:05:05 kernel: klogd started: BusyBox v1.25.1 (2023-08-21 15:34:18 EDT)
May  5 06:05:05 kernel: Linux version 4.1.52 (merlin@ubuntu-dev) (gcc version 5.5.0 (Buildroot 2017.11.1) ) #2 SMP PREEMPT Mon Aug 21 16:24:28 EDT 2023
May  5 06:05:05 kernel: CPU: AArch64 Processor [420f1000] revision 0

BTW, the actual backups worked fine!

I thought the use of the swap space might mean I have a problem with my USB drive, but I've replaced my original pen drive with an SSD in an enclosure and the crash still happens.

I don't know what permissions or anything else to check on the NAS, I have a RasPi which has the same NAS share mounted on it and has no problems.

Oh BTW, I got the “modprobe: module md4 not found in modules.dep” error as well.
 
Last edited:
About the socket ignored warnings:

Code:
"Sockets are zero level files that are used by daemon processes
to communicate with each other. They are created and destroyed as
necessary when the daemons start and stop. They can safely be
ignored."
 
Thanks for giving it a whirl, @Stephen Harrington! I'll have to send you some code to see why you'd get that modprobe message. I thought I had that nixed, but it's not a huge issue.


That's a great suggestion, because yeah, right now it overwrites itself on each day if you run it successively. Creating a file with this extra info shouldn't be a problem, but subsequently selecting it will be a bit trickier, since I'm relying on the filename being named a static name. I will definitely look into this!
The modprobe will fail if you are on 386 base as it is not needed. Nothing to worry about. I also think only certain 388 firmware routers need it.
 
Hi there,

I also saw @Jeffrey Young script and nicked it for my own use BUT I had problems...

The weird thing was that the router would reboot around 12 hours or so after I ran the backup. This was consistent and no longer happened when I stopped running the backup script. There was nothing in syslog to suggest anything amiss.

-- I noticed also the umount would always fail leaving the NAS drive mounted. The failure would be "umount: can't unmount /tmp/mnt/NAS/public: Device or resource busy"

-- I noticed that for the first time ever, my router would use some swap space - not much about 20Mb.

So, I've just configured and run your script manually. The same two things happened - the umount failed in the same way and the router has used some swap space (0.92Mb).

I'll leave it and see if the router reboots overnight.
EDIT - It crashed after about 15 minutes
Mount point will not unmount if there are any open files related to the share. Something may not be cleaning up properly.

Swap space usage is pretty normal with SMB. It is bloatly and uses a lot of memory. That is just the nature of SMB.

Not a good sign with the router reboots! What firmware. If 388.4, this is line with other applications causing reboots such as SpdMerlin. I have not ventured into the 388 base with my AX88U as each version has had its issues that would have affected me. I think I am also staying where I am and passing over 388.4 as well. Some testing 388.4 and SpdMerlin have found that disabling QoS solved the reboots. Are you using QoS at all?
 
Not a good sign with the router reboots! What firmware. If 388.4, this is line with other applications causing reboots such as SpdMerlin. I have not ventured into the 388 base with my AX88U as each version has had its issues that would have affected me. I think I am also staying where I am and passing over 388.4 as well. Some testing 388.4 and SpdMerlin have found that disabling QoS solved the reboots. Are you using QoS at all?

I'm running the latest FW: Merlin 3004.388.4

I just tried an experiment, I mounted the NAS and then immediately tried to umount it, but it failed in the same way. lsof didn't show any open files. The router crashed about 15 minutes later. So the problem is definitely the NAS mount and not the 'backup' part of the script.

I have 'Traditional QoS' configured.
Is it really worth disabling it & trying again?
 
I'm running the latest FW: Merlin 3004.388.4

I just tried an experiment, I mounted the NAS and then immediately tried to umount it, but it failed in the same way. lsof didn't show any open files. The router crashed about 15 minutes later. So the problem is definitely the NAS mount and not the 'backup' part of the script.

I have 'Traditional QoS' configured.
Is it really worth disabling it & trying again?
For trouble shooting purposes, disable QoS and see what happens. It would be good to know if QoS is causing issues here as well.

It is always hit and miss with Samba as far as the mount goes. If Samba is holding the resource, it will be hard to close. Does not really hurt anything to leave a connection open, unless you are worried about security.
 
For trouble shooting purposes, disable QoS and see what happens. It would be good to know if QoS is causing issues here as well.

OK, I'll give it a go and see what happens.
 
BTW, if the router's version of umount supports it, you could use the -l switch to force an unmount.
 
BTW, if the router's version of umount supports it, you could use the -l switch to force an unmount.
I don't think that really unmounts it, just pretends to.

I did try "umount -f", but that made a right mess, disconnected the NAS but left the mount point which couldn't be deleted.
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top