What's new

BACKUPMON BACKUPMON v1.5.9 -Feb 21, 2024- Backup/Restore your Router: JFFS + NVRAM + External USB Drive! (Now available in AMTM!)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Well I didn't want to do a full restore as was on an AIMesh node that had lost it's configuration after a power failure last weekend. I'd managed after a few attempts to get the node back into the mesh and working.

I realize that in this case their is not much need to take backups but I did!

I just manually extracted a few files from the backup; ssh keys / my service_start script, my wrapper backup script (I rely on the creation / removal of a file on the destination server to trigger a backup from the QNAP to an external USB device).
 
@Viktor Jaep I just discovered a possible bug when running scheduled monthly backups: "old" day 31 backups linger until they are replaced in the next month that has 31 days (similarly, 29 and 30 January backups will linger until the end of March). No big deal, but rather something for you to fuss over when you can't sleep some night... 🤪

LingeringBackups.png
 
Last edited:
@Viktor Jaep I just discovered a possible bug when running scheduled monthly backups: "old" day 31 backups linger until they are replaced in the next month that has 31 days (similarly, 29 and 30 January backups will linger until the end of March). No big deal, but rather something for you to fuss over when you can't sleep some night... 🤪

View attachment 54673

What do you mean... "Bug"!! This is a "feature"! Lol 🤣

I would look at it as a nice-to-have backup set that would give you up to 60+ possible days of recoverability depending on the time of year!
 
Last edited:
This utility has been working well until this week when I upgraded my GT-AX6000 to 388.5 Final: now I get this error when running a manual backup-

Code:
mount: mounting \\192.168.27.20\RouterBackups on /tmp/mnt/backups failed: Key has expired

Any suggestions to resolve this "Key has expired" message? Is this a failure to read/write to the attached USB SSD drive, or is it a failure to connect to my network storage location?
 
This utility has been working well until this week when I upgraded my GT-AX6000 to 388.5 Final: now I get this error when running a manual backup-

Code:
mount: mounting \\192.168.27.20\RouterBackups on /tmp/mnt/backups failed: Key has expired

Any suggestions to resolve this "Key has expired" message? Is this a failure to read/write to the attached USB SSD drive, or is it a failure to connect to my network storage location?

From what I found online, this means that either the password on your network storage device may have expired, or that your password may have an @ sign, which mount/protocols also may not like? I would try that first... Also, I have not upgraded to 388.5 yet, so I can't confirm if this version has changed anything at this point.
 
Last edited:
From what I found online, this means that either the password on your network storage device may have expired, or that your password may have an @ sign, which mount/protocols also may not like? I would try that first...
Thanks, but I don't see it as being any of those cases (no @ sign in password, and the network location share is a Windows 10 folder share that was working fine before this week, no password expiration date has been set).

After a full power cycle of the router, the message changed slightly:

Code:
WARNING: External drive mount point not set. Newly created under: /tmp/mnt/backups
mount: mounting \\192.168.27.20\RouterBackups on /tmp/mnt/backups failed: Key has expired
 
Thanks, but I don't see it as being any of those cases (no @ sign in password, and the network location share is a Windows 10 folder share that was working fine before this week, no password expiration date has been set).

After a full power cycle of the router, the message changed slightly:

Code:
WARNING: External drive mount point not set. Newly created under: /tmp/mnt/backups
mount: mounting \\192.168.27.20\RouterBackups on /tmp/mnt/backups failed: Key has expired
That's a normal message you would get after a router reboot, since the mount point has to be created each time after a reboot. But the "key has expired" message is an error coming from the mount command.

Have you tried perhaps rebooting your NAS/Windows machine? Also, not sure what protocol version of CIFS/SMB you're using, but perhaps dropping it lower, or using a higher version? Are you able to get to this share via other means, to test connectivity?
 
Last edited:
That's a normal message you would get after a router reboot, since the mount point has to be created each time after a reboot. But the "key has expired" message is an error coming from the mount command.

Have you tried perhaps rebooting your NAS/Windows machine? Also, not sure what version of CIFS/SMB you're using, but perhaps dropping it lower, or using a higher version? Are you able to get to this share via other means, to test connectivity?
Thanks, I'm not home right now to test, but I will be looking into those suggestions tonight. I agree now that it is an access problem with logging onto that shared folder, but don't see why just yet.
 
Thanks, but I don't see it as being any of those cases (no @ sign in password, and the network location share is a Windows 10 folder share that was working fine before this week, no password expiration date has been set).

After a full power cycle of the router, the message changed slightly:

Code:
WARNING: External drive mount point not set. Newly created under: /tmp/mnt/backups
mount: mounting \\192.168.27.20\RouterBackups on /tmp/mnt/backups failed: Key has expired
Is this windows computer you are trying to reach? I had a similar issue once. It was not the user password that was expired, but the machine account password. This was a Win 10 Pro machine. I had to use gpedit.msc and set max machine age to 0 to disable it. Did not have a problem since.
 
Thanks, I'm not home right now to test, but I will be looking into those suggestions tonight. I agree now that it is an access problem with logging onto that shared folder, but don't see why just yet.
Definitely curious if you find out what the issue was!
Is this windows computer you are trying to reach? I had a similar issue once. It was not the user password that was expired, but the machine account password. This was a Win 10 Pro machine. I had to use gpedit.msc and set max machine age to 0 to disable it. Did not have a problem since.
That is an excellent suggestion! Would not have considered that if the user account that CIFS uses wasn't locked out or password expired.
 
Is this windows computer you are trying to reach? I had a similar issue once. It was not the user password that was expired, but the machine account password. This was a Win 10 Pro machine. I had to use gpedit.msc and set max machine age to 0 to disable it. Did not have a problem since.
Is this the key you're talking about, @Jeffrey Young?

 
Definitely curious if you find out what the issue was!

That is an excellent suggestion! Would not have considered that if the user account that CIFS uses wasn't locked out or password expired.
Ok, this is resolved now. All of your suggestions were close to the right answer, but not exactly....lets just say that they led me to investigate further.

The Windows user (that I specifically created a local user account for this share/backup folder) was working fine for a month or so, but had somehow had the "flag" set to "User must change password at next logon" when the properties of that user were examined in lusrmgr.msc (Windows management console). Don't know how or why...but chalk it up to Windows weirdness. BTW, the password didn't need to be changed or reset once that flag/checkbox was cleared.

All good again, thanks to everyone who responded.
 
Ok, this is resolved now. All of your suggestions were close to the right answer, but not exactly....lets just say that they led me to investigate further.

The Windows user (that I specifically created a local user account for this share/backup folder) was working fine for a month or so, but had somehow had the "flag" set to "User must change password at next logon" when the properties of that user were examined in lusrmgr.msc (Windows management console). Don't know how or why...but chalk it up to Windows weirdness. BTW, the password didn't need to be changed or reset once that flag/checkbox was cleared.

All good again, thanks to everyone who responded.
That's great info... thanks for reporting back! Glad you're backing things up again! :)
 
Is this the key you're talking about, @Jeffrey Young?

That is the one. What I never understood is that my windows machine was not domain joined. Yet, no matter if I set my user password to never expire, come that 30 day machine password expiry, I could not authenticate a share until I changed my user password (which I am guessing renewed the machine password). Like I said, I could not make reason of it as the computer was not domain joined. This was also years ago. May even been a winXP. Nonetheless my standard setup now on new installs is to set the machine age to zero. Perhaps someone else with more knowledge of windows domains could offer an explanation. It solved the issue for me.
 
That is the one. What I never understood is that my windows machine was not domain joined. Yet, no matter if I set my user password to never expire, come that 30 day machine password expiry, I could not authenticate a share until I changed my user password (which I am guessing renewed the machine password). Like I said, I could not make reason of it as the computer was not domain joined. This was also years ago. May even been a winXP. Nonetheless my standard setup now on new installs is to set the machine age to zero. Perhaps someone else with more knowledge of windows domains could offer an explanation. It solved the issue for me.
It seems this setting is primarily concerned with AD-joined members... and by default members on the domain change their own machine passwords every 30 days. That's why I'm confused as well as to how this setting would affect a standalone Windows 10 non-domain joined workstation. But hey... if it works, it works. Wouldn't be the first strange Microsoft quirk I've come across. ;)
 
Sorry... The default is actually nothing... blank. It should have said "Example: /jffs/addons/backupmon.d/exclusions.txt" -- If you want to use an exclusion file, you must create the file and can put it anywhere, as long as your path referencing it is correct. The contents of the file should just be a list of files/folders that you want to exclude from the backup.

Example contents of "exclusions.txt":
Code:
myswap.swp
entware/var/log/*
skynet/skynet.log

I just ran into this as well (my first use of backupmon) - probably wording could be adjusted to indicate that the current default does not exclude anything!
 
I just ran into this as well (my first use of backupmon) - probably wording could be adjusted to indicate that the current default does not exclude anything!
How does this sound?

4.) The optional TAR exclusion list can be placed in a directory of your choice. PLEASE NOTE: By default, backupmon will back up everything, swap files, log files, included! It is a good idea to exclude these using this exclusion list file. You can create this file anywhere, but I prefer to keep things in /jffs/addons/backupmon.d and named it "exclusions.txt", just to clear the clutter. The contents of this file is simply a list of files that TAR can safely ignore during a backup. Certain files, like your swap file, or other temporary files, aren't needed when restoring a backup, and get recreated after a restore. Huge thanks to @visortgw for sharing his exclusion file... the default exclusion items list looks something like this:

exclusions.txt
Code:
myswap.swp
entware/var/log/*
skynet/skynet.log

Save this file somewhere on your router, and make sure it's properly referenced in BACKUPMON. Eliminating swap and other temp files could really speed up your backups tremendously, and save you from headaches down the road on a restore.

 
How does this sound?

4.) The optional TAR exclusion list can be placed in a directory of your choice. PLEASE NOTE: By default, backupmon will back up everything, swap files, log files, included! It is a good idea to exclude these using this exclusion list file. You can create this file anywhere, but I prefer to keep things in /jffs/addons/backupmon.d and named it "exclusions.txt", just to clear the clutter. The contents of this file is simply a list of files that TAR can safely ignore during a backup. Certain files, like your swap file, or other temporary files, aren't needed when restoring a backup, and get recreated after a restore. Huge thanks to @visortgw for sharing his exclusion file... the default exclusion items list looks something like this:

exclusions.txt
Code:
myswap.swp
entware/var/log/*
skynet/skynet.log

Save this file somewhere on your router, and make sure it's properly referenced in BACKUPMON. Eliminating swap and other temp files could really speed up your backups tremendously, and save you from headaches down the road on a restore.

I have since added a few entires to my exclusions file based upon actual experience (mainly, orphan archives generated during testing):
Code:
myswap.swp
entware/var/log/*
skynet/skynet.log
*.tar
*.gz
 
This is my flavour, because I use diversion

exclusions.txt
Code:
myswap.swp
entware/var/log/*
entware/share/uiDivStats.d/dnsqueries.db
 
Last edited:

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top