Hi, This option would be very useful. As a workaround we have been using successfully:
/etc/backuppc/config.pl: do "/etc/backuppc/external-control.pl"; Our control script: BACKUPPC_CTRL_CONF="/etc/backuppc/external-control.pl" BACKUPPC_CTRL_DISABLE='$Conf{BackupsDisable} = 2;' BACKUPPC_CTRL_ENABLE='$Conf{BackupsDisable} = 0;' BACKUPPC_RELOAD_CMD="su backuppc -c '/usr/share/backuppc/bin/BackupPC_serverMesg server reload'" function disable_backup() { echo "Disabling backuppc dump runs." echo "$BACKUPPC_CTRL_DISABLE" > $BACKUPPC_CTRL_CONF eval $BACKUPPC_RELOAD_CMD } function enable_backup() { echo "Enabling backuppc dump runs" echo "$BACKUPPC_CTRL_ENABLE" > $BACKUPPC_CTRL_CONF eval $BACKUPPC_RELOAD_CMD } Best regards, Pavel. Robin Lee Powell napsal(a): > On Sat, Feb 12, 2011 at 10:29:12PM -0600, Les Mikesell wrote: >> On 2/12/11 9:46 PM, Robin Lee Powell wrote: >>> Would be Soooooo handy. >> But what would it mean? And what if one or more of the targets is >> unavailable and you never stop the retries and thus never finish? > > I mean finish all *currently running* backups, and do not start any > others at all. If one currently running ends in failure, that's > fine; don't retry. > > The point is to reach the server-off state without losing the 12 > hours spent on the current backup, or whatever. > > -Robin > ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/