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

[_m4t3u_]

I believe the reason for that is because your "usb_path1_fs_path0" is referring to sda1... but your sda1 label = null... One you put a label on that, then it won't complain on startup any longer.

I'm still trying to make sense out of all this, so thank you very much for providing this. Knowing that it's also referring to "usb_path2_fs_path0=sdb1" is very interesting.

usb_path1_fs_path0=sda1
usb_path2_fs_path0=sdb1

usb_path_sda1_label=
usb_path_sda2_label=Data
usb_path_sdb1_label=rtr_swap

Hi Viktor,

As I said yesterday, this morning I've been testing your quick beta (v1.39b1) and all seems to be working fine. I've done two different backups and modifying some BACKUPMON paths in order to detail testing of paths management. Backup files have been created as expected:

I've just seen an warning during the backup (tar: invalid option -- '2'). May be I'm wrong, but I think this warning was already appearing in previous version (v1.38) too...

[Primary Backup Commencing]...

Messages:
STATUS: External drive (USB) mounted successfully as: /XXXXXXXXXXXXXXXXXX/
STATUS: Finished backing up JFFS to /XXXXXXXXXXXXXXXXXX/GT-AX6000/Sun/jffs-20231119-095141.tar.gz.
STATUS: Finished backing up NVRAM to /XXXXXXXXXXXXXXXXXX/GT-AX6000/Sun/nvram-20231119-095141.cfg.
STATUS: Finished copying routerfw.txt to /XXXXXXXXXXXXXXX/GT-AX6000/Sun/routerfw-20231119-095141.txt.
STATUS: Starting backup of EXT Drive on Sun Nov 19 09:51:45 CET 2023. Please stand by...
tar: invalid option -- '2'
BusyBox v1.25.1 (2023-08-21 15:34:18 EDT) multi-call binary.

Usage: tar -[cxtzjhvO] [-X FILE] [-T FILE] [-f TARFILE] [-C DIR] [FILE]...

Create, extract, or list files from a tar file

Operation:
        c       Create
        x       Extract
        t       List
        f       Name of TARFILE ('-' for stdin/out)
        C       Change to DIR before operation
        v       Verbose
        z       (De)compress using gzip
        j       (De)compress using bzip2
        O       Extract to stdout
        h       Follow symlinks
        X       File with names to exclude
        T       File with names to include
STATUS: Finished backing up EXT Drive in 0 sec to /XXXXXXXXXXXXXXXXXX/GT-AX6000/Sun/ -20231119-095141.tar.gz.
STATUS: Finished copying backupmon.sh script to /XXXXXXXXXXXXXXXXXX/GT-AX6000.
STATUS: Finished copying backupmon.cfg file to /XXXXXXXXXXXXXXXXXX/GT-AX6000.
STATUS: Finished copying reference nvram.txt extract to /XXXXXXXXXXXXXXXXXX/GT-AX6000.
STATUS: Finished copying restoration instructions.txt file to /XXXXXXXXXXXXXXXXXX/GT-AX6000.
STATUS: Settling for 10 seconds...

On the other hand, yesterday you wrote "I believe the reason for that is because your "usb_path1_fs_path0" is referring to sda1... but your sda1 label = null... One you put a label on that, then it won't complain on startup any longer", Sorry but I even can't figure how I have an sda1 device ... I've managed all of that by using my router webUI... Although it seems that partition is showed only by nvram show command, and not by blkid:

RT-AX6000:/tmp/home/root# blkid
/dev/sda2: LABEL="Data" UUID="CE2A3E342A3E19C3"
/dev/sdb1: LABEL="rtr_swap" UUID="6ee644d7-de49-4ef3-962a-311a40ebd725"

Edited:
May be I have the responsible... Windows... This disk was formatted in Windows, then connected to router and enabled as SMB drive... may be this is the "partition blank name" problem...

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

Anyway, I would be pleased if you, or anyone, can tell me how to label that partition -if possible- and I'll try it. If not, no problem. All is running fine with your quick 1.39b1 version.

Thanks for all your support.

 

[Ripshod]

All is running fine with your quick 1.39b1 version

Yes, backups seem to be working fine. I wonder though how this script would react to your errant sda1 partition when it comes to restoring a backup.
The ultimate test would obviously be a restoration, but I wouldn't advise this for just a test.
An afterthought: When partitioning a drive, sometimes we'll see a gap at the start of the drive. Perhaps something is registering this gap as another (unreadable) partition. In this case a restoration could fall flat using the default method.

 

[_m4t3u_]

Yes, backups seem to be working fine. I wonder though how this script would react to your errant sda1 partition when it comes to restoring a backup.

Good question, I simply guessed up that if backup runs fine, restoration will do too, but as you said, may be I'm too much innocent...

Joking apart, for me its not a problem, but all of this consists in to improve and detect anomalies in order to solve them. I'm confident that @Viktor Jaep will manage all of that well by coding or by limiting users configurations supported.

Considering all aspects, in my concrete case, I'm pushing hard on BACKUPMON because may be it was not designed having in mind that someone will take a Windows NTFS formatted disk and attach it to the router directly and shares it by SMB. However, it is a situation that happens. If can be solved, perfect, if not no problem anyway, I can reformat the disk and start from scratch. The important thing, as you said, is to know the limits and what is or not supported.

Your question is a very good point that I haven't considered if you had not done. Thanks!

 

[Viktor Jaep]

I've just seen an warning during the backup (tar: invalid option -- '2'). May be I'm wrong, but I think this warning was already appearing in previous version (v1.38) too...

It looks like tar is bombing out because your label is null, so it doesn't know how to name the backup... you can see the issue in the logs below:

STATUS: Starting backup of EXT Drive on Sun Nov 19 09:51:45 CET 2023. Please stand by...
tar: invalid option -- '2'
STATUS: Finished backing up EXT Drive in 0 sec to /XXXXXXXXXXXXXXXXXX/GT-AX6000/Sun/ -20231119-095141.tar.gz.

You will notice a blank before that date/time... that's where your drive label name should be. So make sure your setup looks correct?

On the other hand, yesterday you wrote "I believe the reason for that is because your "usb_path1_fs_path0" is referring to sda1... but your sda1 label = null... One you put a label on that, then it won't complain on startup any longer", Sorry but I even can't figure how I have an sda1 device ... I've managed all of that by using my router webUI... Although it seems that partition is showed only by nvram show command, and not by blkid:

RT-AX6000:/tmp/home/root# blkid
/dev/sda2: LABEL="Data" UUID="CE2A3E342A3E19C3"
/dev/sdb1: LABEL="rtr_swap" UUID="6ee644d7-de49-4ef3-962a-311a40ebd725"

Edited:
May be I have the responsible... Windows... This disk was formatted in Windows, then connected to router and enabled as SMB drive... may be this is the "partition blank name" problem...

It could very well be that you can only see this through NVRAM... but your NVRAM is still referring to an sda1 device, and its label is blank. Perhaps try this command instead?

fdisk -l

At least BACKUPMON is just giving you a warning at this point, and letting you continue on... so it's definitely not stopping you, and that was the big hurdle.

Anyway, I would be pleased if you, or anyone, can tell me how to label that partition -if possible- and I'll try it. If not, no problem. All is running fine with your quick 1.39b1 version.

Totally experimental... and not sure if this would work (or if it's even recommended), but I found this:

tune2fs –L ROOT_PART /dev/sda1

 

[Viktor Jaep]

Until @Viktor Jaep can make the script more flexible to various SMB versions, you can always edit the script, find the mount command and change the version to 2.0.

To let people pick from a list of valid SMB versions for backward compatibility... I'm going to assume these would be all the supported choices... are there any other variations you know of?

1.0
2.0
2.1

I don't think our routers can handle v3.0 yet if I'm not mistaken. The GT-AX6000 is running samba version 3.6.25, which tells me only supports SMBv2.

 

[vaboro]

I don't think our routers can handle v3.0 yet if I'm not mistaken.

From what I can infer from our earlier discussion SMB clients on both your GT-AX6000 and AC86U could connect to SMB v2.1 server on your NAS at 192.168.86.9; whereas both GT-AC2900 and AX86U have SMB v2 servers supported by firmware. IMHO, one strategy could be to start to connect SMB client to SMB server with vers=3.0 and if it fails try the next lower version.

 

[Viktor Jaep]

Until @Viktor Jaep can make the script more flexible to various SMB versions, you can always edit the script, find the mount command and change the version to 2.0.

There's no need... I've added the SMB version as a selectable option in this latest beta... v2.1 is being used as default. Please give it a whirl, @vaboro... Just FYI... I tested this on my Windows Server share, and it doesn't like v1.0 or v2.0... the lowest allowable for it is v2.1.

What's new?
v1.39b2 - (TBA)
- 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:

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

Significant Screenshots:

Showing the menu #9 item allowing you to pick which version of the CIFS/SMB protocol you want to use:

 

[Ripshod]

Good work. SMB2.1 working fine on RT-AX88U

 

[Viktor Jaep]

From what I can infer from our earlier discussion SMB clients on both your GT-AX6000 and AC86U could connect to SMB v2.1 server on your NAS at 192.168.86.9; whereas both GT-AC2900 and AX86U have SMB v2 servers supported by firmware. IMHO, one strategy could be to start to connect SMB client to SMB server with vers=3.0 and if it fails try the next lower version.

Based on the version of Samba (v3.6.25) running on my router, it doesn't look like I could even get it to work with SMBv3.0. I believe you need to have Samba v4.0 or above to support SMBv3.

 

[Jeffrey Young]

There's no need... I've added the SMB version as a selectable option in this latest beta... v2.1 is being used as default. Please give it a whirl, @vaboro... Just FYI... I tested this on my Windows Server share, and it doesn't like v1.0 or v2.0... the lowest allowable for it is v2.1.

What's new?
v1.39b2 - (TBA)
- 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 and v2.1 (default). 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:

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

Significant Screenshots:

Showing the menu #9 item allowing you to pick which version of the CIFS/SMB protocol you want to use:
View attachment 54319

Like I didn't know you working on this!!!

 

[Jeffrey Young]

To let people pick from a list of valid SMB versions for backward compatibility... I'm going to assume these would be all the supported choices... are there any other variations you know of?

1.0
2.0
2.1

I don't think our routers can handle v3.0 yet if I'm not mistaken. The GT-AX6000 is running samba version 3.6.25, which tells me only supports SMBv2.

Have a look here; https://4sysops.com/archives/the-smb-protocol-all-you-need-to-know/

Few other resources available to....

 

[ColinTaylor]

Based on the version of Samba (v3.6.25) running on my router, it doesn't look like I could even get it to work with SMBv3.0. I believe you need to have Samba v4.0 or above to support SMBv3.

The cifs module on my RT-AX86U works fine for SMB 3.0 and 3.02.

 

[_m4t3u_]

It looks like tar is bombing out because your label is null, so it doesn't know how to name the backup... you can see the issue in the logs below:

You will notice a blank before that date/time... that's where your drive label name should be. So make sure your setup looks correct?

Well... considering all I've discovered since yesterday I'm not sure about anything...
Actually, I think my setup is correct, the problem is mostly to have reused a Windows NTFS formatted drive... I can change that, just need to move some data and then re format the drive.

Before re formatting I would like to give a try to your "experimental" command " tune2fs –L ROOT_PART /dev/sda1: or may be, as it is an NTFS partition ntfslabel /dev/sda5 NEW_LABEL. I'll report after testing those commands, maybe this can help other colleagues with same problem.

It could very well be that you can only see this through NVRAM... but your NVRAM is still referring to an sda1 device, and its label is blank. Perhaps try this command instead?

fdisk -l

As you said, "fdisk -l" gives the info we're discussing about, it shows the sda1 "phantom" partition:

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

At least BACKUPMON is just giving you a warning at this point, and letting you continue on... so it's definitely not stopping you, and that was the big hurdle.

Sure!!! BACKUPMON is doing its job much better than me...

Thanks again for your time, knowledge sharing and patience @Viktor Jaep

 

[Viktor Jaep]

The cifs module on my RT-AX86U works fine for SMB 3.0 and 3.02.

That's really interesting! I assumed looking at /tmp/etc/smb.conf, that this was controlling the max allowable SMB protocol version:

max protocol = SMB2

But you're right... just tested it with 3.0 and 3.02, and both worked! Dayum.

 

[Viktor Jaep]

Have a look here; https://4sysops.com/archives/the-smb-protocol-all-you-need-to-know/

Few other resources available to....

Thank you - I had run across that one as well. So now I'm really confused, because this older Samba version present on my router apparently supports newer protocols. LOL. No idea.

 

[ColinTaylor]

That's really interesting! I assumed looking at /tmp/etc/smb.conf, that this was controlling the max allowable SMB protocol version:

max protocol = SMB2

But you're right... just tested it with 3.0 and 3.02, and both worked! Dayum.

The cifs filesytem kernel module has nothing to do with the Samba server config.

 

[Viktor Jaep]

Well... considering all I've discovered since yesterday I'm not sure about anything...
Actually, I think my setup is correct, the problem is mostly to have reused a Windows NTFS formatted drive... I can change that, just need to move some data and then re format the drive.

Before re formatting I would like to give a try to your "experimental" command " tune2fs –L ROOT_PART /dev/sda1: or may be, as it is an NTFS partition ntfslabel /dev/sda5 NEW_LABEL. I'll report after testing those commands, maybe this can help other colleagues with same problem.

I'd love to hear about your experience!

Sure!!! BACKUPMON is doing its job much better than me...

Thanks again for your time, knowledge sharing and patience @Viktor Jaep

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

 

[Viktor Jaep]

The cifs filesytem kernel module has nothing to do with the Samba server config.

Great to know... thanks for that info!

 

[SomeWhereOverTheRainBow]

Great to know... thanks for that info!

I think every one is motivated (even the other furniture) to see your success with BACKUPMON. You are doing great stuff here. Keep it up!

 

[Viktor Jaep]

There's no need... I've added the SMB version as a selectable option in this latest beta... v2.1 is being used as default. Please give it a whirl, @vaboro... Just FYI... I tested this on my Windows Server share, and it doesn't like v1.0 or v2.0... the lowest allowable for it is v2.1.

What's new?
v1.39b2 - (TBA)
- 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 and v2.1 (default). 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:

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

Significant Screenshots:

Showing the menu #9 item allowing you to pick which version of the CIFS/SMB protocol you want to use:
View attachment 54319

Beta2 has been updated to add support for SMB v3.0 and v3.02... many thanks to @ColinTaylor!

Download link:

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