NVRAM [Release] NVRAM Save/Restore Utility

[latenitetech]

@L&LD does have a good point. Updating the source router to the same firmware first may be less risky. For example, nvram vars dhcp_staticlist and dhcp_hostnames had changes in 384.13 that may not convert properly. But let me know your experience.

So, my experience ...
Using the migrate function of NSRU actually worked quite well, even between FW instances 2 yrs apart. In total I had about a half-dozen issues to be resolved, and found an additional 3 problems in the NSRU tool itself. I will post a separate note with those details so it's not lost here.

I did have an issue with dnsmasq, but it wasn't the concern you raised above with dhcp_staticlist. Even though NSRU loaded the "old format" dhcp_staticlist from 380, upon boot, the new FW automagically converted to the two new dhcp_staticlist and dhcp_hostnames so all of my previous reserved IPs transferred fine. My issue was with a custom 'dnsmasq.conf.add' where I set some non-expiring (i.e. infinite) leases. The technique that worked in 380 and earlier caused dnsmasq to exit and restart (rolling), but I figured out an easy fix that involved moving that customization to a 'dnsmasq.postconf' that now works under 384.17.

My other major issue was with openvpn server and related firewall customization associated with the changes made in 384 around the "Client will use VPN to access" settings. I like the new settings and logic, but it broke my old config. In the end it was a fairly simple fix, but I had to get my head back into iptables and openvpn config files, which, when you don't deal with it for a while gets really murky (at least for me).

All in all, a fairly good experience with NSRU as a restore tool. The vast majority of my system transferred in and just worked. I'm still glad I had the spare router to test on as it greatly reduced my network down time. I was able to swap in the new router (with the new FW and migrated-in settings) and observe the issues, then swap back to the old (380) and have a working network while I researched and fixed the problems. A couple of those cycles over a few days in my spare time and it all came together well.

Thanks for your (and your predecessors) work on this great tool.

 

[latenitetech]

... and found an additional 3 problems in the NSRU tool itself. I will post a separate note with those details so it's not lost ...

1) The parameter 'log_port' (the compliment to 'log_ipaddr') is missing from 'nvram-merlin.ini'. It should be added to the [System - Basic] section right below 'log_ipaddr.' Once added, that parameter transfers fine.

2) Your POSIX change on line 712 of 'nvram-save.sh' broke the proper handling of parameters that are prefixed with '@' , causing none of them to be backed up. Restoring the non-POSIX version of that line on 711 fixes it temporarily.

3) Your POSIX changes on lines 812 and 815 of 'nvram-save.sh' broke the proper handling of embedded newlines in parameter values. Restoring the non-POSIX versions of those lines on 811 and 814 fixes it temporarily. It bit me on the parameter 'vpn_server_custom' causing the generated 'nvram-restore- …' script to abort at that point.

Here is what that script looks like when processing that parameter with your POSIX changes:

($op || grep -q "vpn_server_custom" "$tmpfile") && $(nvram set vpn_server_custom="$(printf '
' "username-as-common-name
reneg-sec 604800           #7 days
keepalive 15 120
mute-replay-warnings")") || printf '
' "Skipping vpn_server_custom"($op || grep -q "vpn_server_dhcp" "$tmpfile") && $(nvram set vpn_server_dhcp="1") || printf '%s\n' "Skipping vpn_server_dhcp"

I believe the fatal issue is a missing newline causing the subject line and the next line to run together, but the entire entry is kludgy (even though it may work) compared to the old code:

($op || grep -q "vpn_server_custom" "$tmpfile") && $(nvram set vpn_server_custom="$(echo -e "username-as-common-name\nreneg-sec 604800           #7 days\nkeepalive 15 120\nmute-replay-warnings")") || printf '%s\n' "Skipping vpn_server_custom"

Now it turns out chasing that error was a red herring for me as the parameter 'vpn_server_custom' is deprecated in FW 384 replaced by 'vpn_serverN_cust2' (a base64-encoded version of the field). But I recommend fixing NSRU anyway as that block of code is meant to be a general "special handling" for any parameters that happen to have embedded newlines.

Hopefully easy fixes so that the next guy who happens to run those legs of code will do so error-free!

 

[Xentrk]

1) The parameter 'log_port' (the compliment to 'log_ipaddr') is missing from 'nvram-merlin.ini'. It should be added to the [System - Basic] section right below 'log_ipaddr.' Once added, that parameter transfers fine.

2) Your POSIX change on line 712 of 'nvram-save.sh' broke the proper handling of parameters that are prefixed with '@' , causing none of them to be backed up. Restoring the non-POSIX version of that line on 711 fixes it temporarily.

3) Your POSIX changes on lines 812 and 815 of 'nvram-save.sh' broke the proper handling of embedded newlines in parameter values. Restoring the non-POSIX versions of those lines on 811 and 814 fixes it temporarily. It bit me on the parameter 'vpn_server_custom' causing the generated 'nvram-restore- …' script to abort at that point.

Here is what that script looks like when processing that parameter with your POSIX changes:

($op || grep -q "vpn_server_custom" "$tmpfile") && $(nvram set vpn_server_custom="$(printf '
' "username-as-common-name
reneg-sec 604800           #7 days
keepalive 15 120
mute-replay-warnings")") || printf '
' "Skipping vpn_server_custom"($op || grep -q "vpn_server_dhcp" "$tmpfile") && $(nvram set vpn_server_dhcp="1") || printf '%s\n' "Skipping vpn_server_dhcp"

I believe the fatal issue is a missing newline causing the subject line and the next line to run together, but the entire entry is kludgy (even though it may work) compared to the old code:

($op || grep -q "vpn_server_custom" "$tmpfile") && $(nvram set vpn_server_custom="$(echo -e "username-as-common-name\nreneg-sec 604800           #7 days\nkeepalive 15 120\nmute-replay-warnings")") || printf '%s\n' "Skipping vpn_server_custom"

Now it turns out chasing that error was a red herring for me as the parameter 'vpn_server_custom' is deprecated in FW 384 replaced by 'vpn_serverN_cust2' (a base64-encoded version of the field). But I recommend fixing NSRU anyway as that block of code is meant to be a general "special handling" for any parameters that happen to have embedded newlines.

Hopefully easy fixes so that the next guy who happens to run those legs of code will do so error-free!

Thank you. I appreciate the feedback. I'll look into the updates over the next week.

 

[JT Strickland]

You have to update the menu. Reas this carefully.
https://www.snbforums.com/threads/release-nvram-save-restore-utility.61722/page-10#post-578143

I appreciate that tip. I was wondering what was going on with mine. It's amazing what a search turns up here.
Just what I was looking for! It is quiet on the front lines once again.
thanks again,
jts

 

[DBestman]

Hello,
Is there a reason why the installer does not support USB sticks formatted as NTFS? The documentation in the QuickStart.txt file indicates that NTFS is preferred for Windows users, but I got an error: "[*] No Compatible ext* USB Partitions Found - Exiting!".
FWIW, I modified my nsrum script to allow my ntfs partition and all seems to worked fine:

  for mounted in $(/bin/mount | grep -E "ext2|ext3|ext4|tfat|exfat|tntfs" | awk '{printf "%s - (%s)\n", $3, $1}'); do

 

[L&LD]

@DBestman, make sure you save your first post above as a favorite for when you have other issues down the line.

amtm and almost every single other supported scripts require Ext2, Ext3, or Ext4 (Ext4 with journaling preferred if router kernel supports it).

Scripts can't run from NTFS.

 

[DBestman]

@DBestman, make sure you save your first post above as a favorite for when you have other issues down the line.

amtm and almost every single other supported scripts require Ext2, Ext3, or Ext4 (Ext4 with journaling preferred if router kernel supports it).

Scripts can't run from NTFS.

Ah, so what you're saying is that even though my scripts seem to be running fine now from NTFS, I'm looking for trouble. I will bow to your wisdom and use Ext4 (once I find out how )
May I suggest to modify the documentation accordingly, so other newbs like me won't scratch their heads over this?

Thanks!!

 

[Xentrk]

Ah, so what you're saying is that even though my scripts seem to be running fine now from NTFS, I'm looking for trouble. I will bow to your wisdom and use Ext4 (once I find out how )
May I suggest to modify the documentation accordingly, so other newbs like me won't scratch their heads over this?

Thanks!!

Thanks for the feedback. That content was a carry over from the legacy version. I'll remove the references non supported formats to avoid confusion.

 

[L&LD]

@DBestman, best to do it through amtm.

The link in my signature also contains amtm Step-by-Step which may help.

If you have RMerlin 384.15_0 or later installed, just be sure to ignore the part of installing amtm in the guide above, because it is installed already.

 

[Xentrk]

I ran into another issue when using the utility built into amtm to reformat a USB and ended up having to do it manually. I forgot to report the problem though. My bad. But TLC is aware of a similar issue I reported a few months back. I formatted a USB and created 3 partitions. The first partition doesn't get labeled.

There are some free utilities for Windows that provide the ability to format and partition a USB for Linux that can also be used.

 

[L&LD]

@Xentrk, a single partition is recommended for a reason.

And, I think that issue has been fixed now too.

 

[DBestman]

@DBestman, best to do it through amtm.

Thanks, I used amtm (cool utility!) to format my drive, and all went well.

 

[TonyK132]

I ran into an issue with nvram-save where occasionally nvram-save does not complete its task. I have the following commands in a script that runs daily, but when it fails, the backup of the jffs sub-dir does not happen, and I do not get the Finished message in the logs. Any idea what's going on?

Here is the snippet of my backupRouterConfig script that I run daily via a cron job.

logger -t $sn "Started"
sh /tmp/mnt/Data/nsru/nvram-save.sh -b
logger -t $sn "Finished"
date >>/jffs/scripts/$sn.log

Here are the logs that shows nvram-save starting but not finishing.

May 26 00:13:00 RT-AC86U-1BD0 backupRouterConfig: Started
May 26 00:13:00 RT-AC86U-1BD0 nvram-save.sh: NVRAM User Save Utility - Version 30.3 POSIX Code Updates
May 26 00:13:00 RT-AC86U-1BD0 nvram-save.sh: NVRAM User Save Utility - Version 30.1 Martineau Hacked for v384.xx+!!
May 26 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Saving RT-AC86U settings from firmware 384.16_0
May 26 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Runtime options: -b
May 26 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Using standard NVRAM variable file: nvram-merlin.ini Version=30.3.0
May 26 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Running in Backup Mode

Here is an example of the logs where it finishes normally.

May 25 00:13:00 RT-AC86U-1BD0 backupRouterConfig: Started
May 25 00:13:00 RT-AC86U-1BD0 nvram-save.sh: NVRAM User Save Utility - Version 30.3 POSIX Code Updates
May 25 00:13:00 RT-AC86U-1BD0 nvram-save.sh: NVRAM User Save Utility - Version 30.1 Martineau Hacked for v384.xx+!!
May 25 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Saving RT-AC86U settings from firmware 384.16_0
May 25 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Runtime options: -b
May 25 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Using standard NVRAM variable file: nvram-merlin.ini Version=30.3.0
May 25 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Running in Backup Mode
May 25 00:13:37 RT-AC86U-1BD0 nvram-save.sh: Complete: User NVRAM saved to /tmp/mnt/Data/nsru/backup/nvram-restore-202005250013_RT-AC86U-1BD0.sh
May 25 00:13:39 RT-AC86U-1BD0 nvram-save.sh: Complete: JFFS directory saved to /tmp/mnt/Data/nsru/backup/jffs-202005250013_RT-AC86U-1BD0
May 25 00:13:40 RT-AC86U-1BD0 backupRouterConfig: Finished

 

[Xentrk]

I ran into an issue with nvram-save where occasionally nvram-save does not complete its task. I have the following commands in a script that runs daily, but when it fails, the backup of the jffs sub-dir does not happen, and I do not get the Finished message in the logs. Any idea what's going on?

Here is the snippet of my backupRouterConfig script that I run daily via a cron job.

logger -t $sn "Started"
sh /tmp/mnt/Data/nsru/nvram-save.sh -b
logger -t $sn "Finished"
date >>/jffs/scripts/$sn.log

Here are the logs that shows nvram-save starting but not finishing.

May 26 00:13:00 RT-AC86U-1BD0 backupRouterConfig: Started
May 26 00:13:00 RT-AC86U-1BD0 nvram-save.sh: NVRAM User Save Utility - Version 30.3 POSIX Code Updates
May 26 00:13:00 RT-AC86U-1BD0 nvram-save.sh: NVRAM User Save Utility - Version 30.1 Martineau Hacked for v384.xx+!!
May 26 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Saving RT-AC86U settings from firmware 384.16_0
May 26 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Runtime options: -b
May 26 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Using standard NVRAM variable file: nvram-merlin.ini Version=30.3.0
May 26 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Running in Backup Mode

Here is an example of the logs where it finishes normally.

May 25 00:13:00 RT-AC86U-1BD0 backupRouterConfig: Started
May 25 00:13:00 RT-AC86U-1BD0 nvram-save.sh: NVRAM User Save Utility - Version 30.3 POSIX Code Updates
May 25 00:13:00 RT-AC86U-1BD0 nvram-save.sh: NVRAM User Save Utility - Version 30.1 Martineau Hacked for v384.xx+!!
May 25 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Saving RT-AC86U settings from firmware 384.16_0
May 25 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Runtime options: -b
May 25 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Using standard NVRAM variable file: nvram-merlin.ini Version=30.3.0
May 25 00:13:00 RT-AC86U-1BD0 nvram-save.sh: Running in Backup Mode
May 25 00:13:37 RT-AC86U-1BD0 nvram-save.sh: Complete: User NVRAM saved to /tmp/mnt/Data/nsru/backup/nvram-restore-202005250013_RT-AC86U-1BD0.sh
May 25 00:13:39 RT-AC86U-1BD0 nvram-save.sh: Complete: JFFS directory saved to /tmp/mnt/Data/nsru/backup/jffs-202005250013_RT-AC86U-1BD0
May 25 00:13:40 RT-AC86U-1BD0 backupRouterConfig: Finished

The last step the script does is creating the log entry in nvram-util.log. If you run the nvram-restore.sh, the log file that failed should show dashes for Ver= as shown below

  9 : nvram-restore-202005021901_RT-AC88U-8248.sh       Ver=--------

Does that happen for the ones that failed? If so, that means the log entry never got added to nvram-util.log and failed somewhere in the process. How many restore files do you have? I may have to add some debugging messages to find the root cause.

 

[TonyK132]

The last step the script does is creating the log entry in nvram-util.log. If you run the nvram-restore.sh, the log file that failed should show dashes for Ver= as shown below

  9 : nvram-restore-202005021901_RT-AC88U-8248.sh       Ver=--------

Does that happen for the ones that failed? If so, that means the log entry never got added to nvram-util.log and failed somewhere in the process. How many restore files do you have? I may have to add some debugging messages to find the root cause.

Sorry, I did not run a restore. Where is the nvram-util.log file located? I could post those results if that would help you. I had about 12 days of backup when it failed. I deleted most of the days, then last night it ran correctly. I was thinking of auto-deleting the oldest files after about xx days. Looks like xx needs to less than 12.

 

[Xentrk]

Sorry, I did not run a restore. Where is the nvram-util.log file located? I could post those results if that would help you. I had about 12 days of backup when it failed. I deleted most of the days, then last night it ran correctly. I was thinking of auto-deleting the oldest files after about xx days. Looks like xx needs to less than 12.

Running the nvram-restore.sh will bring up a menu list of backup files. You then have to select one from the menu to restore from the list. So don't worry about hurting anything. With the volume of backups you are running, the log file or directory may be out of room? Seeing the list will give an idea of how many saves were aborted and did not get a log entry.

nvram-util.log is in the same directory location as the scripts. Type nsru to go to the directory.

 

[TonyK132]

Does this help?


admin@RT-AC86U-1BD0:/tmp/mnt/Data/nsru# sh nvram-restore.sh

nvram-restore.sh NVRAM Restore Utility - Version 30.3.0

NVRAM Restore File Directory: /tmp/mnt/Data/nsru/backup

1 : TKnvram-restore-202004281318_RT-AC86U-1BD0.sh Ver=--------
2 : nvram-restore-202004270654_RT-AC86U-1BD0.sh Ver=--------
3 : nvram-restore-202004281318_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
4 : nvram-restore-202004291215_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
5 : nvram-restore-202004291403_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
6 : nvram-restore-202004301840_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
7 : nvram-restore-202005010916_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
8 : nvram-restore-202005020013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
9 : nvram-restore-202005030013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
10 : nvram-restore-202005040013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
11 : nvram-restore-202005050013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
12 : nvram-restore-202005060013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
13 : nvram-restore-202005070013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
14 : nvram-restore-202005080013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
15 : nvram-restore-202005090013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
16 : nvram-restore-202005111454_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
17 : nvram-restore-202005121747_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
18 : nvram-restore-202005130013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
19 : nvram-restore-202005140013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
20 : nvram-restore-202005150013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
21 : nvram-restore-202005160013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
22 : nvram-restore-202005170013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
23 : nvram-restore-202005170920_RT-AC86U-1BD0.sh Ver=--------
24 : nvram-restore-202005180013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
25 : nvram-restore-202005190013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
26 : nvram-restore-202005200013_RT-AC86U-1BD0.sh Ver=--------
27 : nvram-restore-202005210013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
28 : nvram-restore-202005220013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
29 : nvram-restore-202005230013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
30 : nvram-restore-202005240013_RT-AC86U-1BD0.sh Ver=--------
31 : nvram-restore-202005250013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
32 : nvram-restore-202005260013_RT-AC86U-1BD0.sh Ver=--------
33 : nvram-restore-202005270013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini

Restore last NVRAM save ? (nvram-restore-202005270013_RT-AC86U-1BD0.sh)
{ n[{-n}] [ del ] | Y } (or press ENTER to ABORT) >


Here is s snippet of the log file that shows the gaps in the data.

nvram-save.sh 202005220013_RT-AC86U-1BD0 Fri May 22 00:13:38 DST 2020 384.16_0 nvram-merlin.ini #Version=30.3.0 0 minutes and 38 seconds elapsed, Total Bytes=7203
jffs-save 202005220013_RT-AC86U-1BD0 Fri May 22 00:13:40 DST 2020
nvram-save.sh 202005230013_RT-AC86U-1BD0 Sat May 23 00:13:38 DST 2020 384.16_0 nvram-merlin.ini #Version=30.3.0 0 minutes and 38 seconds elapsed, Total Bytes=7203
jffs-save 202005230013_RT-AC86U-1BD0 Sat May 23 00:13:39 DST 2020
nvram-save.sh 202005250013_RT-AC86U-1BD0 Mon May 25 00:13:37 DST 2020 384.16_0 nvram-merlin.ini #Version=30.3.0 0 minutes and 37 seconds elapsed, Total Bytes=7203
jffs-save 202005250013_RT-AC86U-1BD0 Mon May 25 00:13:39 DST 2020
nvram-save.sh 202005270013_RT-AC86U-1BD0 Wed May 27 00:13:38 DST 2020 384.16_0 nvram-merlin.ini #Version=30.3.0 0 minutes and 38 seconds elapsed, Total Bytes=7203
jffs-save 202005270013_RT-AC86U-1BD0 Wed May 27 00:13:40 DST 2020

 

[Xentrk]

Does this help?


admin@RT-AC86U-1BD0:/tmp/mnt/Data/nsru# sh nvram-restore.sh

nvram-restore.sh NVRAM Restore Utility - Version 30.3.0

NVRAM Restore File Directory: /tmp/mnt/Data/nsru/backup

1 : TKnvram-restore-202004281318_RT-AC86U-1BD0.sh Ver=--------
2 : nvram-restore-202004270654_RT-AC86U-1BD0.sh Ver=--------
3 : nvram-restore-202004281318_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
4 : nvram-restore-202004291215_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
5 : nvram-restore-202004291403_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
6 : nvram-restore-202004301840_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
7 : nvram-restore-202005010916_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
8 : nvram-restore-202005020013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
9 : nvram-restore-202005030013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
10 : nvram-restore-202005040013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
11 : nvram-restore-202005050013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
12 : nvram-restore-202005060013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
13 : nvram-restore-202005070013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
14 : nvram-restore-202005080013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
15 : nvram-restore-202005090013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
16 : nvram-restore-202005111454_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
17 : nvram-restore-202005121747_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
18 : nvram-restore-202005130013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
19 : nvram-restore-202005140013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
20 : nvram-restore-202005150013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
21 : nvram-restore-202005160013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
22 : nvram-restore-202005170013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
23 : nvram-restore-202005170920_RT-AC86U-1BD0.sh Ver=--------
24 : nvram-restore-202005180013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
25 : nvram-restore-202005190013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
26 : nvram-restore-202005200013_RT-AC86U-1BD0.sh Ver=--------
27 : nvram-restore-202005210013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
28 : nvram-restore-202005220013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
29 : nvram-restore-202005230013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
30 : nvram-restore-202005240013_RT-AC86U-1BD0.sh Ver=--------
31 : nvram-restore-202005250013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini
32 : nvram-restore-202005260013_RT-AC86U-1BD0.sh Ver=--------
33 : nvram-restore-202005270013_RT-AC86U-1BD0.sh Ver=384.16_0 nvram-merlin.ini

Restore last NVRAM save ? (nvram-restore-202005270013_RT-AC86U-1BD0.sh)
{ n[{-n}] [ del ] | Y } (or press ENTER to ABORT) >


Here is s snippet of the log file that shows the gaps in the data.

nvram-save.sh 202005220013_RT-AC86U-1BD0 Fri May 22 00:13:38 DST 2020 384.16_0 nvram-merlin.ini #Version=30.3.0 0 minutes and 38 seconds elapsed, Total Bytes=7203
jffs-save 202005220013_RT-AC86U-1BD0 Fri May 22 00:13:40 DST 2020
nvram-save.sh 202005230013_RT-AC86U-1BD0 Sat May 23 00:13:38 DST 2020 384.16_0 nvram-merlin.ini #Version=30.3.0 0 minutes and 38 seconds elapsed, Total Bytes=7203
jffs-save 202005230013_RT-AC86U-1BD0 Sat May 23 00:13:39 DST 2020
nvram-save.sh 202005250013_RT-AC86U-1BD0 Mon May 25 00:13:37 DST 2020 384.16_0 nvram-merlin.ini #Version=30.3.0 0 minutes and 37 seconds elapsed, Total Bytes=7203
jffs-save 202005250013_RT-AC86U-1BD0 Mon May 25 00:13:39 DST 2020
nvram-save.sh 202005270013_RT-AC86U-1BD0 Wed May 27 00:13:38 DST 2020 384.16_0 nvram-merlin.ini #Version=30.3.0 0 minutes and 38 seconds elapsed, Total Bytes=7203
jffs-save 202005270013_RT-AC86U-1BD0 Wed May 27 00:13:40 DST 2020

Navigate to the backup directory. For the files that failed, locate the nvram restore script for the files that failed. It will look like this: nvram-restore-202005021835_RT-AC88U-8248.sh

Scroll down to the bottom of the file and look for the section was last saved. It will look like this:

echo "Restoring [User Adds]"

See if there is a common theme among the failed backups on the last section saved.

Also, closely monitor and check for any messages in the system log at the time the nvram-save.sh ran for clues.

 

[TonyK132]

OK, I'll do that. I deleted some of the old backups, so it may be a few days (12?) before I will have any data for you.

 

[here1310]

Presentation of my backup concept:

Conditions:
1. daily backup of the jffs
2. daily backup of the usb-device (sda1-Entware Repository)
3. daily backup of the cfg using nsru, rotation 7 days

Solutions:
1. daily backup of the jffs with rsync on usb-device (sda1)
################################################################
script:
################################################################
#!/bin/sh
#
logger -t $(basename $0) "jffs_bak start [$@]"
#
# copy the data
rsync -av --delete /jffs/ /tmp/mnt/sda1/jffs_bak/
#
logger -t $(basename $0) "jffs_bak finish [$@]"
################################################################

2. daily backup of the usb device (sda1) as a tar file on a CIFS-mounted NAS or ssd device
################################################################
script:
################################################################ #!/bin/sh
#
# SOURCEDIR is the path to Entware installation place
SOURCEDIR=/tmp/mnt/sda1
# OUTPUTDIR is the path where backups should be created
OUTPUTDIR=/cifs1/sda1_hell04/
# NUMBERBCKS means how much old copies of backup should be left
# NUMBERBCKS=0 means backup will be overwritten every time and no old copy will be left
NUMBERBCKS=0
EXCLUDE=/tmp/mnt/sda1/exclude.txt
if [ -f ${OUTPUTDIR}/sda1.tar.gz.bck${NUMBERBCKS} ];
then
rm -f ${OUTPUTDIR}/sda1.tar.gz.bck${NUMBERBCKS}
fi
count=$(($NUMBERBCKS-1))
while [ $count -gt 0 ]
do
if [ -f ${OUTPUTDIR}/sda1.tar.gz.bck${count} ];
then
mv ${OUTPUTDIR}/sda1.tar.gz.bck${count} ${OUTPUTDIR}/sda1.tar.gz.bck$(($count+1))
fi
count=$(($count-1))
done
if [ -f ${OUTPUTDIR}/sda1.tar.gz ] && [ $NUMBERBCKS -ne 0 ];
then
mv ${OUTPUTDIR}/sda1.tar.gz ${OUTPUTDIR}/sda1.tar.gz.bck1
fi
tar -cf ${OUTPUTDIR}/sda1.tar.gz -X /tmp/mnt/sda1/exclude.txt -C ${SOURCEDIR} .
################################################################
script with swp-file:
################################################################
#!/bin/sh
#
# SOURCEDIR is the path to Entware installation place
SOURCEDIR=/tmp/mnt/sda1
# OUTPUTDIR is the path where backups should be created
OUTPUTDIR=/cifs1/sda1_hell04/
# NUMBERBCKS means how much old copies of backup should be left
# NUMBERBCKS=0 means backup will be overwritten every time and no old copy will be left
NUMBERBCKS=0
if [ -f ${OUTPUTDIR}/sda1swp.tar.gz.bck${NUMBERBCKS} ];
then
rm -f ${OUTPUTDIR}/sda1swp.tar.gz.bck${NUMBERBCKS}
fi
count=$(($NUMBERBCKS-1))
while [ $count -gt 0 ]
do
if [ -f ${OUTPUTDIR}/sda1swp.tar.gz.bck${count} ];
then
mv ${OUTPUTDIR}/sda1swp.tar.gz.bck${count} ${OUTPUTDIR}/sda1swp.tar.gz.bck$(($count+1))
fi
count=$(($count-1))
done
if [ -f ${OUTPUTDIR}/sda1swp.tar.gz ] && [ $NUMBERBCKS -ne 0 ];
then
mv ${OUTPUTDIR}/sda1swp.tar.gz ${OUTPUTDIR}/sda1.tar.gz.bck1
fi
tar -cf ${OUTPUTDIR}/sda1swp.tar.gz -C ${SOURCEDIR} .
################################################################

3. not available, my problem: rotation max. 7 days in the nsru / backup-directory
better: direct backup as cfg and tar file on CIFS-mounted NAS or ssd device
@ Xentrk: can you help me?
possible problems:
1. USB device could age faster / become defective
Solution: daily jffs backup directly to CIFS-mounted NAS or ssd device
################################################################
sript:
################################################################
#!/bin/sh
#
# SOURCEDIR is the path to Entware installation place
SOURCEDIR=/jffs
# OUTPUTDIR is the path where backups should be created
OUTPUTDIR=/cifs1/jffs_hell04/
# NUMBERBCKS means how much old copies of backup should be left
# NUMBERBCKS=0 means backup will be overwritten every time and no old copy will be left
NUMBERBCKS=7
#EXCLUDE=/tmp/mnt/sda1/exclude.txt
if [ -f ${OUTPUTDIR}/jffs.tar.gz.bck${NUMBERBCKS} ];
then
rm -f ${OUTPUTDIR}/jffs.tar.gz.bck${NUMBERBCKS}
fi
count=$(($NUMBERBCKS-1))
while [ $count -gt 0 ]
do
if [ -f ${OUTPUTDIR}/jffs.tar.gz.bck${count} ];
then
mv ${OUTPUTDIR}/jffs.tar.gz.bck${count} ${OUTPUTDIR}/jffs.tar.gz.bck$(($count+1))
fi
count=$(($count-1))
done
if [ -f ${OUTPUTDIR}/jffs.tar.gz ] && [ $NUMBERBCKS -ne 0 ];
then
mv ${OUTPUTDIR}/jffs.tar.gz ${OUTPUTDIR}/jffs.tar.gz.bck1
fi
tar -cf ${OUTPUTDIR}/jffs.tar.gz -C ${SOURCEDIR} .
################################################################