Posted by radman16 on September 25, 2008 at 2:54am
Jump to:
| Project: | Backup and Migrate |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Instead of just being able to set backups to run every X number of hours how about doing something similar to cron jobs where you can set it to run every X hours or at a specific time daily or certain days of the week etc.
btw this is a great module
Comments
#1
Hmm.. not a bad idea, I can see the value in having the module run in off-peak hours. I'll put it on the todo for version 2 (version 1 is feature stable)
#2
Great, I will look forward to trying out version 2.
#3
I second this. I'd love to be able to set it to backup every day around 0500.
#4
I just used the devel module's variable editor and the online tool at http://www.unixtimestamp.com to change my settings. I'll try to remember to come back and report success or failure.
#5
The technique I tried in post #4 did work - took a couple of rounds to get it to stick. However, the backup time is creeping up an hour a day.
#6
What variable did you change? I only can see:
backup_migrate_destination_id
backup_migrate_profile_id
backup_migrate_source_id
#7
I'm not sure what excactly @bluerobot did, but he probably edited the last run time of the schedule to make the module think it had run at 5am so that it would run again 24 hours later.
To stop the time creep, try setting the period to slightly below 24 hours. 1430 minutes for example. That way the period will definitely have expired by the time cron runs and execution gets to backup and migrate.
#8
This would definitely be a useful feature. I am considering preparing a patch, but there are a few different directions I am considering.
Options 1 and 2 are nice because they allow very flexible scheduling by leveraging existing scheduling code, but they are more complicated to administer.
Any thoughts on these options or some options I missed?
#9
subscribing
Some cron mechanism sounds good to me, or could it be invoked by Actions or Rules?
#10
Backup and migrate can be run using actions, but only using the default settings. The module doesn't work with Rules, but it used to work with workflow_ng, so I should be able to add back Rules support fairly easily.
I'm not aware of any way to get cron-like scheduling with either Actions or Rules but if such a thing does exist then I can add better support for those modules to allow this feature to work.
Anybody know if this kind of scheduling is possible?
#11
With elysia_cron http://drupal.org/project/elysia_cron everyone can associate a cron rule to backup_migrate_cron such as "0 0 * * 0" to run backup job every sunday at midnight.
A module developer can add a default rule to his module by adding some lines of php:
function backup_migrate_cronapi($op, $job = NULL) {switch ($op) {
case 'list':
return array(
' backup_migrate_cron' => 'Backup and migrate',
);
case 'rule':
return '0 0 * * 0';
}
}
This way everyone installs backup and migrate and uses elysia cron will have the default execution rule to "every sunday at midnight".
#12
Very interested as well. I like being able to take my site offline when the backup takes place but I don't want this to happen during business hours. I think option 1 here is the best so we don't have to reply on another module for something that seems simple. I don't think a specific time is as important as long as its just off peak. Settings cron jobs is pretty easy so I don't think this would be too much of a burden on administrators.
- Jayson
#13
Would also like this to guarantee off-peak backups. Does this go into D7 first and backport?
#14
A possibility similar to Option 1 (in #8 above) is to use the backup_migrate drush support. In theory a cron job could be setup that uses drush to run a backup.
Unfortunately, backup_migrate doesn't work with Drush 3.0 (see #720580: Drush 3.0 doesn't allow spaces in commands and #715472: "drush bam destinations" is an empty list). I haven't tested backup_migrate with Drush 2.x.
I would suggest that improving drush support (plus some documentation) will resolve this issue.
#15
subscribing...
#16
Going to be bold and move to D7 since that is customary place for new features.
#17
subscribing
#18
looking forward to seeing the results of this thread...
#19
I'm curious what bluerobot did in #4 & 5 myself, like #6 I found only those backup_migrate vars, and I'm not sure what to do with the info #7 provided. Thanks!
#20
subscribe
#21
Subscribe
#22
I'm running the current dev version of B&M module but in the Devel variable editor, I see no variables related to backup/migrate/schedule etc. Currently my backup is running at 10am daily which is at peak usage time. I'd like to set it to 3am.
I suppose I could wake up at 3am and create a new daily schedule ;-(
#23
I am also interested in wich variable #4 exactly has to be editet. can not find one...
#24
subscribing
#25
subscribing
#26
Subscribing
#27
For those looking to change the D6 schedule time by editing the variable, backup_migrate 6.x-2.2 doesn't store the last run in a variable, it's in the last_run field in the backup_migrate_schedules table in the database. The unix time stamp bit still applies, of course.
#28
subscribe
#29
subscribing (hope to see some of this for D6 still.....)
#30
subscribe
#31
(D6) What I did for this was to add a module and define hook_cron:
<?phpfunction backupmigrate_schedules_time_fix_cron(){
/**
* Fix backupmigrate schedules time for slight difference in cron run
*/
$result = db_query('SELECT schedule_id, last_run FROM {backup_migrate_schedules} WHERE enabled = 1');
while($row = db_fetch_array($result)){
$last_run_date_time = new DateTime();
$last_run_date_time->setTimestamp($row['last_run']);
$last_run_date_time->setTime(3, 0); // set the time as you wish: DateTime::setTime ( int $hour , int $minute [, int $second = 0 ] )
$last_run = $last_run_date_time->getTimestamp();
db_query("UPDATE {backup_migrate_schedules} SET last_run = %d WHERE schedule_id='%s'", $last_run, $row['schedule_id']);
}
}
?>
#32
thx farshid!
#33
subscribe for 6.x and 7.x
#34
Can anybody explain how to use the code of farshid?
#35
Andreyy, create a folder named: backupmigrate_schedules_time_fix
add 2 files in it:
1 - backupmigrate_schedules_time_fix.info, here is what you need in it:
name = "Backupmigrate Schedules Time Fix"description = "Fixes Backupmigrate Schedules Time!"
core = 6.x
package = Other
dependencies[] = backup_migrate
go to http://drupal.org/node/231036 for information on .info files
2 - backupmigrate_schedules_time_fix.module -> the code in #31 goes here
put the folder in sites/all/modules and install it in drupal admin section as any other modules.
You are good to go, I have not tested this, as I have added this to another module of mine, so post if any problems.
#36
Hi farshid
Unfortunatelly the manual run of cron generate error (cron running overtimed) and white screen.
#37
Andreyy
try increasing PHP max execution time in php.ini if the problem resists, first you need to find out the module causing problems... I have found some related code somewhere, I do not remember, though here it is:
go to includes/module.inc and find: function module_invoke_all(), add some code to watch for cron hook calls:
<?phpfunction module_invoke_all() {
$args = func_get_args();
$hook = $args[0];
unset($args[0]);
$return = array();
foreach (module_implements($hook) as $module) {
$function = $module .'_'. $hook;
/**
* log cron calls to find out which module to blame:
*/
if ($hook == 'cron') {
watchdog('cron', "hit $module cron");
}
/**
* .
*/
$result = call_user_func_array($function, $args);
?>
run cron and after the WSOD appears go to dblog to find out on which module cron you are having problems... disable the module and test again. wish this helps... though this topic is not the place to talk about it. sorry guys.
#38
Hi farshid,
I get the white screen when I switch on module backupmigrate_schedules_time_fix.