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

[visortgw]

Based upon add-on updates and additions, I have updated my BACKUPMON exclusions file:

myswap.swp
entware/var/log/*
skynet/skynet.log
entware/var/lib/unbound/unbound.log
entware/share/uiDivStats.d/*.db
*.tar
*.gz

It appears that the uiDivStats database file can grow rather large, causing backups to be unnecessarily large and time consuming!

 

[Viktor Jaep]

New version 1.44 released tonight with an emphasis on defining error exit codes to help provide a solid integration between @ExtremeFiretop and @Martinski's MerlinAU Autoupdate Script. Before MerlinAU automatically flashes the newest firmware to your router, it will run BACKUPMON (if present) and determine if a successful backup was taken immediately prior. Thanks to both of these guys for their tremendous efforts making this all happen. It's been a pleasure working together!

What's new?
v1.44 - (January 28, 2024)
- ADDED: More error checking added on creation of TAR files to determine if the script needs to force an exit due to some possible colossal disk or network issue when writing TAR files. Changed many other error exit codes to produce something usable when looking for script success or failure when running a backup from command line (ie. the -backup switch). Honored to collaborate with @ExtremeFiretop and @Martinski with their MerlinAU script, so BACKUPMON may run and check for a successful backup prior to running an automated FW update.
- FIXED: In the setup/config, when choosing USB or Network as your target media type (option #2), it will blank out your backup target mount point (option #6), and give you a visual indication that "ACTION IS NEEDED" for this item. In certain situations, the source and target mount points could be the same name, and if the media type had "network" as the default media type, while the mount points were pointing to an External USB drive, then the USB drive would get unmounted after a backup. Many thanks to @ExtremeFiretop for finding that doozy!

Download link (or update directly from within AMTM):

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

Significant screenshots:

As shown below, in certain situations, a new Backup Target Mount Point is requested to eliminate possibly unmounting your External USB drive after a backup completes.

 

[Viktor Jaep]

Based upon add-on updates and additions, I have updated my BACKUPMON exclusions file:

myswap.swp
entware/var/log/*
skynet/skynet.log
entware/var/lib/unbound/unbound.log
entware/share/uiDivStats.d/*.db
*.tar
*.gz

It appears that the uiDivStats database file can grow rather large, causing backups to be unnecessarily large and time consuming!

Thanks @visortgw! I've come to rely on your exclusion files!

 

[visortgw]

Thanks @visortgw! I've come to rely on your exclusion files!

Yes, it took a while to figure out why my backups grew by more than a factor of 10 in size!

 

[ExtremeFiretop]

Thanks to both of these guys for their tremendous efforts making this all happen. It's been a pleasure working together!

Was an absolutely pleasure and looking forwards to keeping it up in the future!

 

[TonyK132]

Just for understanding, in addition to the External Drive and JFFS folder structures, you are looking for singular folders for specific scripts, like YazDHCP? So a compressed folder that just contains this script and it's settings folders and whatnot? How did nsru do this? Do you have any examples you might be able to share to understand these requirements a bit more please?

When I ran nsru, I would also separately copy the /opt/var/lib directory, which contains the historical data for Chrony, Unbound, and VnStat. I would also separately copy /jffs/addons/YazDHCP.d which contains the data for YazDHCP. So when I reinstalled any of those scripts, or changed the USB drive, or needed to do a nuclear reset of the router to install a recent f/w version from an old version, I could restore that dir, and my old data for those scripts would be restored. Same for the YazDHCP dir. Copying that folder made my DHCP assignments so much easier, even when I went from my AC86U to my new AX86U. But I never figured out where connmon data was stored (oh, yea, I do that also). I also never figured out where each of the scripts stored their settings so I could easily restore them, although I now think some might be stored in /opt/share. I also now think the settings for BackupMon are in /jffs/addons. So as of now, I envision the new user file would contain 4 lines: /opt/var/lib, /opt/share, /jffs/addons/YazDHCP.d, and /jffs/addons/BackupMon. Hard coding those locations would be a problem if any of those script writers decided to change any of their locations, but I figured I'd deal with that if and when that happens. But maybe there is a better way to deal with this, like maybe a common API for all amtm scripts that would identify its storage locations so BackupMon could query them and use that data. But that is obviously outside my wheelhouse. For now, just having the ability to add sub-dirs to the backup list that BackupMon uses would be a help.

 

[Ripshod]

When I ran nsru, I would also separately copy the /opt/var/lib directory, which contains the historical data for Chrony, Unbound, and VnStat. I would also separately copy /jffs/addons/YazDHCP.d which contains the data for YazDHCP. So when I reinstalled any of those scripts, or changed the USB drive, or needed to do a nuclear reset of the router to install a recent f/w version from an old version, I could restore that dir, and my old data for those scripts would be restored. Same for the YazDHCP dir. Copying that folder made my DHCP assignments so much easier, even when I went from my AC86U to my new AX86U. But I never figured out where connmon data was stored (oh, yea, I do that also). I also never figured out where each of the scripts stored their settings so I could easily restore them, although I now think some might be stored in /opt/share. I also now think the settings for BackupMon are in /jffs/addons. So as of now, I envision the new user file would contain 4 lines: /opt/var/lib, /opt/share, /jffs/addons/YazDHCP.d, and /jffs/addons/BackupMon. Hard coding those locations would be a problem if any of those script writers decided to change any of their locations, but I figured I'd deal with that if and when that happens. But maybe there is a better way to deal with this, like maybe a common API for all amtm scripts that would identify its storage locations so BackupMon could query them and use that data. But that is obviously outside my wheelhouse. For now, just having the ability to add sub-dirs to the backup list that BackupMon uses would be a help.

Is all that really necessary though? All those are included in the normal backup and are easily extracted and uploaded seperately.

 

[visortgw]

Is all that really necessary though? All those are included in the normal backup and are easily extracted and uploaded separately.

My thought exactly late last night when I read this. BACKUPMON archives EVERYTHING from NVRAM, /jffs and the USB drive.

 

[Viktor Jaep]

Is all that really necessary though? All those are included in the normal backup and are easily extracted and uploaded seperately.

My thought exactly late last night when I read this. BACKUPMON archives EVERYTHING from NVRAM, /jffs and the USB drive.

Likewise, @TonyK132... agree with the above. Everything is there in its entirety inside these tar.gz files. You can easily find these specific apps/folders/subfolders in order to pick and choose what files you'd want to extract to restore certain functionality or settings. In the most ideal situation, as what @JGrana just experienced... you'd want to restore these backups in their entirety back to your router, and you won't lose anything. All your scripts and settings will start as if nothing ever happened on reboot.

 

[visortgw]

Likewise, @TonyK132... agree with the above. Everything is there in its entirety inside these tar.gz files. You can easily find these specific apps/folders/subfolders in order to pick and choose what files you'd want to extract to restore certain functionality or settings. In the most ideal situation, as what @JGrana just experienced... you'd want to restore these backups in their entirety back to your router, and you won't lose anything. All your scripts and settings will start as if nothing ever happened on reboot.

Just for an example, as I was trying to wrap my head around @TonyK132's original post, I did the following on my MacBook Pro to verify what I thought was in the archives:

1. Copy tarball.tar.gz file from my NAS to empty folder (e.g. , Expand) on my MBP Desktop.
2. Open Terminal on MPB, and navigate to folder: $ cd Desktop/Expand/
3. Extract tarball: $ gunzip tarball.tar.gz
4. Extract directories/files from tarball: $ tar -xvf tarball.tar.gz

You can do similar on the router itself, a Linux workstation, or WIndows PC using the appropriate tools.

 

[Viktor Jaep]

Just for an example, as I was trying to wrap my head around @TonyK132's original post, I did the following on my MacBook Pro to verify what I thought was in the archives:

1. Copy tarball.tar.gz file from my NAS to empty folder (e.g. , Expand) on my MBP Desktop.
2. Open Terminal on MPB, and navigate to folder: $ cd Desktop/Expand/
3. Extract tarball: $ gunzip tarball.tar.gz
4. Extract directories/files from tarball: $ tar -xvf tarball.tar.gz

You can do similar on the router itself, a Linux workstation, or WIndows PC using the appropriate tools.

Yep! In Windows, you can literally browse and open the tar.gz files directly from Windows Explorer... and you can browse their contents as if they're folders on your PC. It's truly a walk in the park to find and extract any files you need from these master backup files. I don't see any real need to change this.

 

[TonyK132]

OK, OK. Based on your pushback emails, I started exploring the directory mappings to find the sub-dirs that are important to me. I'll figure this out for myself.

 

[Viktor Jaep]

OK, OK. Based on your pushback emails, I started exploring the directory mappings to find the sub-dirs that are important to me. I'll figure this out for myself.

The hardest part is determining where all the supporting script files are located. Luckily the bulk are under /jffs/scripts and /jffs/addons

 

[visortgw]

OK, OK. Based on your pushback emails, I started exploring the directory mappings to find the sub-dirs that are important to me. I'll figure this out for myself.

Not pushback, but rather providing you the detailed info so that you can succeed!

 

[TonyK132]

The hardest part is determining where all the supporting script files are located. Luckily the bulk are under /jffs/scripts and /jffs/addons

The historical data files are in the /opt/var/lib sub-dir. You do not copy that location. But it looks like that gets mapped to \entware\var\lib\ which you do copy.

 

[Viktor Jaep]

The historical data files are in the /opt/var/lib sub-dir. You do not copy that location. But it looks like that gets mapped to \entware\var\lib\ which you do copy.

Interesting... So yeah, Backupmon basically copies the raw data across directly from the Ext USB drive and JFFS... I'm sure the OS itself has lots of these types of virtual directories that could come over with the contents of these folders and the actual router .cfg file. When these pieces are restored, everything comes back over as it was before.

 

[visortgw]

Interesting... So yeah, Backupmon basically copies the raw data across directly from the Ext USB drive and JFFS... I'm sure the OS itself has lots of these types of virtual directories that could come over with the contents of these folders and the actual router .cfg file. When these pieces are restored, everything comes back over as it was before.

Yes, multiple levels of symbolic links:

opt -> tmp/opt​

tmp/opt -> /tmp/mnt/USBDRIVE/entware​

​

So /opt/var/lib equates to /tmp/mnt/USBDRIVE/entware/var/lib.

 

[Viktor Jaep]

Yes, multiple levels of symbolic links:

opt -> tmp/opt
tmp/opt -> /tmp/mnt/USBDRIVE/entware
So /opt/var/lib equates to /tmp/mnt/USBDRIVE/entware/var/lib.

"symbolic links"... that's what they're coined... thank you! Great info!

 

[Ripshod]

@Viktor Jaep I believe I'm seeing similar. Occasionally a daily backup will not be done, I only noticed last night when moving data from one raid to another. It's seems like something else may be resetting the cron list, losing the backupmon entry as well as other entries. I'll dig a little deeper for you when I next see it (not) happen.

@Viktor Jaep it happened again. No backup this morning and missing cron jobs.
AT the exact time of the backup cron my log went absolutely berserk with

Jan 31 01:15:03 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4
Jan 31 01:15:03 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4
Jan 31 01:15:03 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4

Then from 04:58Z

Jan 31 04:58:42 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4
Jan 31 04:58:42 ripshod kernel: jffs2: read_cache_page() returned error: -5
Jan 31 04:58:42 ripshod kernel: jffs2: Error garbage collecting node at 02970fa4!
Jan 31 04:58:42 ripshod kernel: jffs2: No space for garbage collection. Aborting GC thread
Jan 31 04:59:55 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4
Jan 31 04:59:55 ripshod kernel: jffs2: read_cache_page() returned error: -5
Jan 31 04:59:55 ripshod kernel: jffs2: Error garbage collecting node at 02970fa4!
Jan 31 05:00:02 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4
Jan 31 05:00:02 ripshod kernel: jffs2: read_cache_page() returned error: -5
Jan 31 05:00:02 ripshod kernel: jffs2: Error garbage collecting node at 02970fa4!
Jan 31 05:00:06 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4
Jan 31 05:00:06 ripshod kernel: jffs2: read_cache_page() returned error: -5

Which continues 3 or 4 times a minute and is still erroring now, 7.5 hours later, with absolutely nothing else being logged.

Do you think this is related? Is something hardware-wise failing?

 

[ColinTaylor]

@Viktor Jaep it happened again. No backup this morning and missing cron jobs.
AT the exact time of the backup cron my log went absolutely berserk with

Jan 31 01:15:03 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4
Jan 31 01:15:03 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4
Jan 31 01:15:03 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4

Then from 04:58Z

Jan 31 04:58:42 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4
Jan 31 04:58:42 ripshod kernel: jffs2: read_cache_page() returned error: -5
Jan 31 04:58:42 ripshod kernel: jffs2: Error garbage collecting node at 02970fa4!
Jan 31 04:58:42 ripshod kernel: jffs2: No space for garbage collection. Aborting GC thread
Jan 31 04:59:55 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4
Jan 31 04:59:55 ripshod kernel: jffs2: read_cache_page() returned error: -5
Jan 31 04:59:55 ripshod kernel: jffs2: Error garbage collecting node at 02970fa4!
Jan 31 05:00:02 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4
Jan 31 05:00:02 ripshod kernel: jffs2: read_cache_page() returned error: -5
Jan 31 05:00:02 ripshod kernel: jffs2: Error garbage collecting node at 02970fa4!
Jan 31 05:00:06 ripshod kernel: jffs2: Data CRC 075e7209 != calculated CRC 7d16ee8b for node at 02970fa4
Jan 31 05:00:06 ripshod kernel: jffs2: read_cache_page() returned error: -5

Which continues 3 or 4 times a minute and is still erroring now, 7.5 hours later, with absolutely nothing else being logged.

Do you think this is related? Is something hardware-wise failing?

That error can sometimes indicate that the jffs partition is full, or becoming full. Sometimes a reboot will sort it out. Otherwise examine what processes you have that might be writing to jffs.

If it's not that then your jffs filesystem will probably need to be reformatted.