All that's the use case I have in mind for looking at the Backup and Migrate module. Eventually I decided to punt and see if there were a way to export the content from my site and import it into a fresh Drupal install. While Backup and Migrate did the job I'm not happy with how it did so, and I think the episode points to a crucial flaw in Drupal's featuritis. Namely: There is no way to export the site content and as a result your content is entrapped inside Drupal.
Consider if you wish to migrate away from Drupal to some other content management system. How would you do so? Your content is buried inside the Drupal database and while you could do some database queries to access the content, the database structure is more than arcane. There are several import/export modules in the Drupal ecosystem but none of them served the need I see here. Interestingly there are several modules that facilitate importing content from specific other CMS's into Drupal, but the support for exporting from Drupal is nearly nonexistent.
Installing and using Backup and Migrate is fairly simple. It installs just like any other module, drop it into the modules directory and enable it in the modules admin page.
Once installed it appears in the Content Management section of the admin area. Usage is very simple, you are presented with a list of database tables, you select the database tables to export then click on "Backup Database". Your browser will begin downloading a .sql file containing the SQL commands to recreate the given database tables.
To effectively use this module you must have an inkling of the database structure and which tables are important to backup and migrate for the purpose you have in mind. Obviously this is not very user friendly and is not for the neophyte Drupal user.
Another consideration is compatibility. The Drupal database is a constantly changing thing, and each software update can modify table structures. This is one reason why it's required to run update.php on each software update, to make sure the database structure is properly updated. What you receive is a raw database dump, and there is no attempt to abstract away the details. Hence to successfully import this data anywhere else it must be into a Drupal install which is roughly the same version from which the export was made.
This is how my disaster recovery scenario unfolded:-
- After two days of frustration and troubleshooting...
- Install backup & migrate
- Set up new.davidherron.com with a fresh clean Drupal install
- In new.davidherron.com I only initialized the minimum of modules
- Export the desired tables from davidherron.com. I very carefully selected the tables I wanted (actually, I guessed) aiming for modules related to the content, content types, etc.
- In new.davidherron.com go to its Backup & Migrate, and import those tables.
- I had to do this twice because the first time through the resulting site went insane after a couple steps. On the second time through I used mysqldump at several steps so that I could easily recover back to the previous mysqldump.
- Start enabling the modules. Several times when enabling modules it gave a message about the tables already existing, and yes of course they already existed because the import created those tables.
- This was followed by several hours of debugging, and making sure all the settings in the old site were recreated in new.davidherron.com
- The toughest one to resolve was to get imported CCK fields recognized properly. The CCK fields were kind of recognized but going into "manage fields" resulted in a message that some fields were missing their modules. Huh? What I did was disable the related modules, uninstall those modules, and then re-enable those modules. Afterward the fields were magically okay and displayed correctly.
- When I was satisfied I pulled some server side magic to make the content on new.davidherron.com be on davidherron.com, and the content previously there on old.davidherron.com.