I was about to start porting a 'site-synch' module I'd done for 4.6 up to 5.0, and thought I'd see if I could start with reference to this module.
I've had a look at both the current 4.7 and the (vastly different) 5.0 proposed version. Neither provides the hooks I was looking for.

My previous project was for synchronising nodes and admin settings between different deployments - getting incremental changes from a dev server to a live server. This was done by hijacking the UI and redirecting the form submissions. Quite a different job from what backup is trying to do of course, but in a related area.

I planned to have a 'backup site now' button which can freeze a file+db snapshot - locally.
This could be followed by a 'deploy' sorta button which SENDS this site to another host (SCP/FTP) and then somehow invokes (RSH or RPC) and un-bundle over there.
I've already done a bunch of shell scripts that do this nicely, but was looking into a configurable Drupal interface for it.

I imagined backup.module could assist with the first half, but not until the core _backup_backup() function became a lot more configurable and modular.
I like the error-checking and security handling it does so far, although I'm not quite sure what actual use the _backup_get_files() listing process is to the user...
It may be feature creep, but options like 'save backup locally' vs 'download now' and several of the others mentioned in the issues here each look pretty easy to impliment.

Also, a backup scheme is only as good as its restore process ;-) . Surely an upload/restoration procedure should be added to this util.
Yes, I'll actually volunteer if I know what the state of play is with the current code.

Is there any point in me trying to work in with what we've got so far in backup.module (especially with 5.0 looking like a major prospective rewrite) or should I just start my totally different module from scratch?

FYI, my current scripts are:

backup_site_now.sh

#!/bin/bash

SITE='sitename'
DATE=`date +"%Y-%m-%d"`
DBUSER='me'
DBPASS='mypass'

echo backing up $SITE into archives

echo packaging database

mysql -u ${DBUSER} -p${DBPASS} drupal_${SITE} -e "DELETE FROM watchdog; DELETE FROM cache; DELETE FROM sessions; "
mysqldump -u ${DBUSER} -p${DBPASS} --compatible=mysql40 drupal_${SITE} > backups/${SITE}_database_$DATE.sql
gzip backups/${SITE}_database_$DATE.sql

echo packaging htdocs

tar -cf backups/${SITE}_htdocs_$DATE.tar htdocs/
gzip backups/${SITE}_htdocs_$DATE.tar

deploy_site_now

#!/bin/bash

SITE='sitename'
DATE=`date +"%Y-%m-%d"`
HOST='my.host.name'
HOSTTEMPDIR='share'
HOST_DESTINATION=www/projects/${SITE}
USER='me'
DBPASS='mypass'
DBNAME=drupal_${SITE}

echo Moving todays bundle over to target

scp backups/${SITE}_database_$DATE.sql.gz ${USER}@${HOST}:${HOSTTEMPDIR}
scp backups/${SITE}_htdocs_$DATE.tar.gz ${USER}@${HOST}:${HOSTTEMPDIR}

echo remotely unpacking
ssh ${USER}@${HOST} --exec \
  gunzip ${HOSTTEMPDIR}/${SITE}_database_$DATE.sql.gz \;\
  gunzip ${HOSTTEMPDIR}/${SITE}_htdocs_$DATE.tar.gz \;\
  tar -x --directory ${HOST_DESTINATION} -f ${HOSTTEMPDIR}/${SITE}_htdocs_$DATE.tar \;\ 
  mysql -u ${USER} -p${DBPASS} ${DBNAME} \< ${HOSTTEMPDIR}/${SITE}_database_$DATE.sql

(the scp relys on ssh keys being set up)

Comments

dmuth’s picture

Status: Active » Postponed

>Is there any point in me trying to work in with what we've got so far in backup.module (especially with 5.0 looking like a major
> prospective rewrite)

No, not at this point. I'm not so much rewriting the module as I will be importing code from my command-line backup utility and will be removing the existing code that downloads the file to the user's browser.

That being said, I like some of your ideas, and would like to revisit them once I release the 5.0 version of this module. So I'm going to mark this bug as "postponed" and come back to it later. Perhaps we can collaborate on a future release of each of our modules.

-- Doug