We run gravcms in a linux container (lxd) which has build in snapshot support. Therfore we don’t want to use gravcms’ backup mechanism.
What is the best way to completely disable the whole backup job execution without disabling the other jobs? What is the intended way to configure jobs in a multisite install? The admin plugin creates a config in every site which causes job execution to run for every site instead of once for the hole grav install, right?
I disabled backup schedule in all site config files but the job is still being executed.
find . -name backups.yaml|xargs grep 'schedule:'
./sites/main/config/backups.yaml: schedule: false
./sites/doc/config/backups.yaml: schedule: false
Do I have to create a backup job config for the main config in
grav/user/config to prevent the backup job execution at all? We don’t use grav/user/pages but only grav/sites
I also tried to disable the job execution by setting
max_backups_count: 0 but this doen’t work either since this config parameter seems only to be used by the purge job.
@hi-ko, As far as I know, Grav doesn’t make any backups, unless you configure it to make backups…
@pamtbaau I’m not aware that I explicitly enabled backup but I guess it’s enabled automatically by the admin plugin. So the question is how to get rid of these backup jobs without loosing the other jobs.
In our installation we additionally use symlinks in sites to reuse specific pages, plugins, themes on other sites but the backup job then creates very big archives by dereferencing all the symlinks dumping everything again for every site.
Backups are indeed not enabled by default, not by Grav and not by Admin. Perhaps you did enable them accidentally.
You can disable backups of the site from the Tools → Scheduler section (
/admin/tools/scheduler). There you should see
Had the same experience as @hi-ko
Although in user/config/backups.yaml, in the default profile there was an entry “schedule:false”, every night, a default site backup was being generated.
What I did to disable it was … I went to the scheduler config, where there are three jobs that look disabled by default. I explicitly enabled them, saved the config, then explicitly disabled them and saved the config again. This action generated a new config/scheduler.yaml which had explicitly disabled the status of these jobs.
[nginx@content website]$ cat user/config/scheduler.yaml
Overnight, there were no new backups created, as I had originally expected.