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

[Ripshod]

And working fine at v3.02

 

[Viktor Jaep]

And working fine at v3.02

Sorry for the toll these releases are taking on your signature line!

 

[Ripshod]

Sorry for the toll these releases are taking on your signature line!

Keep rolling out them betas with the same numbers my fingers will be fine

 

[Viktor Jaep]

Thanks to all for your help testing the new features! v1.40 is out! Happy Thanksgiving!

What's new?
v1.40 - (November 20, 2023)
- ADDED: You now have the ability to choose which version of the CIFS/SMB protocol you want to use. Thanks to @vaboro, you can choose between using v1.0, v2.0, v2.1 (default), v3.0 and v3.02. This is especially useful when connecting to older hardware that may not be able to support the later versions, as it is apparent that older NAS or routers are still in use that need this for backwards compatibility.
- FIXED: Changed some of the logic around detecting the primary EXT USB drive in order to determine its label name. This is used to present a warning if the label is blank. Before, it would not let the user proceed, but now it just gives a 10sec warning before continuing, and gives some suggestions on what to label the drive, and that in its current state, may have consequences on the operation of BACKUPMON. Thanks to @_m4t3u_ and @TheMorpN for bringing this to light.
- FIXED: Thanks to a suggestion from @thelonelycoder, after the script downloads an update, it will no longer ask the user to exit and restart. Now using the exec command, the script restarts by itself, and goes back to the -setup menu.

Download link (or update directly within AMTM):

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

Significant Screenshots:

Here with option #9, you now have control over which version of the CIFS/SMB protocol you want to use... definitely helpful for backwards compatibility with older equipment that might be limited to lesser protocol versions.

 

[jsbeddow]

Thanks to all for your help testing the new features! v1.40 is out! Happy Thanksgiving!

What's new?
v1.40 - (November 20, 2023)
- ADDED: You now have the ability to choose which version of the CIFS/SMB protocol you want to use. Thanks to @vaboro, you can choose between using v1.0, v2.0, v2.1 (default), v3.0 and v3.02. This is especially useful when connecting to older hardware that may not be able to support the later versions, as it is apparent that older NAS or routers are still in use that need this for backwards compatibility.
- FIXED: Changed some of the logic around detecting the primary EXT USB drive in order to determine its label name. This is used to present a warning if the label is blank. Before, it would not let the user proceed, but now it just gives a 10sec warning before continuing, and gives some suggestions on what to label the drive, and that in its current state, may have consequences on the operation of BACKUPMON. Thanks to @_m4t3u_ and @TheMorpN for bringing this to light.
- FIXED: Thanks to a suggestion from @thelonelycoder, after the script downloads an update, it will no longer ask the user to exit and restart. Now using the exec command, the script restarts by itself, and goes back to the -setup menu.

Download link (or update directly within AMTM):

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

Significant Screenshots:

Here with option #9, you now have control over which version of the CIFS/SMB protocol you want to use... definitely helpful for backwards compatibility with older equipment that might be limited to lesser protocol versions.
View attachment 54379

Hmm...which of the CIFS/SMB Versions is the "true" default? The upper block of text would indicate that the default is Version 2.1, but the screenshot text (when choosing option #9) seems to indicate that "By default, BACKUPMON supports the latest version available (v3.02), ....", so which one is it? Am I being dense here?

 

[Viktor Jaep]

Hmm...which of the CIFS/SMB Versions is the "true" default? The upper block of text would indicate that the default is Version 2.1, but the screenshot text (when choosing option #9) seems to indicate that "By default, BACKUPMON supports the latest version available (v3.02), ....", so which one is it? Am I being dense here?

Default version is v2.1, which remains unchanged for those who don't mess with the settings... but by default (out-of-the-box), it also supports the latest version, v3.02... yeah, I see why it's confusing. I'll look at changing the wording.

 

[SomeWhereOverTheRainBow]

Default version is v2.1, which remains unchanged for those who don't mess with the settings... but by default (out-of-the-box), it also supports the latest version, v3.02... yeah, I see why it's confusing. I'll look at changing the wording.

Either way, it shouldn't interfere with the BACKUPMON process. This is rock solid!

 

[vaboro]

It's not entirely straight forward as the inbuilt Samba code conflicts with the Entware version.

Disabled the built-in Samba and installed more current version in a debian bootstrapped environment:

Spoiler: SMB up to v3.1.1 support

PORT    STATE SERVICE
445/tcp open  microsoft-ds
MAC Address: 22:33:44:55:66:77 (ASUSTek Computer)

Host script results:
| smb-protocols:
|   dialects:
|     NT LM 0.12 (SMBv1) [dangerous, but default]
|     2:0:2
|     2:1:0
|     3:0:0
|     3:0:2
|_    3:1:1

 

[Ripshod]

Once again, rather embarrassingly, I've had reason to test the restoration.
I'm quite proud to announce that this side of the script is still working sweet and dandy

 

[Viktor Jaep]

Once again, rather embarrassingly, I've had reason to test the restoration.
I'm quite proud to announce that this side of the script is still working sweet and dandy

I'm so glad things continue to function and that you're back in working order! Talk about embarrassing... throughout development, I had "accidentally" restored my router at least 2x before realizing I hadn't commented out the necessary code that would have prevented that... and before I knew it, it was too late, and BAM ... reboot. LOL

 

[_m4t3u_]

I'd love to hear about your experience!


Happy to help! The goal is to make this whole process as easy as possible... and really appreciate your participation!

Hi again!

Today I've been doing some testing. Sadly I've been unable to re label the NTFS, which was no labeled during its creation, partition located on my /dev/sda device (sda1).

I've tried the following:

1.- The command you provided as for testing purposes only. The results are, as expected, that this command works only with ext(4?) partitions:

RTR_AX_6000# tune2fs -L ms_part /dev/sda1
tune2fs 1.45.6 (20-Mar-2020)
tune2fs: Bad magic number in super-block while trying to open /dev/sda1

2.- Installed ntfs-3g package from Entware, the install worked seamesly but, it seems that the tool I needed to change the partition label (ntfslabel) is not included, for Asus-Wrt, with the main package. While ntfs-3g runs without any problem it does not permit to re label partitions without ntfslabel tool. But, it permits to testing access to NTFS partitions, I've tried this with the "rebel" partition.

RTR_AX_6000# ntfs-3g.probe --readwrite /dev/sda1
NTFS signature is missing.

So one of the previous commands may have retired/deleted some info from the unlabeled device and/or from nvram too, but I'm not sure which of two commands was the responsible... The partitions continue the same though:

Disk /dev/sda: 4294967295 sectors, 2047G
Logical sector size: 512
Disk identifier (GUID): 800cea48-20f4-4c4e-8631-daade6f7b784
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7813969886

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34           32767       15.9M   0700  Microsoft reserved partition
   2           32768      7813965823       3725G   0700  Basic data partition

But blkid can't get any information about /dev/sda1 that could previously be retrieved with this command

RTR_AX_6000# blkid | grep sd
/dev/sda2: LABEL="Data" UUID="CE2A3E342A3E19C3"
/dev/sdb1: LABEL="rtr_swap" UUID="6ee644d7-de49-4ef3-962a-311a40ebd725"

At this point, I will go with a complete wipe of that mechanical disk and USB FlashDrive. I've bought a new SSD to use in place of FlashDrive, with just one partition. I will allocate there the swap (file) and some data, like BACKUPMON copy data. The mechanical disk will be used as SMB share again but not as backups destination or any else router related data.

Of course, after that I'll go with amtm, BACKUPMON 1.4, Skynet and AdGuardHome as soon I can.

Thanks for your all your work and support!

 

[Viktor Jaep]

Hi again!

Today I've been doing some testing. Sadly I've been unable to re label the NTFS, which was no labeled during its creation, partition located on my /dev/sda device (sda1).

I've tried the following:

1.- The command you provided as for testing purposes only. The results are, as expected, that this command works only with ext(4?) partitions:

RTR_AX_6000# tune2fs -L ms_part /dev/sda1
tune2fs 1.45.6 (20-Mar-2020)
tune2fs: Bad magic number in super-block while trying to open /dev/sda1

2.- Installed ntfs-3g package from Entware, the install worked seamesly but, it seems that the tool I needed to change the partition label (ntfslabel) is not included, for Asus-Wrt, with the main package. While ntfs-3g runs without any problem it does not permit to re label partitions without ntfslabel tool. But, it permits to testing access to NTFS partitions, I've tried this with the "rebel" partition.

RTR_AX_6000# ntfs-3g.probe --readwrite /dev/sda1
NTFS signature is missing.

So one of the previous commands may have retired/deleted some info from the unlabeled device and/or from nvram too, but I'm not sure which of two commands was the responsible... The partitions continue the same though:

Disk /dev/sda: 4294967295 sectors, 2047G
Logical sector size: 512
Disk identifier (GUID): 800cea48-20f4-4c4e-8631-daade6f7b784
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7813969886

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34           32767       15.9M   0700  Microsoft reserved partition
   2           32768      7813965823       3725G   0700  Basic data partition

But blkid can't get any information about /dev/sda1 that could previously be retrieved with this command

RTR_AX_6000# blkid | grep sd
/dev/sda2: LABEL="Data" UUID="CE2A3E342A3E19C3"
/dev/sdb1: LABEL="rtr_swap" UUID="6ee644d7-de49-4ef3-962a-311a40ebd725"

At this point, I will go with a complete wipe of that mechanical disk and USB FlashDrive. I've bought a new SSD to use in place of FlashDrive, with just one partition. I will allocate there the swap (file) and some data, like BACKUPMON copy data. The mechanical disk will be used as SMB share again but not as backups destination or any else router related data.

Of course, after that I'll go with amtm, BACKUPMON 1.4, Skynet and AdGuardHome as soon I can.

Thanks for your all your work and support!

Absolutely! Thanks for all this great info... what a pain, all for just a label, right? Well, I'm glad you have a solid plan in place. It will be better than it was before - definitely something to look forward to! Happy Thanksgiving!

 

[ColinTaylor]

Today I've been doing some testing. Sadly I've been unable to re label the NTFS, which was no labeled during its creation, partition located on my /dev/sda device (sda1).

The MSR partition (/dev/sda1) does not contain a filesystem. Not NTFS or any other type. Therefore it cannot be given a volume label.

 

[_m4t3u_]

Absolutely! Thanks for all this great info... what a pain, all for just a label, right? Well, I'm glad you have a solid plan in place. It will be better than it was before - definitely something to look forward to! Happy Thanksgiving!

Well, I'have had to pay my AsusMerlin-Wrt noob tax... there was no way to scape, could be that problem or any other!

Keeping things simple is the best option... sometimes I forget this though... (I represent at perfection why the KISS second S is there)

However, I'm so happy with support and help received... the forum is alive and it does the problems look smaller

Happy Thanksgiving from Spain!

 

[PeterT]

The one thing I didn't like about the restore is the initial step to restore both the script and config to the /jffs/scripts directory. After one then does the initial setup you're left with two config files; one in /jffs/scripts and the other in /jffs/add-ons/...

 

[Ripshod]

The one thing I didn't like about the restore is the initial step to restore both the script and config to the /jffs/scripts directory. After one then does the initial setup you're left with two config files; one in /jffs/scripts and the other in /jffs/add-ons/...

This was dealt with several generations ago. Running the restore deletes the config file in /jffs/scripts/ just before the reboot. If your's is leaving the config file then you seriously need to update.
So now there's nothing for you to dislike.

 

[Viktor Jaep]

The one thing I didn't like about the restore is the initial step to restore both the script and config to the /jffs/scripts directory. After one then does the initial setup you're left with two config files; one in /jffs/scripts and the other in /jffs/add-ons/...

This was dealt with several generations ago. Running the restore deletes the config file in /jffs/scripts/ just before the reboot. If your's is leaving the config file then you seriously need to update.
So now there's nothing for you to dislike.

Correct, @Ripshod ... took care of that a while back. Took a while to troubleshoot and figure out there were competing .cfg files messing with the script. Seriously, at this point, just trying to make this as simple as possible to run a successful restore.

 

[PeterT]

Ah.. that's probably because I didn't actually do the restore; just the copy of the files and the initial run of setup. Surely if the initial setup run reads the "restored" config and writes it to the correct location, wouldn't it make sense to drop it then, and not wait for a restore / reboot cycle?

 

[Ripshod]

Ah.. that's probably because I didn't actually do the restore; just the copy of the files and the initial run of setup. Surely if the initial setup run reads the "restored" config and writes it to the correct location, wouldn't it make sense to drop it then, and not wait for a restore / reboot cycle?

I've got lazy. I no longer check the settings, just straight into a restore. Even if I did check the settings because the settings wouldn't need changing the two config files would be identical and not cause a problem.
If it's a great concern you could just initially copy the config file to /jffs/addons/backupmon.d/ instead. Of course you'd have to create that directory.
Or you could just copy the script on it's own and configure it manually.

 

[Viktor Jaep]

Ah.. that's probably because I didn't actually do the restore; just the copy of the files and the initial run of setup. Surely if the initial setup run reads the "restored" config and writes it to the correct location, wouldn't it make sense to drop it then, and not wait for a restore / reboot cycle?

I'm trying to make the restore process as easy as possible... by copying the main script and its config into the same folder was in my mind, the easiest way to go. It will actually go as far as copying the cfg file back into the /jffs/addons/backupmon.d/ folder, however, if your restore worked, it would have overwritten that folder with all its original contents anyways. Then the very last thing it does before it reboots, is delete the .cfg out of the /jffs/scripts folder.