Module Cronjob Database Backup

[kixe]

... got lost in crone Here is another one ...
cronjob for database backup. All Informations here:
github: https://github.com/kixe/CronjobDatabaseBackup
PW Modules: http://modules.processwire.com/modules/cronjob-database-backup/
 

[bernhard]

got this error:

[Marty Walker]

I get that too even when I have the required LazyCron module installed.

[kixe]

@BernhardB & Marty
You can install the module via Soma's Modules Manager or download it manually and put it in the modules folder. This should work. I will try to fix installation with the 'Download and Install' option in PW.

1 hour later:

I could fix it. Should work now. Thank you for reporting.

Edited November 17, 2014 by kixe

[Marty Walker]

Many thanks. It installs fine now. When I go to the settings page I get this notice:

Notice: Undefined index: cycle in /home/sitename/public_html/beta/site/modules/CronjobDatabaseBackup/CronjobDatabaseBackup.module on line 165

[kixe]

@Marty Walker
Thanks for your debugging help. Everything fixed.

[netcarver]

@kixe

Thank you for this module - I don't know how I managed to overlook it until now. It should come in very useful.

Is there any chance you could either add an option to allow the automatically generated filename to include the creation date, or move the filename generation into a hookable method so people can supply their own name generator if needed?

Regardless of the above request, thank you again!

[netcarver]

@kixe
 
I forked your repo and made a few tentative commits. The results are here.
 
Changes include more options for the backup period and a hookable filename generation method. I haven't submitted any pull requests as I unified the indentation and line endings first and you might not want those changes.

[ceberlin]

It would be great if I could set the maximum number of backups created by this module I want to keep.

[Linda789]

Moderator note:

@Linda789

I am treating your post as spam unless you can prove otherwise.

You joined the forums today, and submitted 2 posts with a link to an outside resource which suspiciously looks like unauthorised advertising on your part.

Edited February 6, 2015 by kongondo
Possible spam

[MuchDev]

I was half way through trying to write this when I found your module. Thank you thank you thank you . Made really quick work of an important feature. 

[kixe]

@MuchDev
Thanks!
Try it!
Like it!
Mark it as favorite in the modules directory!

@ceberlin
I put it on the todo list.

@netcarver
Good remarks I will add your code soon.

[MuchDev]

K so I've now been using this module for 6 days and everything is working perfectly, lovin' it. So I guess the only thing that I would like is to be able to limit the amount of backups that this module creates and have that setting somewhere accessible either through a hard coded variable or the admin interface. I'm thinking just a delete function that is called when the latest backup is complete.  I'm going to take a look and see if that is something that I may be able to contribute.

[kixe]

Version update 1.1.0
Extended Module Setting Options
 

• Max number of backups
  Minimum 1, default and maximum 100 (defined in constant MAXFILES). Executed with each cron.
   
• Deadline
  Will remove backups older than selected time interval with each cron.
   
• Name format syntax
  # placeholder for db-name. Use surrounding % to escape date() format.
   
• Remove backups from module settings dialog
  Select how many backups you want to keep in storage. Klick *SAVE* to execute.

[MuchDev]

Thank you so much! Managing those backups has been a little bit of a pain, now the pain is gone. Nice touch with the cleanup, 20 backups cleaned out . This module is indispensable now. 

[bernhard]

how do you guys manage backups of your files (assets)?

[kixe]

I am working on this, but hadn't time to do. As a starting point this could help

date_default_timezone_set('GMT');

$path = "/home/yoursite/backups"; // full server path to the directory where you want the backup files (no trailing slash)

$hrs = 3600;
$days = 24 * $hrs;

$todaysdate = date('Ymd', time());

// Live Site Cutoff
$livecutoff = date('Ymd', (time() - (7*$days)));

$target = $path . "/site/" . $todaysdate . ".tar.gz";

$filelist = scandir($path . "/site");
foreach ($filelist as $backupfile) {
	if (stristr($backupfile, ".tar.gz")) {
		$filedate = explode('.tar.gz', $backupfile);
		if ($filedate[0] < $livecutoff) {
			unlink($path . "/site/" . $backupfile);
		}
	}
}

system("tar --create --preserve --gzip  --file=".$target." ~/public_html ~/mail ~/ftpconf",$result);
$size = filesize($target);
switch ($size) {
  case ($size>=1048576): $size = round($size/1048576) . " MB"; break;
  case ($size>=1024);    $size = round($size/1024) . " KB"; break;
  default:               $size = $size . " bytes"; break;
}

This is just a snippet for a first approach, nothing to use as is.

[bernhard]

are you planning to add this kind of functionality to your module some day? any planned date for this?

i'm just curious. no real need for me right now because i'm using plesks backup feature. i was just wondering because the database is just one part of the whole...

[kixe]

nothing planned. I think this feature could be useful in case of providing file uploads for frontenduser or so. Until now I have no need for this feature. Maybe tomorrow ...

[bernhard]

but how do you handle situations like when somebody deletes some files, then you restore a DB backup and the files referenced in the file-field are not stored in the filesystem any more?

[kixe]

as I said no need for me now. All assets I have to deal with are stored on my or my customers local machine. But you are right in case of file upload option for visitors file backup is a must.

[MuchDev]

but how do you handle situations like when somebody deletes some files, then you restore a DB backup and the files referenced in the file-field are not stored in the filesystem any more?

good question. For all file backups I rely on a combination of my daily\weekly\monthly backups through whm, I don't allow users to empty the trash and use the trashman module to allow users to restore any accidentally trashed files instead. I find that really clamping down on user permissions cuts down on these worries.

[kixe]

maybe this could help
https://processwire.com/talk/topic/9655-pre-release-remote-backup/?hl=%2Bbackup+%2Bfiles

[Juergen]

I have upgraded PW to the latest dev version (21) and now I get the following error if I want to open a backup:

Error: Exception: Unknown Selector operator: '' -- was your selector value properly escaped? (in /home/.sites/24/site1275/web/wire/core/Selectors.php line 283)

#0 /home/.sites/24/site1275/web/wire/core/Selectors.php(320): Selectors->create('0', '', ':7232549db11.sq...')
#1 /home/.sites/24/site1275/web/wire/core/Selectors.php(115): Selectors->extractString('0:7232549db11.s...')
#2 /home/.sites/24/site1275/web/wire/core/Selectors.php(104): Selectors->setSelectorString('0:7232549db11.s...')
#3 /home/.sites/24/site1275/web/wire/core/Pages.php(213): Selectors->__construct('0:7232549db11.s...')
#4 [internal function]: Pages->___find('0:7232549db11.s...', Array)
#5 /home/.sites/24/site1275/web/wire/core/Wire.php(397): call_user_func_array(Array, Array)
#6 /home/.sites/24/site1275/web/wire/core/Wire.php(332): Wire->runHooks('find', Array)
#7 /home/.sites/24/site1275/web/wire/core/Pages.php(320): Wire->__call('find', Array)
#8 /home/.sites/24/site1275/web/wire/core/Pages.php(320): Pages->find('0:7232549db11.s...', Array)
#

I dont know if the error exist only after the last upgrade or if it occured earlier.

What does this error message means?

[kixe]

@Juergen
Thanks for reporting. You cannot open or restoring a backup from CronjobDatabaseModule but in ProcessDatabaseBackups which is a module made by Ryan. I couldn't  reproduce your error in PW 2.6.21. You maybe could post a new topic in general support forum. Some more information would be helpful: is CronjobDatabaseBackup still doing its job? Could you try to restore from a backup created in the 2.6.21 environment? Thanks.