BACKUPMON BackupMon Failing

[Viktor Jaep]

If that were the case surely primary backups would get messed up the same? Would it add to my personal exclusions list or pfexclusions.txt?
EDIT: myswap.swp has indeed been added back to my personal exclusions list by the script, and now appears under both 'es' and 'ep'.

Lol. Well, if you go into the setup, you can specify that you DO want to backup your swap, which will set BACKUPSWAP=1, and should remove *.swp from your exclusion list?

 

[Viktor Jaep]

Out of the blue I encountered an error overnight on an automated (cron job) USB-to-USB backup:

Jul 16 2024 02:02:46 GT-BE98_Pro-7668 BACKUPMON[20884] - **ERROR**: Errors detected creating secondary EXT Drive tar file.​

Nothing changed as far as I know. Rerunning the same backup command this morning was successful.

What does the error log say about this?

 

[Ripshod]

My errors started 2:15am BST July 6 if that's any help. Every time it failed was for spdMerlin tmp files, which you know are in my exclusions list.

 

[Viktor Jaep]

My errors started 2:15am BST July 6 if that's any help.

Starting to wonder if there's some concurrent jobs or other scripts interfering around that time?

 

[Ripshod]

It seems backupmon is ignoring the exclusions list on the secondary backup and is trying to process the tmp files. And it only started on 6th. Before that I was also running spdMerlin at the same time and never had BACKUPMON attempt to backup tmp files.
*edit* I'll move my spdMerlin times to avoid the collision but things already seem a lot more stable.

We've been here before, with the CRON collisions that time. But that was CRON itself.

 

[Viktor Jaep]

It seems backupmon is ignoring the exclusions list on the secondary backup and is trying to process the tmp files. And it only started on 6th. Before that I was also running spdMerlin at the same time and never had BACKUPMON attempt to backup tmp files.
*edit* I'll move my spdMerlin times to avoid the collision but things already seem a lot more stable.

We've been here before, with the CRON collisions that time. But that was CRON itself.

The code hasn't really seen much change since July 4. The patch right after was basically a URL change.

 

[visortgw]

What does the error log say about this?

That is error log.

 

[Viktor Jaep]

That is error log.

Usually there's an associated tar error along with it?

If I don't already have some, I'll create a few fake .tmp files and see if I get any similar results.

 

[Ripshod]

The code hasn't really seen much change since July 4. The patch right after was basically a URL change.

That date would still fit. Secondary backup doesn't fail every time.

 

[Viktor Jaep]

That date would still fit. Secondary backup doesn't fail every time.

Perhaps try reverting to 1.8.14?

 

[Ripshod]

Perhaps try reverting to 1.8.14?

Good idea. Do you have a link?

 

[Viktor Jaep]

Good idea. Do you have a link?

BACKUPMON/backupmon-1.8.14.sh at 4ddcee1d5beaf63b5ff4d180155acb980728f982 · ViktorJp/BACKUPMON

Asus-Merlin JFFS, USB and NVRAM Backup/Restore Tool - ViktorJp/BACKUPMON

github.com

 

[Ripshod]

BACKUPMON/backupmon-1.8.14.sh at 4ddcee1d5beaf63b5ff4d180155acb980728f982 · ViktorJp/BACKUPMON

Asus-Merlin JFFS, USB and NVRAM Backup/Restore Tool - ViktorJp/BACKUPMON

github.com

I was being a bit dumb tbh. I've just grabbed it from a backup
I've reset spdMerlin and will run like this til I see an error - but I'm confident I won't. Thanks @Viktor Jaep

 

[Viktor Jaep]

I was being a bit dumb tbh. I've just grabbed it from a backup
I've reset spdMerlin and will run like this til I see an error - but I'm confident I won't. Thanks @Viktor Jaep

Well, I just did some testing, and I can't replicate what you were seeing...

1.) I didn't have any .tmp files on my SSD, so I created one in the root.
2.) I did a backup, and both my primary and secondary backups successfully backed up this .tmp file
3.) I didn't have the exclusion for *.tmp in my exclusions files, so I added it to both my primary and secondary.
4.) Ran another backup, and this time. the .tmp file was not found in the primary or secondary backups
5.) I took a look at the log, and still don't have any tar errors about this.

 

[visortgw]

Well, I just did some testing, and I can't replicate what you were seeing...

1.) I didn't have any .tmp files on my SSD, so I created one in the root.
2.) I did a backup, and both my primary and secondary backups successfully backed up this .tmp file
3.) I didn't have the exclusion for *.tmp in my exclusions files, so I added it to both my primary and secondary.
4.) Ran another backup, and this time. the .tmp file was not found in the primary or secondary backups
5.) I took a look at the log, and still don't have any tar errors about this.

I only saw the one last night. Other than that, everything has been PERFECT.

 

[visortgw]

I did revert on 1.8.14 earlier today.

 

[Viktor Jaep]

I did revert on 1.8.14 earlier today.

This is the only difference between v1.8.14 and v1.8.15... (1) the script's version number, and (2) a URL change to point to a different shared email library repostory. There have been zero code changes made to the way backups are made.

 

[Ripshod]

It's just a collision. Last night the secondary backup failed again, and with the spdMerlin tmp files again, using 1.8.14.
So the common points are

• tmp files
• Secondary backup (could be down to timing and doesn't mean primary backups are immune)
• Never happened before 6th July (doesn't mean it couldn't have happened earlier for others)

I can fix this by moving the timings but, in my case, secondary backup is still failing on tmp files when the extension is included in the exclusions list.
I'm going to add the spdMerlin /csv directory to my exclusions list and see what happens tonight.

 

[Ripshod]

@jrmathis if you haven tried it already you could try adding this to your exclusions list:

addons/dn-vnstat.d/csv/*

If that one doesn't work this one may:

/jffs/addons/dn-vnstat.d/csv/*

 

[jrmathis]

@jrmathis if you haven tried it already you could try adding this to your exclusions list:

addons/dn-vnstat.d/csv/*

If that one doesn't work this one may:

/jffs/addons/dn-vnstat.d/csv/*

It's worked twice after reboot, so I'm thinking that solved something, but should it crop up again, I'll add it...still puzzled by the manual vs automatic discrepancy...I also changed the time for the auto backup, maybe it was colliding with something, since I had timed it just before midnight...

On the successful auto backups, the errors referencing vnstat are not present...FYI