Since updating to 26.1 the Nextcloud Backup has some strange behaviour.
Each backup creates numerous files with identical content.
The number of files is between 1 and 100, most times more than one (expected) file.
This happens to all Nextcloud backups, run by cron and manual triggered via GUI.
And the filenames of the backupfiles are different on 26.1.
Used to be "config-[fqdn]-[human readable timestamp].xml".
Now it's "config-[utime timestamp with up to 4 digits].xml".
Tried to remove and reinstall Nextcloud Backup plugin, same behaviour after reinstall.
The backup should create a single file with easy to read filenaming like it used to do before 26.1.
This change was submitted by a user to avoid backing up configs that haven't changed overnight and to get the full history.
Cheers,
Franco
I have opened a feature request to have an option that allows the user to opt for the previous behavior.
The problem with backing up the conf/backup directory is that when using nginx plugin, it uses the configuration to maintain the list of banned IPs, and this changes the config many times per day generating a huge amount of files.
I don't need to backup every of theses configs. So having the chance to use the original method would be useful in my case.
There will be no flip-flopping. If you want you can install the plugin from the stable/25.7 branch and lock the package.
Cheers,
Franco
Ok... thank you
I've closed the request.
This is completely unusable. I have to revamp my entire backup strategy for >10 firewalls.
At the very least use readable timestamps for which alphabetical and chronological order is identical like YYYY-MM-dd-hh:mm:ss or similar.
I backup half a dozen of firewalls to the same Nextcloud directory - how am I going to tell them apart without the hostname in the file name?
EDIT: I'll switch to git I guess. I stopped using git because performing a local config rollback breaks the connection of the local and the upstream repo with a merge conflict, but probably one can work around that. Having one properly time stamped file every 24 hours was perfect.
Quote from: Patrick M. Hausen on February 01, 2026, 03:57:28 PMThis is completely unusable. I have to revamp my entire backup strategy for >10 firewalls.
...
+1
+1
This "fix" should really be undone with the next release.
BTW: How do I roll that package back? "opnsense-revert -r 25.7.11 os-nextcloud-backup" fails with:
Fetching os-nextcloud-backup.pkg: ..[fetch: https://pkg.opnsense.org/FreeBSD:14:amd64/26.1/MINT/25.7.9/latest/Latest/os-nextcloud-backup.pkg.sig: Not Found] failed
+1
Quote from: Patrick M. Hausen on February 01, 2026, 03:57:28 PMAt the very least use readable timestamps for which alphabetical and chronological order is identical like YYYY-MM-dd-hh:mm:ss or similar.
I had to disable the plugin too. Many files with meaningless names.
To me, lock to the previous version as Franco says can't be a long term solution, so I had to stop using it.
Quote from: muchacha_grande on February 01, 2026, 03:22:00 PMThe problem with backing up the conf/backup directory is that when using nginx plugin, it uses the configuration to maintain the list of banned IPs, and this changes the config many times per day generating a huge amount of files.
Thx for the hint, I can confirm this is the rootcause after doing diffs on the backupfiles.
Just for reference the plugin maintainer/author approved these changes in October. https://github.com/opnsense/plugins/pull/4952
It was in part merged because Fabian doesn't have time for improvements in OPNsense these days and we don't want to demotivate community submissions either.
Don't mind a bit of discussion, but this outcry is a bit misplaced in my opinion for a community-based plugin and changes in plain sight (on GitHub).
Cheers,
Franco
I haven't updated to v26.1 yet, but can I lock the plug-in before to prevent it upgrading when I do get around to v26.1?
Locks are removed to make major updates proceed. I worked on a little extension for opnsense-code to allow installing older version of plugins since opnsense-revert is not that safe and shouldn't cross ABI.
https://github.com/opnsense/update/commit/fbe231e8f5
Maybe I haven't been perfectly clear: we can consider changing this but it has to be constructive and follow established procedures. It would start with a ticket and maybe we can get feedback from Fabian and the change author too...
Cheers,
Franco
Thank you, Franco. After:
opnsense-patch -c update fbe231e8f5
opnsense-code -uo sysutils/nextcloud-backup -r 25.7 plugins
pkg lock os-nextcloud-backup-1.0_1
configctl webgui restart
os-nextcloud-backup-1.0_1 is back and locked for now.
I also created an issue: https://github.com/opnsense/plugins/issues/5181
Quote from: meyergru on February 02, 2026, 01:49:45 PMI also created an issue: https://github.com/opnsense/plugins/issues/5181 (https://github.com/opnsense/plugins/issues/5181)
Thank you meyergru.
I haven't updated just yet. I do rely on these backups and I'm confused a bit reading all this. Can someone clarify what's going on here? So, each backup file isn't a full backup? For example with a restore we'd need a full and a diff? I clean up backup files on the Nextcloud side, want to make sure I understand this so I don't blow out a full backup and bork up my ability to restore if needed.
Or am I misunderstanding and this just creates a full backup on ANY change? Along with just a goofy naming convention.
Instead of backing up a file per invoke it backs up your actual backup content on the system all at once.
From a pure technical perspective you still have all your backups. From a UX perspective both the old and the new way have upsides and downsides.
Cheers,
Franco
Quote from: franco on February 04, 2026, 08:30:00 AMInstead of backing up a file per invoke it backs up your actual backup content on the system all at once.
And which of the multiple files do I pick for a restore?
The one with the appropriate timestamp? I don't quite understand the fuzz except for readability and host name missing. It mirrors the backup functionality of how System: Configuration: History has always worked.
Cheers,
Franco
Quote from: franco on February 04, 2026, 09:25:49 AMIt mirrors the backup functionality of how System: Configuration: History has always worked.
So all the files are a complete backup each. I must admit I never looked closer into the mentioned part of the menu. Only configuration backup and restore. And os-nextcloud-backup nicely mirrored what you would get with a manual download plus renaming/archiving per day.
So please don't get this wrong: my only complaint is about readability and the missing hostname.
But I will revisit the git based mechanism, anyway, because that includes a log of who did the change in a situation with more than one admin.
> my only complaint is about readability and the missing hostname
I know and that's fair. The author of the change has already made a PR as far as I can see and was discussing with Uwe.
Cheers,
Franco