The test database was copied from production a year ago. Recent releases passed testing but failed in production because of data patterns that did not exist in the old copy. The production data includes customer PII. What should the DBA do?

A database refresh replaces data in a non-production environment with a recent copy of production so testing reflects current volumes, distributions and edge cases. Because production holds personal data, the refresh process should apply masking or other de-identification before the environment is opened to testers, preserving realistic formats and relationships while removing real identities. This combines the testing value of current data with the data protection principle that non-production environments should not expose sensitive production records. Copying production unchanged gives testers real customer PII, broadens access beyond those with a business need, and may breach privacy regulations and internal policy. Fully random data protects privacy but discards the data patterns, skew and relationships that caused the production failures, so it would not solve the testing gap. Keeping the old copy preserves comparability but guarantees tests will continue to miss patterns introduced over the past year, which is the problem the scenario describes. Exam caveat: masking must keep referential integrity across tables, and the refresh process itself needs change control, since it overwrites the test environment. Operational check: script the refresh and masking steps, validate that no unmasked PII remains through sample queries, confirm row counts and key distributions resemble production, and schedule refreshes on a regular cadence.