[support] WAS Why .. now 3 ways to save the db which is best

Metzler, David metzlerd at evergreen.edu
Wed Jul 13 18:25:39 UTC 2011


Um... you do understand that this is data, right? It can't be thought of
like source code.  You will never get exactly the same data twice, even
if you haven't edited a single thing on your site. 

Every DB export will be different.  There are even session variables in
the DB, so it's not like you can use it to track changes.   What
difference does it make which backup methodology you choose as long as
you've tested the restore?  I assume that's what you're using it for,
since it really doesn't make sense from the version control perspective.


I'd use the dump method since you're really not trying to synchronize
between two dbs.  3.  seems dangerouse since it will try and backup and
restore over the top of the same site in a single execution which is not
what the script is intended for.  Seems like asking for trouble.  

-----Original Message-----
From: support-bounces at drupal.org [mailto:support-bounces at drupal.org] On
Behalf Of Andy Heath
Sent: Wednesday, July 13, 2011 10:58 AM
To: support at drupal.org
Subject: Re: [support] WAS Why .. now 3 ways to save the db which is
best

Following on from my post one twig up in this thread ..

So now I have three ways to save the database:

1. syncing from another machine with %dump=wherever... in the alias
2. drush sql-dump --result-file=wherever...
3. drush sql-sync @mysite @mysite

They all produce different sql - which is best?

 From a processing perspective admittedly 3. is terrible because I 
presume it exports the db then re-imports it.

I seek a reliable practice to adopt then if I always do it the same way 
I can happily shove the current db in a git repo (hey its only a small 
database).

andy

-- 
[ Drupal support list | http://lists.drupal.org/ ]


More information about the support mailing list