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

[Jeffrey Young]

How can that be? With the mount point being the same as where the NFS mount point would end up?.

Mountd is just the daemod that handles NFS shares. If you turn on NFS from the server centre, the deamon gets started for you. Otherwise you have to start it. You still have to mount the actual share.

 

[Viktor Jaep]

Mountd is just the daemod that handles NFS shares. If you turn on NFS from the server centre, the deamon gets started for you. Otherwise you have to start it. You still have to mount the actual share.

If you wouldn't mind, @Jeffrey Young, could you please share a short procedure how you'd perform an NFS backup in part with backupmon? I'd be fascinated to see how?

 

[Jeffrey Young]

If you wouldn't mind, @Jeffrey Young, could you please share a short procedure how you'd perform an NFS backup in part with backupmon? I'd be fascinated to see how?

I would create a new script (wrapper) with something like....

#!/bin/sh

<Code to mount the NFS Share>
<Code to call BACKUPMON as a one-time call to back up the Router>
<Code to unmount the share (unless it is a permanently mounted point)>

Then call the wrapper script via a cron job.

I'll be honest and say I have not tried downloading your tool or even looked at it in any detail. I like to know what is happening under the hood and also to keep things simple, so I have kept to my script (Although I have modified my script to encode the password so that special characters can be used in the password and I now only keep the last 10 days of backups). So, I don't know if you can configure BACKUPMON so that when started manually it will just make a backup and then quit. If It can, then the above is likely how I would do it.

 

[Viktor Jaep]

I would create a new script (wrapper) with something like....

#!/bin/sh

<Code to mount the NFS Share>
<Code to call BACKUPMON as a one-time call to back up the Router>
<Code to unmount the share (unless it is a permanently mounted point)>

Then call the wrapper script via a cron job.

I'll be honest and say I have not tried downloading your tool or even looked at it in any detail. I like to know what is happening under the hood and also to keep things simple, so I have kept to my script (Although I have modified my script to encode the password so that special characters can be used in the password and I now only keep the last 10 days of backups). So, I don't know if you can configure BACKUPMON so that when started manually it will just make a backup and then quit. If It can, then the above is likely how I would do it.

So would you basically use the same mountpoint... if you created an NFS share, using a local /tmp/mnt/nfsshare mount point on the router, then you would specify that same mount point path in BACKUPMON? I'm just wondering what backupmon would do at the time of backup, because it's going to try to force a cifs mount to that same mountpoint before it starts a backup?

And no worries... But yes, when you just execute "backupmon" by itself, it launches a regular backup and quits. Launching "backupmon -backup" will additionally launch a purge old backups job after backup completes.

 

[Jeffrey Young]

I'm just wondering what backupmon would do at the time of backup, because it's going to try to force a cifs mount to that same mountpoint before it starts a backup?

Sorry, my bad here. I thought I had read somewhere that BACKUPMON now had the option of specifying a required mount point (requiring an smb call) or just specifying a directory to where the backup is to go (i.e. assume the backup destination already exists).

If that is not the case, then yep, that's a problem.

 

[Viktor Jaep]

I supposed I could create an option that would not attempt cifs mounts, and leaves everything else alone... like a "NFS" option, but will rely on the user to ensure that the mount points are all configured correctly. @smarthome-enthusiast ... would something like that work for you?

 

[Jeffrey Young]

It is the downside of applying automation to a task. You can never cover 100% of the cases/configurations out in the wild.

 

[Viktor Jaep]

Sorry, my bad here. I thought I had read somewhere that BACKUPMON now had the option of specifying a required mount point (requiring an smb call) or just specifying a directory to where the backup is to go (i.e. assume the backup destination already exists).

Actually... I take it back... if the mount point already exists, backupmon will happily bypass creating a CIFS mount point. So theoretically, yes... it could work if that mount point was already in existence and created using NFS. But at the end of the backup, it will try to dismount it. So it sounds like it would need some work to get this to function correctly.

But thinking about this more... if your NFS mount point is already in place, choosing the "USB" option in backupmon will not mess with mount points, and will leave them alone and not unmount them in the end. So this actually could be a simple fix of just calling it "USB/NFS". Lol

@smarthome-enthusiast ... wanna give that a try?

 

[Jeffrey Young]

But thinking about this more... if your NFS mount point is already in place, choosing the "USB" option in backupmon will not mess with mount points, and will leave them alone and not unmount them in the end. So this actually could be a simple fix of just calling it "USB/NFS". Lol

I knew I read it somewhere in the thread..... I'm not going crazy!! Now, I just need to convince my wife of that!!

 

[Viktor Jaep]

I knew I read it somewhere in the thread..... I'm not going crazy!! Now, I just need to convince my wife of that!!

If you need any recommendation letters to help with that, I'd be happy to oblige!

 

[pianopete]

Hi.

I'm getting this message in my log files:

Mar 10 2024 17:54:34 RT-AC68U-D230 BACKUPMON[8850] - INFO: External drive (USB) mounted successfully as: /tmp/mnt/RouterBackup
Mar 10 2024 17:54:48 RT-AC68U-D230 BACKUPMON[8850] - INFO: Finished backing up JFFS to /tmp/mnt/RouterBackup/router/RT-AC68U-Backup/Sun/jffs.>
Mar 10 2024 17:54:50 RT-AC68U-D230 BACKUPMON[8850] - INFO: Finished integrity check for /tmp/mnt/RouterBackup/router/RT-AC68U-Backup/Sun/jffs>
Mar 10 2024 17:54:50 RT-AC68U-D230 BACKUPMON[8850] - INFO: Finished backing up NVRAM to /tmp/mnt/RouterBackup/router/RT-AC68U-Backup/Sun/nvra>
Mar 10 2024 17:54:51 RT-AC68U-D230 BACKUPMON[8850] - INFO: Finished copying routerfw.txt to /tmp/mnt/RouterBackup/router/RT-AC68U-Backup/Sun/>
Mar 10 2024 17:54:52 RT-AC68U-D230 BACKUPMON[8850] - INFO: Starting backup of EXT Drive on Sun Mar 10 17:54:52 DST 2024
Mar 10 2024 17:57:21 RT-AC68U-D230 BACKUPMON[8850] - **ERROR**: Errors detected creating EXT Drive tar file.

However, in the backup directories, the tar files are present:

-rwxrwxrwx    1 xxxx xxxx       5459987 Mar 10 17:54 jffs.tar.gz
-rwxrwxrwx    1 xxxx xxxx         63496 Mar 10 17:54 nvram.cfg
-rwxrwxrwx    1 xxxx xxxx            53 Mar 10 17:54 routerfw.txt
-rwxrwxrwx    1 xxxx xxxx      52347383 Mar 10 17:57 usb3.tar.gz

The backups are to an attached USB stick, nothing fancy, plenty of space. I couldn't find any similar reports on the net. Any advice on how to trouble shoot this please ?

Running 386.12_6 firmware and 1.5.13 version of backupmon.

Cheers
Pete

 

[Viktor Jaep]

Hi.

I'm getting this message in my log files:

Mar 10 2024 17:54:34 RT-AC68U-D230 BACKUPMON[8850] - INFO: External drive (USB) mounted successfully as: /tmp/mnt/RouterBackup
Mar 10 2024 17:54:48 RT-AC68U-D230 BACKUPMON[8850] - INFO: Finished backing up JFFS to /tmp/mnt/RouterBackup/router/RT-AC68U-Backup/Sun/jffs.>
Mar 10 2024 17:54:50 RT-AC68U-D230 BACKUPMON[8850] - INFO: Finished integrity check for /tmp/mnt/RouterBackup/router/RT-AC68U-Backup/Sun/jffs>
Mar 10 2024 17:54:50 RT-AC68U-D230 BACKUPMON[8850] - INFO: Finished backing up NVRAM to /tmp/mnt/RouterBackup/router/RT-AC68U-Backup/Sun/nvra>
Mar 10 2024 17:54:51 RT-AC68U-D230 BACKUPMON[8850] - INFO: Finished copying routerfw.txt to /tmp/mnt/RouterBackup/router/RT-AC68U-Backup/Sun/>
Mar 10 2024 17:54:52 RT-AC68U-D230 BACKUPMON[8850] - INFO: Starting backup of EXT Drive on Sun Mar 10 17:54:52 DST 2024
Mar 10 2024 17:57:21 RT-AC68U-D230 BACKUPMON[8850] - **ERROR**: Errors detected creating EXT Drive tar file.

However, in the backup directories, the tar files are present:

-rwxrwxrwx    1 xxxx xxxx       5459987 Mar 10 17:54 jffs.tar.gz
-rwxrwxrwx    1 xxxx xxxx         63496 Mar 10 17:54 nvram.cfg
-rwxrwxrwx    1 xxxx xxxx            53 Mar 10 17:54 routerfw.txt
-rwxrwxrwx    1 xxxx xxxx      52347383 Mar 10 17:57 usb3.tar.gz

The backups are to an attached USB stick, nothing fancy, plenty of space. I couldn't find any similar reports on the net. Any advice on how to trouble shoot this please ?

Running 386.12_6 firmware and 1.5.13 version of backupmon.

Cheers
Pete

Hey @pianopete! Couple of questions...

1.) Does it do this each time you back up?
2.) Are you able to open your usb3.tar.gz file successfully?
3.) Looking at AMTM -> dcl ... are you seeing any USB drive errors?

If able... could you run a manual integrity check against this file and let me know what it returns?

tar -tzf /tmp/mnt/RouterBackup/router/RT-AC68U-Backup/Sun/usb3.tar.gz

 

[pianopete]

Hi Viktor.

Hey @pianopete! Couple of questions...

1.) Does it do this each time you back up?

Started on 4th March with a JFFS error:

**ERROR**: Errors detected creating JFFS tar file.

then the errors for the usb tar file started 2 days ago and I've had three episodes of that message (the last one being a manual attempt).

2.) Are you able to open your usb3.tar.gz file successfully?

Yes - tar tzf gives what appears to be a full listing (although I haven't checked if any files are missing).

No errors from the tar command.

3.) Looking at AMTM -> dcl ... are you seeing any USB drive errors?

I wasn't running the disk checker. I've installed it now but not sure how to run it (it looks like it runs on reboot).

If able... could you run a manual integrity check against this file and let me know what it returns?

Assume you mean the shell command return ?

tar tzf usb3.tar.gz 
[LOTS OF OUTPUT]
# echo $?
0

Hope this helps, and thanks for the rapid reply!
Pete

 

[Viktor Jaep]

Started on 4th March with a JFFS error:

**ERROR**: Errors detected creating JFFS tar file.

then the errors for the usb tar file started 2 days ago and I've had three episodes of that message (the last one being a manual attempt).

Sounds like possibly cascading USB drive errors might be causing this...

I wasn't running the disk checker. I've installed it now but not sure how to run it (it looks like it runs on reboot).

Definitely interested to see the results of "dcl" after you do reboot

Assume you mean the shell command return ?

tar tzf usb3.tar.gz
[LOTS OF OUTPUT]
# echo $?
0

Well I was hoping to see something more here... there were no errors somewhere within the [LOTS OF OUTPUT] section? The error you were getting was due to this command returning a "1" (error) determining the validity of this file...

Hopefully just a bad USB drive... that can hopefully be repaired... but be prepared for the worst, and may need to replace in the near future. Usually once your USB drive starts displaying integrity issues like this, it's only a matter of time.

 

[pianopete]

Sounds like possibly cascading USB drive errors might be causing this...

OK - I've ordered a couple of replacement drives.

Definitely interested to see the results of "dcl" after you do reboot

I'll try to do this tomorrow.

Well I was hoping to see something more here... there were no errors somewhere within the [LOTS OF OUTPUT] section? The error you were getting was due to this command returning a "1" (error) determining the validity of this file...

Well I redirected stdout to null and nothing came out on stderr.

I'm running a batch on all of the usb3.tar.gz files on the usb drive to check the return value.

Question: is there a way to increase the verbosity of the error log messages ?

Hopefully just a bad USB drive... that can hopefully be repaired... but be prepared for the worst, and may need to replace in the near future. Usually once your USB drive starts displaying integrity issues like this, it's only a matter of time.

As above, replacement on the way!


Pete

 

[pianopete]

I'm running a batch on all of the usb3.tar.gz files on the usb drive to check the return value.

All of the exit codes for the usb3.tar.gz came back as 0. one of the jffs.tar.gz came back with '1' and the message:

"tar: short read"

My guess is that you're correct - I'm seeing my USB drive deteriorating. I'll see what happens on the reboot, but I'm putting this down to a bad USB drive.

Pete

 

[Viktor Jaep]

All of the exit codes for the usb3.tar.gz came back as 0. one of the jffs.tar.gz came back with '1' and the message:

"tar: short read"

My guess is that you're correct - I'm seeing my USB drive deteriorating. I'll see what happens on the reboot, but I'm putting this down to a bad USB drive.

Pete

Definitely recommend going the SSD + Enclosure route if you are going to be replacing your flashdrive... they're relatively cheap and much better able to handle the demands made on the EXT USB drive.

 

[pianopete]

Definitely recommend going the SSD + Enclosure route if you are going to be replacing your flashdrive... they're relatively cheap and much better able to handle the demands made on the EXT USB drive.

I have a spare 128Gb SSD so I've ordered an enclosure for that. Thanks for the advice.

This was the result of a disk check after reboot:

disk_check.log has this content:

 START FILE
_____________________________________________
 Mon Mar 11 11:35:33 DST 2024 Waited 2s for NTP to sync date
 Mon Mar 11 11:35:33 DST 2024 Probing 'ntfs' on device /dev/sdb
 Running disk check with command 'ntfsck -a' on /dev/sdb
 ntfsck 3017.7.18.13
 Checking NTFS Superblock ...
 Device name        : /dev/sdb
 NTFS volume version: 3.1
 Cluster size       : 4096 bytes
 Current volume size: 15376314880 bytes (15377 MB)
100.00 percent completedd
100.00 percent completedd
100.00 percent completedd
 Done NTFS checking and repair on device '/dev/sdb'.
 Syncing device ...
 Mon Mar 11 11:35:40 DST 2024 Disk check done on /dev/sdb
 
 Mon Mar 11 11:35:58 DST 2024 Probing 'ext4' on device /dev/sda1
 Running disk check with command 'e2fsck -p' on /dev/sda1
 usb3: recovering journal
 usb3: clean, 2397/3760128 files, 898772/15015932 blocks
 Mon Mar 11 11:36:09 DST 2024 Disk check done on /dev/sda1
_____________________________________________

 END FILE
_____________________________________________

 

[Viktor Jaep]

I have a spare 128Gb SSD so I've ordered an enclosure for that. Thanks for the advice.

This was the result of a disk check after reboot:

disk_check.log has this content:

 START FILE
_____________________________________________
 Mon Mar 11 11:35:33 DST 2024 Waited 2s for NTP to sync date
 Mon Mar 11 11:35:33 DST 2024 Probing 'ntfs' on device /dev/sdb
 Running disk check with command 'ntfsck -a' on /dev/sdb
 ntfsck 3017.7.18.13
 Checking NTFS Superblock ...
 Device name        : /dev/sdb
 NTFS volume version: 3.1
 Cluster size       : 4096 bytes
 Current volume size: 15376314880 bytes (15377 MB)
100.00 percent completedd
100.00 percent completedd
100.00 percent completedd
 Done NTFS checking and repair on device '/dev/sdb'.
 Syncing device ...
 Mon Mar 11 11:35:40 DST 2024 Disk check done on /dev/sdb
 
 Mon Mar 11 11:35:58 DST 2024 Probing 'ext4' on device /dev/sda1
 Running disk check with command 'e2fsck -p' on /dev/sda1
 usb3: recovering journal
 usb3: clean, 2397/3760128 files, 898772/15015932 blocks
 Mon Mar 11 11:36:09 DST 2024 Disk check done on /dev/sda1
_____________________________________________

 END FILE
_____________________________________________

The fact that it had to recover the journal meant something was out of whack. I definitely think you'll be better off with that SSD. And if you don't need that NTFS partition, I'd keep things plain and simple, and just create one ext4 partition for the purposes of the router...

 

[pianopete]

The fact that it had to recover the journal meant something was out of whack. I definitely think you'll be better off with that SSD. And if you don't need that NTFS partition, I'd keep things plain and simple, and just create one ext4 partition for the purposes of the router...

Hi Viktor. Transferred the stuff from my 2 USB keys to the Samsung 128Gb SSD in a caddy. All seems to be working well.

However, a question - you suggested putting everything on the one partition. I've done that and now Backupmon warns me about having the backup system on the same disk (STATUS: **High Risk** -> EXT USB is backing up to EXT USB. TAR exclusion is in place.)

I understand this, hence me using a separate usb key for the backups previously. Any thoughts ? Would I be better to move the backup directory to a separate USB key in the other USB slot on my Router ?

Pete