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

[Ripshod]

Quick query.
First. I've changed no settings but as from this morning secondary backups stopped. In the configuration it was disabled. I made no changes myself so it's just weird.
Second. With a manual backup I've noticed some kind of error line at the end of the log. It's not causing any problems as far as I can see - settings and the actual backups are unaffected.

STATUS: Finished secondary copy of restoration instructions.txt to /tmp/mnt/secondarybackups/Router_Backups.
STATUS: Settling for 10 seconds...
STATUS: Secondary External Drive (\\10.0.0.15\removeable) unmounted successfully.
[: y: bad number

 

[Viktor Jaep]

Quick query.
First. I've changed no settings but as from this morning secondary backups stopped. In the configuration it was disabled. I made no changes myself so it's just weird.

That is really weird! Yeah, it doesn't save a config unless you save one within the config menu. Could you have restored an old copy somehow?

Second. With a manual backup I've noticed some kind of error line at the end of the log. It's not causing any problems as far as I can see - settings and the actual backups are unaffected.

I will take a closer look at this one! Thanks for the info!

 

[Ripshod]

That is really weird!

You're telling me. I've not restored anything since the WiFi went bye-bye.
Just a thought - I did update amtm yesterday, with a reboot.

 

[Viktor Jaep]

You're telling me. I've not restored anything since the WiFi went bye-bye.
Just a thought - I did update amtm yesterday, with a reboot.

As soon as I get near a computer again here soon, I'll check my backups and my secondary backups. I had also updated AMTM yesterday as well. But I don't really think that would have any effect whatsoever on a config file. I'll let you know!

EDIT: @Ripshod ... as expected, not seeing any interruptions in primary or secondary backups... My old AC86U continues to plug away as well even with the AMTM updates. Checked my setup, and secondaries were still marked as "enabled". Not quite sure what happened on your end!

STATUS: Finished secondary copy of restoration instructions.txt to /tmp/mnt/secondarybackups/Router_Backups.
STATUS: Settling for 10 seconds...
STATUS: Secondary External Drive (\\10.0.0.15\removeable) unmounted successfully.
[: y: bad number

Also, I'm not able to replicate this... what steps are you doing to make this error show up? Can you repeat this behavior?

 

[Strud]

Thanks @Strud... Glad you got that figured out. I would always recommend giving anything a name if it asks for it. All sorts of things can break if things are named with a null value, or a single space. Just a good best practice for the future. I believe when you format your USB drive with AMTM to assign a swap file to it, that it recommends giving it a name as well.

Correct, it was recommended, but still not mandatory, and I bet there are more people like me who would leave it empty Every other script was running fine without it.
If the script would use the name of the mount point (which in my case was sda1 with no label set, and now shows the label I did put) it would be bulletproof in this regard. Alternatively you might consider putting a warning message if you detect no label.

Just my 2c, I'm still very glad and thankful this script exists!

 

[Ripshod]

Also, I'm not able to replicate this... what steps are you doing to make this error show up? Can you repeat this behavior?

I fixed it. During a restoration we have to copy the backupmon.cfg and backupmon.sh files to the /jffs/scripts folder on the router. After the restoration the config file still exists in /jffs/scripts and that seems to interfere, maybe being read before the config in /jffs/addons/backupmon.d (I noticed secondary backups were disabled after the reboot). Deleting the config from /jffs/scripts, setting the secondary backup again, then a reboot and the settings stick and no error in the log - fixed.
So, could you add a line to the script to delete the errant (no longer needed) config in /jffs/scripts before the forced reboot?

 

[matthew_eli]

In case I have more than 1 partition to the EXT USB drive, is it possbile to back all of them up? I see the script is able to retrieve only the sda1 partition in this case.

Thanks for all your efforts anyway!

 

[Viktor Jaep]

Correct, it was recommended, but still not mandatory, and I bet there are more people like me who would leave it empty Every other script was running fine without it.
If the script would use the name of the mount point (which in my case was sda1 with no label set, and now shows the label I did put) it would be bulletproof in this regard. Alternatively you might consider putting a warning message if you detect no label.

Just my 2c, I'm still very glad and thankful this script exists!

I will definitely be adding some checks for this. Thank you for bringing this to light!

I fixed it. During a restoration we have to copy the backupmon.cfg and backupmon.sh files to the /jffs/scripts folder on the router. After the restoration the config file still exists in /jffs/scripts and that seems to interfere, maybe being read before the config in /jffs/addons/backupmon.d (I noticed secondary backups were disabled after the reboot). Deleting the config from /jffs/scripts, setting the secondary backup again, then a reboot and the settings stick and no error in the log - fixed.
So, could you add a line to the script to delete the errant (no longer needed) config in /jffs/scripts before the forced reboot?

Nice catch! Ahhh... Yes, it looks like that file never gets removed after being copied back to its original location during a restore process! I'll get this taken care of.

In case I have more than 1 partition to the EXT USB drive, is it possbile to back all of them up? I see the script is able to retrieve only the sda1 partition in this case.

Thanks for all your efforts anyway!

I will look into this use-case as well. Something I hadn't considered, and will add a bit more complexity to both the backup and restore. Thanks for bringing this up!

 

[Ripshod]

In case I have more than 1 partition to the EXT USB drive, is it possbile to back all of them up?

I have to ask what's on the other partition(s) as you're adding to the size of the backup and the time it will take. If these are fileshares or media files surely it would be better to just backup those files monthly by a different method? I'm assuming you're not backing up to a monster NAS.

 

[Viktor Jaep]

In case I have more than 1 partition to the EXT USB drive, is it possbile to back all of them up? I see the script is able to retrieve only the sda1 partition in this case.

Thanks for all your efforts anyway!

@matthew_eli ...If you wouldn't mind please running this statement below, and copying the results to send back to me? I need to see what these variables look like when there's multiple partitions... feel free to post here, or just PM me if you're not comfortable sharing this info:

nvram show | grep "usb_path"

 

[matthew_eli]

@matthew_eli ...If you wouldn't mind please running this statement below, and copying the results to send back to me? I need to see what these variables look like when there's multiple partitions... feel free to post here, or just PM me if you're not comfortable sharing this info:

nvram show | grep "usb_path"

Here it is:

tm_usb_path_pid=
tm_usb_path_serial=
tm_usb_path_vid=
usb_path1=storage
usb_path1_act=sda
usb_path1_diskmon_freq=0
usb_path1_diskmon_freq_time=
usb_path1_fs_path0=sda1
usb_path1_manufacturer=SanDisk
usb_path1_node=2-1
usb_path1_pid=558c
usb_path1_product=Extreme SSD
usb_path1_serial=323032373151343033393939
usb_path1_speed=5000
usb_path1_vid=0781
usb_path2_diskmon_freq=0
usb_path2_diskmon_freq_time=
usb_path3_diskmon_freq=0
usb_path3_diskmon_freq_time=
usb_path_sda=2-1
usb_path_sda1=2-1
usb_path_sda1_label=overlay
usb_path_sda2=2-1
usb_path_sda2_label=optware
usb_path_sda3=2-1
usb_path_sda3_label=SWAP
usb_path_sda4=2-1
usb_path_sda4_label=MAT_ROUTER
usb_path_sda_label=
size: 81683 bytes (114925 left)

 

[matthew_eli]

I have to ask what's on the other partition(s) as you're adding to the size of the backup and the time it will take. If these are fileshares or media files surely it would be better to just backup those files monthly by a different method? I'm assuming you're not backing up to a monster NAS.

The problem arises since I had this SSD with a former router with Overlay partition and I don't need to save it (that is SDA1), but the other 2, rather optware and the storage partition, some MBs anyway

 

[Viktor Jaep]

Correct, it was recommended, but still not mandatory, and I bet there are more people like me who would leave it empty Every other script was running fine without it.
If the script would use the name of the mount point (which in my case was sda1 with no label set, and now shows the label I did put) it would be bulletproof in this regard. Alternatively you might consider putting a warning message if you detect no label.

Just my 2c, I'm still very glad and thankful this script exists!

So, I actually had a check happening that if the USB drive label was null, then don't back it up... this was in response for people who didn't have an external drive hooked up, and was causing some errors because the script was assuming that a USB drive is always hooked up.

So that leads me to believe that your USB label may have just been a single space character. Will have to look into how to capture situations like this, or may even require a 3char minimum for a label name... I know a label is not mandatory, but it sure makes life a lot more difficult trying to account for these different types of scenarios.

 

[Strud]

So, I actually had a check happening that if the USB drive label was null, then don't back it up... this was in response for people who didn't have an external drive hooked up, and was causing some errors because the script was assuming that a USB drive is always hooked up.

So that leads me to believe that your USB label may have just been a single space character. Will have to look into how to capture situations like this, or may even require a 3char minimum for a label name... I know a label is not mandatory, but it sure makes life a lot more difficult trying to account for these different types of scenarios.

I'm 100% sure I had no label set at all, as that's what I'm doing for years, since I started to use Merlin with my old ac68u. Also the mounting point show in AMTM was "/tmp/mnt/sda1", I guess it would include the label name otherwise, as it does now, whatever the label is, am I right?

Does your script keep any logs somewhere? Them I'm happy to share it with you, maybe it could help.

 

[PeterT]

Does your script keep any logs somewhere? Them I'm happy to share it with you, maybe it could help.

What I've done to create a log is to use a wrapper script to invoke backupmon.sh. I needed some extra processing for some other automation I hav e in place to trigger a backup from a NAS to it's attached USB drive.

My wrapper is just

#!/bin/sh
{
  echo Backup starting: `date` 
  ssh admin@192.168.2.70 "touch /share/backups/router/main/backup_running"
  ./backupmon.sh -backup
  ssh admin@192.168.2.70 "rm /share/backups/router/main/backup_running"
  echo Backup ending: `date`
} 2>&1 | tee /tmp/backup.log

Of course it means I have to edit the services-start.sh script to schedule my script, and remove the backupmon schedule.

(DUH. easier just to update the backupmon.cfg and remove the schedule there).

 

[Viktor Jaep]

In case I have more than 1 partition to the EXT USB drive, is it possbile to back all of them up? I see the script is able to retrieve only the sda1 partition in this case.

Thanks for all your efforts anyway!

So I've been thinking more about this request, and was hoping to get your feedback...

1.) Since you have 4 partitions, what would your plan be should your EXT USB drive fail? Would you try to repartition your drive using the same sizes and labels you have now and then try to restore to those partitions? Do you currently have backups for all your partitions?
2.) How would you envision BACKUPMON working in a situation like this? Would it need to detect the total number of partitions you have setup on your EXT USB drive, and determine if we have matching backups that correlate to the labels you had previously set for these partitions should we need to restore to these partitions?
3.) Would you be satisfied with manually selecting which backups would need to be restored to which partitions, instead of trying to automate a recovery? It seems there can be a lot that can go wrong between partition label names, partition numbers, and partition sizes.

 

[matthew_eli]

So I've been thinking more about this request, and was hoping to get your feedback...

1.) Since you have 4 partitions, what would your plan be should your EXT USB drive fail? Would you try to repartition your drive using the same sizes and labels you have now and then try to restore to those partitions? Do you currently have backups for all your partitions?

In case my SSD will fail, I plan to recreate only the partitions I need. I don't have any backup at the moment, since there is no easy/automatic way to do it (WinSCP)

2.) How would you envision BACKUPMON working in a situation like this? Would it need to detect the total number of partitions you have setup on your EXT USB drive, and determine if we have matching backups that correlate to the labels you had previously set for these partitions should we need to restore to these partitions?

Yeah exactly; in the backup phase, selecting the partitions to be saved. In the restore phase, correlate the label and restore those partitions

3.) Would you be satisfied with manually selecting which backups would need to be restored to which partitions, instead of trying to automate a recovery? It seems there can be a lot that can go wrong between partition label names, partition numbers, and partition sizes.

Manual shall be available in case of restoring, since someone can also decide to change the labels

 

[Viktor Jaep]

In case my SSD will fail, I plan to recreate only the partitions I need. I don't have any backup at the moment, since there is no easy/automatic way to do it (WinSCP)


Yeah exactly; in the backup phase, selecting the partitions to be saved. In the restore phase, correlate the label and restore those partitions


Manual shall be available in case of restoring, since someone can also decide to change the labels

I'm still toying with the possibility of supporting multiple partitions... in the interim, to make sure your stuff stays safe, I'd recommend using @Jeffrey Young's script... I've made a few quick changes for you to help with your situation.... see if this works for you?

#!/bin/sh
# Original: August 9, 2023 @Jeffrey Young
# Last modified: October 16, 2023 @Viktor Jaep
# This version handles exactly 4 USB drive partitions

USERNAME="**********"
PASSWORD="**********"
UNC="\\\\192.168.189.5\\users"
EXTDRIVE="/tmp/mnt/WDCloud"
BKDIR="/router/AX88UBackup"
DAY="$(date +%d)"
USBDRIVEP1="/tmp/mnt/$(nvram get usb_path_sda1_label)"
USBDRIVEP2="/tmp/mnt/$(nvram get usb_path_sda2_label)"
USBDRIVEP3="/tmp/mnt/$(nvram get usb_path_sda3_label)"
USBDRIVEP4="/tmp/mnt/$(nvram get usb_path_sda4_label)"

if ! [ -d $EXTDRIVE ]; then
    mkdir -p $EXTDRIVE
    chmod 777 $EXTDRIVE
fi

if ! mount | grep $EXTDRIVE > /dev/null 2>&1; then
    modprobe md4 > /dev/null    # Required now by some 388.x firmware for mounting remote drives
    mount -t cifs $UNC $EXTDRIVE -o "vers=2.1,username=${USERNAME},password=${PASSWORD}"
    sleep 5
fi

if [ -n "`mount | grep $EXTDRIVE`" ]; then
 
    if ! [ -d "${EXTDRIVE}${BKDIR}" ]; then mkdir -p "${EXTDRIVE}${BKDIR}"; fi
    if ! [ -d "${EXTDRIVE}${BKDIR}/${DAY}" ]; then mkdir -p "${EXTDRIVE}${BKDIR}/${DAY}"; fi

    [ -f ${EXTDRIVE}${BKDIR}/${DAY}/jffs.tar* ] && rm ${EXTDRIVE}${BKDIR}/${DAY}/jffs.tar*
    [ -f ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP1.tar* ] && rm ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP1.tar*
    [ -f ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP2.tar* ] && rm ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP2.tar*
    [ -f ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP3.tar* ] && rm ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP3.tar*
    [ -f ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP4.tar* ] && rm ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP4.tar*
 
    tar -czf ${EXTDRIVE}${BKDIR}/${DAY}/jffs.tar.gz -C /jffs . >/dev/null
    logger "Script ImageUSB: Finished backing up jffs to ${EXTDRIVE}${BKDIR}/${DAY}/jffs.tar.gz"
 
    tar -zcf ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP1.tar.gz -C $USBDRIVEP1 . >/dev/null
    logger "Script ImageUSB: Finished backing up USB Key P1 to ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP1.tar.gz"
    tar -zcf ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP2.tar.gz -C $USBDRIVEP2 . >/dev/null
    logger "Script ImageUSB: Finished backing up USB Key P2 to ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP2.tar.gz"
    tar -zcf ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP3.tar.gz -C $USBDRIVEP3 . >/dev/null
    logger "Script ImageUSB: Finished backing up USB Key P3 to ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP3.tar.gz"
    tar -zcf ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP4.tar.gz -C $USBDRIVEP4 . >/dev/null
    logger "Script ImageUSB: Finished backing up USB Key P4 to ${EXTDRIVE}${BKDIR}/${DAY}/USBDriveP4.tar.gz"

    sleep 10
    umount $EXTDRIVE
else
    echo "Failed to run ImageUSB script as mount failed"
fi

 

[JGrana]

I believe a label is vital as that becomes the filename the drive is saved to. You can't have a NULL filename.

I have thought about this label issue for a while. There are numerous times a user doesn’t label a drive - and it can cause many issues later on.

I know this might sound draconian, but @thelonelycoder and @ColinTaylor, should we force the user to enter a label during amtm’s format operation? If someone is technical enough to go into amtm and format a drive, I would think they would not mind entering a label for the drive.
Personally, I would not make it an ”option” in the amtm fd function.

Just my $0.02.

 

[JGrana]

Well I can agree with you there... I had a terrible time dealing with the network UNC format right here in BACKUPMON... in the format "\\\\192.168.1.1\\share", jumping through all kinds of hoops to try to keep the formatting intact as it gets assigned to variables, being displayed on screen, or saved back to a config file. It's "working" as-is, but I think it's kludgy and messy. Don't suppose you have a good way of dealing with these, do you?

I would take the @thelonelycoder advice and lift the few lines from his email script.
It’s literally one line to encrypt and another to decrypt.
I used it in tmo.sh to handle the password for T-Mobile’s gateway.
Very easy. And a win/win - takes care of special chars and also stores it in encrypted format.