Data Migration using DB Backups

[daveto]

Hi all,

a client of ours has been entering data on their staging environment
but needs to have that data on QA. The codebase for both are
constantly in flux. Our current strategy is to take a backup of the
Staging database, including Versioned, non-Versioned data, and then
replicate it for use by the QA instances.

I know the normal way is to use the standard ATG export/import
scripts, however, we are going to try the quick and dirty method. My
question is, do you see any significant risks in doing this? Will it
work? My main points of concern are:

1. BCC publishing, will versioning snapshots/branches/etc. remain
intact?
2. What sort of environment-specific info should we be ready to
address in the data?

Thanks for any insights on this...and I'll provide results after we
execute this in a weeks time.

Dave

[quicksilver03]

All the data from BCC and the epub schema will remain in the database,
however if you have file assets you'll have to copy them to your
target environment otherwise BCC will fail when trying to deploy them.

For the environment, definitely look into all the *server_id tables,
like dss_server_id, epub_server_id, etc.: try truncating the data in
those tables after the import. Another thing I will look at is the
das_id_generator table, I would set the id prefixes to be different
between the 2 environments, something like "i" in integration
environment and "q" in QA once the data is imported, to avoid ID
clashes if you decide to run an incremental export/import and somebody
has created some data in QA in the meantime.

[daveto]

Thanks Quicksilver03,

We don't have any file assets so that should make it easier. However,
will look at dss_server_id and epub_server_id tables to see what
environment-specific data is there and possibly truncate. We are
planning to shut down all systems and ensure there are no deployments
before we do the database swap. That should prevent any ID clashes
when the systems come back up again. Moreover, with a db swap, the
DAS_ID_GENERATOR table will be moved along with the rest of the DB so
will overwrite any changes we make to the prefix values in the QA db.

Dave