Gegen echte Daten zu testen findet Probleme, die Testdaten nie finden. Es legt aber auch jeden Kundennamen, jede Adresse und jede Bestellung auf einen Server, der weniger sorgfältig geschützt ist - die Kopie entsteht also bewusst und nicht mit einem schlichten Dump.

Was zu entfernen ist

  • Zahlungsdaten und Tokens - auch die letzten vier Ziffern.
  • Passwort-Hashes, ersetzt durch einen bekannten Wert, damit Sie sich als beliebiger Benutzer anmelden können.
  • API-Schlüssel und Webhook-Geheimnisse, die in Einstellungstabellen liegen.
  • Alles, was Sie melden müssten, wenn es nach außen gelangte.

Was umzuschreiben ist

Vor allem E-Mail-Adressen. Ein Test, der hundert Bestellbestätigungen an echte Kunden schickt, ist der mit Abstand häufigste Staging-Unfall, und er lässt sich nicht rückgängig machen.
UPDATE users SET
  email = CONCAT('user', id, '@example.invalid'),
  phone = NULL,
  password_hash = '$2y$10$known.test.hash';

An example.invalid kann nie zugestellt werden - es ist genau dafür reserviert.

In einem Durchgang erledigen

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

Halten Sie die Säuberung als Datei im Repository, damit die nächste Person dasselbe tut und niemand sich die Liste merken muss.

Dann die URLs

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

Weglassen, was Sie nicht brauchen

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

Log- und Session-Tabellen sind oft der größte Teil der Größe und kein Teil des Werts.

Sind die Daten so heikel, dass Ihnen beim Säubern mulmig wird, kopieren Sie sie nicht. Erzeugen Sie stattdessen einen kleinen realistischen Satz und halten Sie ihn im Repository.