BACKUPMON BACKUPMON v1.8.20 -Oct 12, 2024- Backup/Restore your Router: JFFS + NVRAM + External USB Drive! CIFS/SMB/NFS! (Thread Closed!)

[rung]

BTW... when creating a Windows share... you can add the "Everyone" group to the share name... give it read/write access. Then it doesn't need a password. Or you can just use "admin / admin" in that case. But please know... that's the "I'm going to leave the door unlocked and wide-open" insecure approach of doing things, but if you don't have curious users on your network on a mission to destroy your backups in unsecured backup folders like this, it's a good start... then start experimenting with locking things down with usernames/passwords after you get this working.

Please be sure to share a screenshot your configuration screen or /jffs/addons/backupmon.d/backupmon.cfg file, to make sure everything looks right... happy to help!

You probably already have this in your script, but I found that I needed the following in my services-start script on my AX86 Pro to get Win 10 shares to work:

#!/bin/sh
/sbin/modprobe md4

 

[ExtremeFiretop]

You probably already have this in your script, but I found that I needed the following in my services-start script on my AX86 Pro to get Win 10 shares to work:

#!/bin/sh
/sbin/modprobe md4

I do believe this is what he uses as per this post:

I use "modprobe md4"... which seems to do the trick? I'll look into your suggestion!

 

[Viktor Jaep]

I do believe this is what he uses as per this post:

Correctamundo!

 

[jksmurf]

Correctamundo!

I have the feeling @Viktor Jaep has been wanting to say that since the last season of Happy Days …

 

[Gen10]

BTW... when creating a Windows share... you can add the "Everyone" group to the share name... give it read/write access. Then it doesn't need a password. Or you can just use "admin / admin" in that case. But please know... that's the "I'm going to leave the door unlocked and wide-open" insecure approach of doing things, but if you don't have curious users on your network on a mission to destroy your backups in unsecured backup folders like this, it's a good start... then start experimenting with locking things down with usernames/passwords after you get this working.

Please be sure to share a screenshot your configuration screen or /jffs/addons/backupmon.d/backupmon.cfg file, to make sure everything looks right... happy to help!

Had no success with setting it to everyone either. Bit confusing as it seems some of the process is done on the actual router storage? Maybe its missconfigured or im overlooking something.

 

[Viktor Jaep]

View attachment 59374

Had no success with setting it to everyone either. Bit confusing as it seems some of the process is done on the actual router storage? Maybe its missconfigured or im overlooking something.

It really sounds like something might be up with the storage end. It seems to be creating other files fine... but then it bombs on the .tar file. First, try this:

Under the testing & dianostics, hit the (ts) option:

Then hit the (p) option, to import your primary backup settings... then hit (t) to test it out.

Share the output of your screen so we can see the results?

Windows 10 machine, right? Do you have any AV or anything that might be preventing .tar.gz files from writing to your harddrive? Never mind... the jffs written right before this was a tar.gz. So that's not it.

 

[Viktor Jaep]

Had no success with setting it to everyone either. Bit confusing as it seems some of the process is done on the actual router storage? Maybe its missconfigured or im overlooking something.

I suppose it could also be that your attached USBdrive is bombing out maybe due to errors? Have you taken a look at the (dcl) option under AMTM? Perhaps that might shed some light on the health of your /tmp/mnt/usbdrive device?

 

[ExtremeFiretop]

I don't mean to send us all the way back to the start. But I didn't see confirmation the network share is actually functional.

Is the created network share (Routerbackups) accessible and working from any other windows computer on the same network? (I.e test from any device other than the router and the computer it's created on)
If the share is created on computer "A", find another PC (computer "B") and open windows file explorer, and type in the network share path in the address bar or map a network drive.

This would be a good test to validate if everything is configured correctly for the network share, or if it's really a configuration issue of Backupmon.
Edit: Or an issue with the usbdrive, etc.

 

[Gen10]

I suppose it could also be that your attached USBdrive is bombing out maybe due to errors? Have you taken a look at the (dcl) option under AMTM? Perhaps that might shed some light on the health of your /tmp/mnt/usbdrive device?

View attachment 59377

 

[Gen10]

I don't mean to send us all the way back to the start. But I didn't see confirmation the network share is actually functional.

Is the created network share (Routerbackups) accessible and working from any other windows computer on the same network? (I.e test from any device other than the router and the computer it's created on)

If the share is created on computer "A", find another PC (computer "B") and open windows file explorer, and type in the network share path in the address bar or map a network drive.

This would be a good test to validate if everything is configured correctly for the network share, or if it's really a configuration issue of Backupmon.

Edit: Or an issue with the usbdrive, etc.

I actually just accesed the shared folder via my W11 PC. The share is on a W10 machine. Since I had everyone configured for access it let me right into the folder without authentication.

 

[ExtremeFiretop]

Well that rules out my theory, seems the share is functional from the router and other devices.

Back you to @Viktor Jaep

 

[Viktor Jaep]

Back you to @Viktor Jaep

Thanks buddy!!

@Gen10 ... I think it might be your USB drive. When you continually see these "recovering journal" messages, that's usually bad news. @ColinTaylor may have some better advice. I would see about taking it offline, and trying to repair it some other way. Is it a flashdrive? They typically don't hold up well. Worse comes to worst, you may need to replace it with a more capable SSD.

 

[Gen10]

Thanks buddy!!

@Gen10 ... I think it might be your USB drive. When you continually see these "recovering journal" messages, that's usually bad news. @ColinTaylor may have some better advice. I would see about taking it offline, and trying to repair it some other way. Is it a flashdrive? They typically don't hold up well. Worse comes to worst, you may need to replace it with a more capable SSD.

Funny enough it actually is an SSD. This one to be exact. https://www.amazon.com/dp/B076XMH2JT?tag=snbforums-20

I can certainly try some basic windows drive repairs on it unless there's better ways to repair.

 

[Viktor Jaep]

Funny enough it actually is an SSD. This one to be exact. https://www.amazon.com/dp/B076XMH2JT?tag=snbforums-20

I can certainly try some basic windows drive repairs on it unless there's better ways to repair.

If that's the case, then you're probably OK. Let me know if anything changes after an offline repair?

 

[Wendigogo]

Well, I didn't see anyone asking for the "ve" output.
It should tell us some important information (mine was the bad USB drive mounting point).

Enjoy!

 

[Viktor Jaep]

Well, I didn't see anyone asking for the "ve" output.
It should tell us some important information (mine was the bad USB drive mounting point).

Enjoy!

Right you are... might give some more clues. @Gen10 ... Can you post your (ve) logs please?

 

[Gen10]

Right you are... might give some more clues. @Gen10 ... Can you post your (ve) logs please?

GNU nano 7.2                                     /jffs/addons/backupmon.d/backupmonerrors.log
 1 BEGIN ERRORLOG ->
 2 Jun 11 2024 19:00:28 GT-AX6000-1337 BACKUPMON[5661] - tar: can't change directory to '/tmp/mnt/usbdrive': No such file or directory
 3 Jun 11 2024 19:00:28 GT-AX6000-1337 BACKUPMON[5661] - **ERROR**: Errors detected creating EXT Drive tar file.

Yup that was it! I derped and didn't change the USB directory as I thought only the network drive was used initially. It was set to default this whole time! Once I modified the usbdrive value to my actual directory I was able to succesfully backup.

 

[Viktor Jaep]

GNU nano 7.2                                     /jffs/addons/backupmon.d/backupmonerrors.log
 1 BEGIN ERRORLOG ->
 2 Jun 11 2024 19:00:28 GT-AX6000-1337 BACKUPMON[5661] - tar: can't change directory to '/tmp/mnt/usbdrive': No such file or directory
 3 Jun 11 2024 19:00:28 GT-AX6000-1337 BACKUPMON[5661] - **ERROR**: Errors detected creating EXT Drive tar file.

Yup that was it! I derped and didn't change the USB directory as I thought only the network drive was used initially. It was set to default this whole time! Once I modified the usbdrive value to my actual directory I was able to succesfully backup.

OMG! I'm so glad that made a lightbulb go off on your end. Thanks to @Wendigogo for doing the same to me and reminding me of this recently-implemented feature.

 

[Viktor Jaep]

I might go ahead and change the default to something that stands out more, so it's easier to identify. Like:

/tmp/mnt/<NAMEOFYOURUSBDRIVE>

or something like that.

 

[visortgw]

I might go ahead and change the default to something that stands out more, so it's easier to identify. Like:

/tmp/mnt/<NAMEOFYOURUSBDRIVE>

or something like that.

/tmp/mnt/<FILLINTHEBLANK>