Skip to content

Sanitize database exports

When sharing a database from a production LocalGov Drupal site with local developers, contractors, or other environments, you should sanitize it first to remove personally identifiable information (PII) and meet GDPR obligations.

There is currently no LocalGov Drupal–specific sanitization tooling, but the wider Drupal ecosystem provides everything you need. This page collects the relevant approaches.

Context for LocalGov Drupal sites

Most LocalGov Drupal sites only hold user accounts and personal data for content editors — not members of the public. Development partners are usually either in-house at the council or working under a contract that already includes data protection clauses.

The picture changes when a council uses webforms to collect submissions from the public. In those cases, sanitization should be considered on a case-by-case basis depending on the sensitivity of the data being collected.

Baseline: drush sql:sanitize

Drush ships with a built-in command that handles the most common sanitization tasks (passwords, email addresses, sessions):

drush sql:sanitize

Reference: drush.org/11.x/commands/sql_sanitize

This is a sensible default before exporting a database dump for local development. Run it against a copy of the database — never against production.

Extending sanitization for custom fields

drush sql:sanitize only knows about the fields it ships with. If your site stores additional personal data on the user entity — full name, address, organisation, phone number, gender, custom fields — you need to scrub those yourself.

You can hook into the sanitize command from a custom module to target site-specific fields. A walkthrough of the pattern is here: Drupal 9: Sanitizing Data With Drush (Hashbang Code).

The general approach: implement a sanitize plugin or hook in a small custom module and register the additional fields/tables that should be cleared or replaced with dummy data.

Webform submissions: separate database with localgov_forms_lts

For sites that receive webform submissions from the public, the localgov_forms_lts submodule (part of localgov_forms) lets you store webform submission data in a separate database from the main Drupal database.

This makes it straightforward to export and share the main database for development without dragging public submission data along with it, and to apply different retention/clearing policies to the submission store.

Reference: localgov_forms_lts README

Tooling and add-ons

Annertech maintains a DDEV add-on with helper patterns which could be also helpful für Drupal local development workflows: github.com/Annertech/annertech-ddev.

A typical sanitized-export workflow for a LocalGov Drupal site looks like:

  1. Take a dump of the production database into a working copy.
  2. Run drush sql:sanitize against the working copy.
  3. Run any custom sanitization (extended user fields, custom entities) implemented in a site-specific module.
  4. If using localgov_forms_lts, decide whether the separate submissions database is included in the export at all — typically it should not be.
  5. Hand the resulting dump over to the developer or environment.

Always pair technical sanitization with appropriate contractual data-protection terms; the two are complementary, not alternatives.

Contributing

If you've solved a sanitization problem on your LocalGov Drupal site — particularly for custom user fields, sensitive content types, or webform data — consider contributing the pattern back to the LocalGov Drupal documentation so other councils can reuse it.