https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42028 --- Comment #2 from Michał <schodkowy.omegi-0r@icloud.com> --- Created attachment 195004 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=195004&action=edit [PATCH 2/3] Bug 42028: tweak default koha-run-backups settings [PATCH 2/3] Bug 42028: tweak default koha-run-backups settings "Configuration" tar file should not be so outrageously big (~10x bigger than the database, what in the world!). The biggest offender is the Zebra index files. These should not be backed up at all, instead regenerate them after restoring backup. There's no consistency between SQL and index dumps, they're not atomic, so restoring them like that is unsafe anyway. In fact, ideally that option should be removed completely so that nobody can shoot their foot off. Logs these days can also grow quite big with all these crazy AI crawlers out there nowadays and default retention settings. I don't think making N copies of the very same logs on the server, which are meant to be ultimately ephemeral anyways, is really beneficial... And now that we shrunk the needed storage by ~10x (YMMV), bump default 2 days to 7, making it much more likely you'll have old enough point of reference in case anything goes wrong with your Koha, before it gets nuked forever. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42028 Michał <schodkowy.omegi-0r@icloud.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |januszop@gmail.com, | |schodkowy.omegi-0r@icloud.c | |om Status|NEW |Needs Signoff --- Comment #4 from Michał <schodkowy.omegi-0r@icloud.com> --- Test plan: PATCH 1: 1. Before applying run `time koha-dump INSTANCE` 2. Apply patch 3. Run #1 again and compare the times, run `ls -lh /var/spool/koha/INSTANCE` and compare the file sizes for .gz and .zst Optionally you may run `koha-run-backups --days 7 --exclude-indexes --exclude-logs --output /var/spool/koha` to make sure it works as expected, altering file name and date with `touch -d` or so, to make sure the --days option still works as expected and old files are getting removed. PATCH 2: 1. Run old cron command: `koha-run-backups --days 2 --output /var/spool/koha` 2. Look at the generated file size of .tar.zst in /var/spool/koha/INSTANCE 3. Run new command: `koha-run-backups --days 7 --exclude-indexes --exclude-logs --output /var/spool/koha` 4. Compare the sizes. Note that production installations with sizable Zebra index and log files will only yield the proper difference effect. PATCH 3: Run `koha-dump INSTANCE` and in another terminal use a tool like htop and you can sort by "NI" column to make sure koha-dump and its children processes have value of 10. You may also check ionice with: ionice -p `pidof zstd` (or replace zstd with mysqldump or tar). Be quick, since zstd backup finished much more quickly, you'd need to check these values before it finishes. The error messages for renice and ionice should not be shown at the top of your koha-dump terminal output (own process normally can adjust own values, and also these scripts are in sbin to only run as root...). -- You are receiving this mail because: You are watching all bug changes.