killswitch for dev / staging sites

I agree this is a needed feature - but I think hostname detection is too inflexible (for example HTTP_HOST is not available when running `drush cron`). What I propose instead is simply a master on/off switch for scheduled backups. There would be a radio button on the schedules tab, and developers can manipulate the variable directly in settings.php, for example:

if ($_SERVER['HTTP_HOST'] == 'example.com') {
  $conf['backup_migrate_schedules_run'] = TRUE;
}

This way you can use any logic needed, including host detection.

This patch adds a checkbox to the schedule page (enabled by default). It also adds a warning to the Drupal status report if backups are disabled, to reduce the change of accidentally leaving backups disabled in production.

whoops. hook_requirements should have been in the install file.

There's no need for special logic. The module can be fully configured from your settings.php. Since you presumably need to maintain different settings.php files for each environment, you can simply disable remote destinations on all but your production site. When I get a few minutes I'll dig up some documentation on how to configure the module in settings.php

Subscribe

Interesting. I looked at backup_migrate_item->all_items(), and it seems that variables can be defined that add items, but I don't see any variable that could unset them.
$conf['backup_migrate_schedules_defaults'] = array(); had no effect, since all_items() adds the database results to the item list.

This alter hook achieves the desired effect:

/**
 * Implements hook_backup_migrate_schedules_alter().
 */
function backup_migrate_backup_migrate_schedules_alter(&$items) {
  // Remove all the scheduled items for the -dev site.
  $items = array();
}

I put this in settings.php for testing, but of course it more properly belongs in a module. Given that writing hooks is out of reach for some users and site builders, I think a simple "off button" in the UI is still worth considering.

subscribe

@ronan — if you could point us to the settings.php-based solution you mentioned, it would be really helpful. My preference would be to only eliminate remote backups on dev sites, or to change the profile name in settings.php (so I can tell remote dev backups from remote production backups), rather than eliminating all backups as @grendzy's code does.

While there may be people would would benefit from @grendzy's contribution, by having this in code and not in the database, you don't have to remember to re-set it each time you import your production database to your dev site. Plus, I think any Drupal sitebuilders sophisticated enough to have development and production environments will be able to paste documented code into settings.php.

For those who are looking for this, I found some documentation here: #1820530: Document the ability to enable/disable backup scheduling in settings.php.

I think Bright Bold took care of linking to the docs for modifying a schedule in settings.php

You can also modify destinations and settings profiles in a similar manner.

For those looking to disable in dev/stage etc. I would recommend going the other direction and using settings.php to ENABLE schedules in prod. That way you won't have to worry about a new developer skipping the disabling step etc.

I hope this helps. Some day I'll spend the time to write up a proper handbook page on all this.

Trying to consolidate this issue. Marking as a duplicate of #1820530: Document the ability to enable/disable backup scheduling in settings.php.