Module Cronjob Database Backup

[Juergen]

Hello kixe,

yes you are right, it is Ryans ProcessDatabaseBackups, which is responsible for the backups. So your module does the job quite well - the module creates a new backup after the time period I have choosen. It seems all ok unless I click on the backup to open it, then I get the error message (also at backups which were made with the latest dev version) - I will post this problem in the general section.

Best regards

[kixe]

Hello Juergen,

please try to make a backup directly from ProcessDatabaseBackups. And restore from this backup. Did you get the same error?

Thanks regards

[Juergen]

Independent if the backup is created manually or via cron job - same result.

Best regards

[kixe]

Because it is maybe interesting for others I will answer a question I got in the personal messenger:

Does the module have the capability to run from a standard cron job?

Yes. The Backup is triggered by the hook function cronBackup() expecting a HookEvent as single argument, which is in fact not needed. If you want to trigger the backup from anywhere, just create a HookEvent object and call the cronBackup() function. Done.
 

$event = new HookEvent;
$modules->get('CronjobDatabaseBackup')->cronBackup($event);

[cstevensjr]

I have spent the entire day working with websites with this module.  I am very impressed and thankful that @Kixe worked on this wonderful module.  Additional thanks to @LostKobrakai who mentioned this module in another thread, which got my interest and finally resulted in me testing it out.

I still don't know how I missed understanding the great usefulness of this module initially.

[Robin S]

I have a question regarding the condition:

Runs only if current user has db-backup permission.

Is there some way around this? I don't want to give any other roles this permission besides superuser (and the only superuser is me) because I don't want to give site editors the ability to restore backups. But I also don't want to have to be regularly browsing the website myself just to ensure the backup cron job runs.

You mention running the backup from a standard cron job above - how does the db-backup permission come into play here?

[kixe]

@Robin S
Thanks for pointing this out. This note is obsolete. I missed to remove it from earlier versions. The cronjob is triggered by every user.
 

[horst]

Hi @kixe,

first just want to say thanks for this useful module (if I don't have already)!

And I want to share a usage that propably wasn't intended with your module, but I find it useful for small sites where content changes slightly in a weekly manner or less. I use a hook into Session::logout in the ready.php file that invokes a DB-Backup. Currently the simplyfied code looks like:

/* Autobackups */
$wire->addHookBefore("Session::logout", function(HookEvent $event) {
    if(!wire('user')->hasPermission('db-backup')) return;
    if(wire('modules')->isInstalled('CronjobDatabaseBackup')) {
        // execute a cronBackup
        ignore_user_abort(true);
        set_time_limit(120);
        $cdb = wire('modules')->get('CronjobDatabaseBackup');
        $e = new HookEvent();
        $cdb->cronBackup($e);
    }
    return;
});

This is a bit hacky. What do you think about to embedd a public method to do this more transparent. Also it would be good if the description ($fileinfo) could be set dynamically with this method or as separate method or option. Currently I have hacked this into the module to be able to set it like: "logout horst (CronjobDatabaseBackup)".

Anyway, also without that, it is a big, big helper!

 

[kixe]

@horst
Thanks for your feedback and suggestions (I like them all). I pushed an update to github (Version 113) I made this very quickly. It seems to work, but I hadn't time to try out all scenarios. Could you test a bit? Thanks.

Version 1.1.3
NEW: user logout triggers cronjob  (db-backup permission required) instead of cycle interval.
NEW: extension of filename options (user properties)
NEW: custom fileinfo (via module settings). Same features like filename (hookable)

[bernhard]

i got a very misterious behaviour today. after some time of debugging i made it down to the following:

i have this script in my _init.php

    function myHook() {
        wire('log')->save('lazy',"backup!");
    }
    // add a hook to your function:
    $pages->addHook('LazyCron::every30Seconds', null, 'myHook');
    wire('log')->save('lazy', 'hook added');

• install lazycron
• refresh the site
• hook added and backup in the logs

BUT

• install cronjobdatabasebackup
• refresh the site
• only "hook added" in the logs!

no matter what i do the cron seems not to be executed.

deleting the file /site/assets/cache/LazyCron.cache solved that problem. can you confirm that @kixe ? or did i do anything wrong? first time for me with both lazycron and your backup module

[bernhard]

hi kixe, some more questions

i want to have daily backups of my database, maximum 10 files.

when is the backup trigger triggered? is it triggered by EVERY pageload (also guest users) or only by logged in users? i want the backup be crated also on guest visits. do i have to grant the guest role "db-backup" permission?

next question for understanding: what happens when this role does not have this permission? is it correct, that the cronjob itself will be triggered once a day, but if it is triggered by "guest" it will NOT create a backup and if it is triggered by "superuser" it WILL create one?

i think some more explaining words in the field descriptions would be a great help!

thank you for sharing your module!

[Robin S]

On 6/08/2016 at 3:04 AM, bernhard said:

when is the backup trigger triggered? is it triggered by EVERY pageload (also guest users) or only by logged in users? i want the backup be crated also on guest visits. do i have to grant the guest role "db-backup" permission?

I believe the lazy cron can be triggered on every pageload by every user, including guest, and you don't need to add the db-backup permission to guest for this to happen. I asked about this too and @kixe responded...

On 27/05/2016 at 5:06 PM, kixe said:

Thanks for pointing this out. This note is obsolete. I missed to remove it from earlier versions. The cronjob is triggered by every user.

 

On 6/08/2016 at 3:04 AM, bernhard said:

i think some more explaining words in the field descriptions would be a great help!

Agreed. Also, the module description on GitHub and the modules directory seems to contradict the above so perhaps that needs to be corrected?

Quote

This cronjob (hooks on LazyCron) is executed by a call to module: ProcessPageView.
Runs only if current user has db-backup permission. Permission will be added with module installation. Assign the permission to the roles which should trigger the process.

 

[kixe]

@Robin S
Thanks for he help. I am a bit too busy to answer in time.
 

18 hours ago, Robin S said:

Agreed. Also, the module description on GitHub and the modules directory seems to contradict the above so perhaps that needs to be corrected?

Agreed. If I'll find some time, I will make an update. Apart from this I hope module is doing its job ...

[kixe]

Pushed update 1.1.5

[bernhard]

@since 1.1.5 added CTA Button to ProcessDatabaseBackups page (edit backups) 2016/11/28

for anyone wondering as well

[kixe]

@bernhard

1 hour ago, bernhard said:

for anyone wondering as well

CronjobDatabaseBackup and ProcessDatabaseBackups are siblings. I put them a little closer together.

[arjen]

Hi @kixe,

Have you seen my PR? It would be very convenient to be able to allow the job to run on certain hostnames. This idea is 'stolen' from the ProCache module.

[Tyssen]

Feature request: the ability to have backups sent via email as well as saved on the server.

[Noel Boss]

Thanks for the great Module! How about providing a default name if no name is present? 

#-%Y-m-d-H-i-s%

Or a better description with an example, I had to go into code before I realised that I had to surround "all" of the date format with %. before I tried to surround every parameter (like %Y%-%m% etc)...

[bernhard]

it will create a default name (database name). or are you talking about a configurable default name?

[Noel Boss]

Yes, it uses # as default name resulting in dbname-1.sql, dbname-2.sql etc – so one can not easily tell how old the date is... Since PW itself already uses a name with date appended when backing up to the same folder on upgrades, why not use the same?

The format PW uses:

dbname-Version-YYYY-MM-DD_HH-ii-ss.sql

processwire-3.0.86-2018-01-09_13-36-54.sql

[kixe]

@noelboss
ProcessDatabaseBackups (by Ryan) uses the same default format as CronjobDatabaseBackup (e.g. dbname-1.sql)
whereas the core class WireDatabaseBackup uses the default format: dbname_YYYY-MM-DD_HH-ii-ss.sql

2 hours ago, noelboss said:

dbname-Version-YYYY-MM-DD_HH-ii-ss.sql

I don' t know where this format is in use.

Since CronjobDatabaseBackup is built very close to ProcessDatabaseBackups I will stay compliant and don't want to change the current default format for the filename.
Anyway you have always the option to modify the format for your needs in module settings, even in the format you prefer.

[Noel Boss]

Okay, sorry, didn't know - then its probably the update module that does format the files this way. Never the less, I still think having the date in the filename would be the best default in the majority of cases, since if you want to restore a backup, you‘d probably want to know the date anyway. 

But no problem for me, I figured it out, its just that I tought maybe that would help some to get started faster. Still great Module without this change.

[Noel Boss]

Hi Kixe

Great module, thanks! Saved my site this weekend ?

I have two suggestions as I reviewed my settings. I noticed someting that would probably be easy to implement and at least for me usefull:

– No maximum limit of backups (max): why would that option be limited to 100? If I want to store 6hours backups for 3 months, 100 is not enough.

- More flexible remove option (deadline): Provide an integer 1-99 plus a intervall: Hours, days, weeks, months years.

This way, one can tailor backups and removal very flexible. The current limitations seem very arbitrary for me.  On last thought: If it is possible, it would be nice if one can specify a time at which the backup would start – I know, this would just be an indication but still, one could plan the backups for say during night.

[d'Hinnisdaël]

Would it make sense to add an option to exclude tables from the backup, instead of choosing the tables to include?

This would be especially useful with regards to the sessions table. I have a project with a moderate amount of visitors, but 1million+ rows in the sessions table. The backup module fails since the process needs too much memory. If I exclude the sessions table, the export shrinks from 150MB to 30MB, which the server can easily handle.

Now, I can already select all tables and leave the table sessions unchecked. However, as soon as I add a field, template, etc., all future backups will be missing that table completely. In that scenario, an exclude option would be the better option.

I might just whip up a PR when I find the time, but was wondering if anybody else feels this is necessary or a good idea.