I need help understanding the recommended approach for disabling a backup on a testing or development environment. Is there a simple variable setting I can include in my settings.php (or template.php) to disable one or more schedules?

With version 7.x-2.x, I was creating all my schedules and destinations and profiles entirely via settings.php, following a method similar to that described by aklata here:
Add ability to enable/disable backup scheduling in settings.php
Using this approach, I wouldn't have any backup profiles or schedules saved in the database on my production site, and would store them all in the settings.php file. Then I simply didn't include those settings on my development/testing/staging sites.

I understand that with 7.x-3.x, that is no longer the recommended approach. So now I've got an exported template that I can use to quickly import a standard backup scheme into any site (cool!). But since that schedule now lives in the database, I'd like an easy way to disable the backups on my other environments, so that I can bring a database over from the live site without manually disabling the scheduled backups after I do so.

I gather Features would help with this, but it looks like all it needs now is a simple variable edit somewhere ('enabled' => '0'). But where?

Alternatively, I would welcome helpful advice on a better approach to achieving the same thing with 7.x-3.x.

Comments

ronan’s picture

ronan CreditAttribution: ronan commented
Status: Active » Closed (works as designed)

That method still works in the 3.x version. You can export the schedule and simply add:

$conf['backup_migrate_schedules_defaults']['schedule_name'] = [[EXPORTED CODE]]

to your settings.php

I hope this helps. Let me know if it doesn't work.

ronan’s picture

ronan CreditAttribution: ronan commented

It should be noted, that any changes you make to the DB will override the defaults in settings.php. So you may need to delete the shedule from your database (it should be labeled 'revert') after you export.

pkiff’s picture

pkiff CreditAttribution: pkiff commented

Great! Thanks, ronan. I got it working now.

I wasn't quite sure how to connect the new fields up with the right schedules since my old settings.php backup_migrate code from 7.x-2.x produced errors.

For others who might be looking to do this, here is a sample backup variable config from a production environment settings.php file running backup_migrate 7.x-3.x.

/**
 * Backup Configuration
 * Automatic database backups and schedules are custom configured here so that
 * they only run on the live server, even when the database is copied over from
 * the Production server to the Local, Development, Testing, or Staging servers. 
 * For this to work reliably, all custom Backup and Migrate settings in the 
 * database should be reverted to their defaults using the standard admin UI.
 * The settings below will then overwrite those default settings.
 */

 /**
 * Define backup_migrate variables
 * These variables are used to help build a better custom filename.
 * The drupal core version should be updated whenever  you update core.
 */
$drupal_version = 'drupal734';
$short_site_name = 'short';

/**
 * Define backup_migrate profiles
 * This is an edit of the default profile. It is used to configure 
 * a better custom filename.
 */
$conf['backup_migrate_profiles_defaults'] = array(
  'prof_default' => array(
    'profile_id' => '1',
    'machine_name' => 'default',
    'name' => 'Default Settings',
    'filename' => $short_site_name. '-' . $drupal_version,
    'append_timestamp' => '1',
    'timestamp_format' => 'Y-m-d\\TH-i-s',
    'filters' => array()
  )
);

/**
 * Define backup_migrate schedules
 * This is a basic hourly database backup with Smart Delete enabled.
 */
$conf['backup_migrate_schedules_defaults'] = array(
  'sched_hourly' => array(
    'schedule_id' => '1',
    'machine_name' => 'hourly',
    'name' => 'Hourly Database Backup',
    'source_id' => 'db',
    'destination_id' => 'scheduled',
    'copy_destination_id' => '',
    'profile_id' => 'default',
    'keep' => '-2',
    'period' => '3600',
    'enabled' => '1',
    'cron' => 'builtin',
    'cron_schedule' => '0 4 * * *',
    'type_name' => 'schedule',
  )
);
peterpearson’s picture

peterpearson CreditAttribution: peterpearson commented

Thanks for the example. I'd also suggest the current Drupal version is available on the VERSION constant in settings.php. It would seem safer to use that than trust $drupal_version gets updated manually.