Database operations with Govard: dump, import, anonymize

Part 5 of the Govard in Depth series — safe database copies without leaking customer data.

Why database copies are a liability

Every Magento store runs on its database. Orders, customers, catalog rules, CMS blocks, configuration: all of it lives in MariaDB, and every debugging session eventually needs a copy of that data. The standard move is to dump production or staging and import it locally. That works, and it is also where most teams quietly take on risk.

A raw production dump contains names, email addresses, street addresses, phone numbers, and order histories. Copy it to three laptops and a shared staging server and you now have four unguarded copies of personal data, usually without expiry, encryption, or access control. Under GDPR that is not a shortcut, it is a breach waiting for an audit. The fix is not to stop sharing dumps. It is to make the safe path, dump, import, anonymize, the default path, and to make it fast enough that nobody reaches for the raw dump instead.

Govard treats the database as a managed service inside the environment, not as a file you pass around over chat. Dumps are taken from inside the container stack, imports land in the same place, and anonymization runs as a defined step rather than a manual SQL session everyone forgets.

Dumping and importing with Govard

The database container is pinned in configuration, so a dump taken on one machine imports cleanly on another. There is no version mismatch to chase, no host MySQL fighting the container on port 3306.

A typical cycle looks like this:

# Take a compressed dump from the staging environment
govard db dump --env staging --gzip --out /tmp/staging-2026-10-01.sql.gz

# List what you have before importing anything
govard db list-dumps

# Import it into your local environment (drops and recreates the local db)
govard db import --env local --file /tmp/staging-2026-10-01.sql.gz

# Confirm the store sees the new data
govard env ps
govard tool magento cache:flush

A few details matter here. The dump command runs inside the stack, so it uses the same credentials and MariaDB client version as the running container. The --gzip flag is worth making a habit: a Magento production dump easily runs to several gigabytes uncompressed, and compression cuts transfer time to a fraction. The import command is deliberately destructive toward the target only: it replaces the local database, never touches the source, and prints which environment it is about to overwrite before it proceeds.

For teams that refresh often, the pattern is to dump once from staging, store the artifact where the team can reach it, and let each engineer import locally. Nobody dumps production directly to a laptop. Staging becomes the single funnel, which means one place to enforce the next step: anonymization.

Larger stores should also think about what they do not need. A full dump with all log, session, and report tables can double import time for zero debugging value. Truncate the disposable tables before dumping, or keep a documented table-group exclusion list in the project so every dump skips the same dead weight. Faster dumps get refreshed more often; slow dumps get skipped, and then engineers debug against month-old data.

Anonymize before the dump travels

The rule is simple: no dump leaves the server it was taken on with real customer data in it. Anonymization rewrites PII columns to plausible but fake values while preserving shape: email addresses stay unique and well-formed, names stay readable, addresses keep valid structure, but none of them identify a real person.

# Anonymize the staging copy in place, then dump the clean version
govard db anonymize --env staging --profile magento2
govard db dump --env staging --gzip --out /tmp/staging-anon-2026-10-01.sql.gz

# Spot-check before sharing: real addresses must be gone
govard db query --env staging "SELECT email FROM customer_entity LIMIT 5"
govard db query --env staging "SELECT firstname, lastname, telephone FROM customer_address_entity LIMIT 5"

The magento2 profile knows which tables carry PII: customer_entity, customer_address_entity, sales_order, sales_order_address, quote, newsletter subscriber tables, and the admin user table. It replaces emails with generated values under a reserved domain such as [email protected], scrambles names and phone numbers, and resets password hashes to a known development value so nobody can log in as a real customer with a leaked hash. What it preserves is equally important: entity IDs, foreign keys, store scoping, and order totals stay intact, so checkout flows, order grids, and customer segments still behave like production.

Run anonymization on the server side, against the staging copy, before anyone downloads anything. That ordering is the whole GDPR story: the artifact that travels is already clean, so a lost laptop or an over-shared link exposes structure, not people. Keep the raw dump on the server with a short retention window and delete it after the anonymized version is verified. Document that retention in the project README so a new hire does not discover a year of raw dumps in shared storage.

One more check worth automating: after anonymizing, grep the dump for your own company domain and for common real domains before distributing it. If SELECT DISTINCT email FROM customer_entity still shows real addresses, the profile missed a custom table or an extension stores emails in a nonstandard column. Custom modules that add PII columns need to be added to the anonymization profile explicitly. The first time you audit this, you will likely find one.

Pitfalls

• Importing into the wrong environment. The import target flag is the most dangerous argument in this workflow. Always confirm the --env value in the pre-flight prompt; a local filename plus a staging target is how a team loses a day.
• Shipping raw dumps to laptops. If anonymization is a manual step someone runs "when they remember," it will be skipped under deadline pressure. Put it in the documented refresh procedure, in order, with the verification queries.
• Forgetting custom PII columns. Loyalty modules, custom checkout fields, and marketing extensions all add their own tables. Audit them once, extend the profile, and re-check after every major module install.
• Dumping production instead of staging. Production dumps carry the freshest PII and the highest blast radius. Funnel through staging unless there is a specific reason not to, and write down what that reason was.
• Keeping dumps forever. Old dumps on shared drives are forgotten PII archives. Date the filenames, set a retention window such as 30 days, and delete aggressively.
• Skipping the post-import cache flush. Magento caches configuration and layout in Redis, not in the database. After an import, flush cache and reindex what the project requires, or you will debug phantom issues that are just stale cache.

Next in this series: Deploy and rollback with Govard — /blog/govard-deploy-rollback