I wrote my own for this, specific for my $DAYJOB application. It primarily focused on configuration tables, and optionally a slice of the main data tables. Th

I wrote my own for this, specific for my $DAYJOB application. It primarily focused on configuration tables, and optionally a slice of the main data tables. The tricky parts were: 1. Write code to write out DDL. This is easier than it sounds because not every DDL feature is actually used by the application. 2. Write code to dump out DML. Again easier than it sounds because not every datatype is used by the application. The tricky parts where automatic identity columns and large binary table. 3. The code from #1 and #2 has to be done in topological order (least dependent scheme objects to most dependent). After the DDL is write, write the DML. 4. A bit fancy streaming to ensure the webserver doesn't build everything up in memory before zip filing it and beaming it down the wire. 5. Some care needs to be taken for confidential information. User passwords (even bcrypted/scrypted) shouldn't come along. Nor should thinks like outgoing email server settings. Or incoming email server settings. I'm lucky as no PII or credit card details exist in $DAYJOB application. If done carefully the code should be insensitive to simple schema changes (new fields, new configuration tables). The goal behind it all is to produce a single (big) .SQL file that will recreate a working database. So worth the time and effort to create.