Since drush no longer allows folders called "backup" to exist in the root of the drupal site, and thus puts backups in "~/.drush-backup", it no longer keeps backups for different sites separate. I have about 10 different Drupal sites on my computer, and if I use Drush to keep them up-to-date, all of the backups from all of the different sites are all mixed up. This makes the backup pointless.

Comments

moshe weitzman’s picture

moshe weitzman commented

You won't call them pointless after you accidentally drop a DB in prod :)

I agree that this needs work. Please suggest a folder hierarchy that works better. Note that we store code and db dumps in this folder.

If you like a certain hierarchy, use the --backup-dir option in updatecode and specify a value for --result-file in sql-dump. You can save your prefs to a site specific drushrc.php file.

greg.1.anderson’s picture

greg.1.anderson commented

From IRC:

The backup should also store a 'manifest' file with enough information that we could also do a 'restore' command. There is a discussion of this at http://groups.drupal.org/site-archive-format.

It also appears that drush_make has done some work in this area: #910732: RFC: PATCHES.txt format

These features have overlapping goals with what I wanted to do in #908212: drush vcs commands. If we have a 'restore' command, seems it would also be good to be able to do a full backup (in addition to the 'incremental' backup done by pm-updatecode), and if we are doing backup / restore, then the database must also be saved somehow, because restoring files w/out changing the database can result in a corrupt Drupal site.

pukku’s picture

pukku commented

I've been thinking about this over the weekend, and it seems to me that in most cases, the simplest likely-to-be-useful solution is to have ~/drush-backups (I don't think there should be a '.' at the start, but that may just be me), and inside that, have a folder with the name of the folder enclosing the drupal site that drush is working on, inside of which are the datestamp folders. In the worst case, this degenerates back to the current situation.

moshe weitzman’s picture

moshe weitzman commented

Seems reasonable. Anyone think this enclosing folder name is better or worse than database name for top level?

greg.1.anderson’s picture

greg.1.anderson commented

I agree that it would be better if there were no "." in drush-backups. Perhaps if .drush-backups exists, we should continue to use it.

The advantage of the database name is that it is most likely to be unique for the least amount of work. There are all sorts of other things we could do if we wanted to work harder to find the default. If the folder containing settings.php is not default, then it is a good name to use. If it is default, then we should try to find a better name for the site. We might find something in @self, we could use the database name, we might find something in $base_url (if it is set in settings.php), and we might find something somewhere in the full path (but the heuristic here is perhaps too complicated).

Whatever we try, those who are dissatisfied can always set the backup dir explicitly.

moshe weitzman’s picture

moshe weitzman commented
Version: All-versions-4.0-rc3 »
Status: Active » Fixed

I decided to go ahead with this now. I changed .drush-backups to drush-backups and now the top folder is derived on database name unless the caller has specified differently. I tested as best I know how.

pukku’s picture

pukku commented

Hi! I like the use of the database name better than my idea...

Thanks for the fix!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.