Nextcloud Backup creates multiple files

Started by vPro, Today at 12:16:13 PM

Previous topic - Next topic
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

Today at 03:28:15 PM #4 Last Edit: Today at 03:38:08 PM by muchacha_grande
Ok... thank you

I've closed the request.

Today at 03:57:28 PM #5 Last Edit: Today at 04:27:27 PM by Patrick M. Hausen
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.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: Patrick M. Hausen on Today at 03:57:28 PMThis is completely unusable. I have to revamp my entire backup strategy for >10 firewalls.
...
+1

Today at 05:27:40 PM #7 Last Edit: Today at 05:37:33 PM by meyergru
+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
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

+1

Quote from: Patrick M. Hausen on Today at 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 Today at 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