Probar con datos reales encuentra problemas que los datos de prueba no encontrarán jamás. También pone cada nombre de cliente, cada dirección y cada pedido en un servidor protegido con menos cuidado; por eso la copia se hace a propósito, no con un volcado pelado.

Qué quitar

  • Los datos de pago y los tokens, incluso los últimos cuatro dígitos.
  • Los hashes de contraseñas, sustituidos por un valor conocido para poder entrar como cualquiera.
  • Las claves de API y los secretos de webhooks guardados en tablas de ajustes.
  • Todo lo que tendría que notificar si se filtrase.

Qué reescribir

Las direcciones de correo, por encima de todo. Una prueba que manda cien confirmaciones de pedido a clientes reales es, con diferencia, el accidente más común en pruebas, y no tiene vuelta atrás.
UPDATE users SET
  email = CONCAT('user', id, '@example.invalid'),
  phone = NULL,
  password_hash = '$2y$10$known.test.hash';

A example.invalid no se puede entregar nunca: está reservado exactamente para esto.

Hágalo en una sola pasada

mysqldump --single-transaction live_db | \
  gzip > /tmp/live.sql.gz
zcat /tmp/live.sql.gz | mysql staging_db
mysql staging_db < scrub.sql   # the UPDATEs above
rm /tmp/live.sql.gz

Guarde la limpieza como un archivo en el repositorio, para que la siguiente persona haga lo mismo y nadie tenga que acordarse de la lista.

Luego las URL

wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com' --all-tables --precise

Sáltese lo que no necesita

mysqldump --single-transaction --ignore-table=live_db.sessions --ignore-table=live_db.audit_log live_db

Las tablas de registros y de sesiones suelen ser casi todo el tamaño y nada del valor.

Si los datos son tan delicados que limpiarlos le pone nervioso, no los copie. Genere en su lugar un conjunto pequeño y realista, y guárdelo en el repositorio.