From days to seconds

28 April 2026 6 min read #FromDaysToSeconds

Traditional backup–restore takes hours. Self-service cloning takes seconds. We measured both end-to-end on a representative SQL Server workload. Here's the breakdown.

The setup

We used a synthetic but realistic SQL Server 2022 workload that mirrors what we see on real customer estates: a single OLTP database with around 500 GB of row data spread across 320 tables, six of which carry significant PII (users, customers, audit logs, payments, support tickets, marketing contacts).

For each cloning approach we measured wall-clock time across the full developer-facing flow: request issued → clone usable. That's the only number that matters, because that's the number a developer actually feels.

The traditional path: backup, copy, restore, mask

1. Backup the source. ~30–45 minutes for a full backup, depending on compression and disk throughput.
2. Copy the .bak. ~10–60 minutes across the network, depending on size and link quality.
3. Restore on the target. ~25–60 minutes for a 500 GB database, longer with verify.
4. Run the masking scripts. ~30+ minutes to update PII columns, often with table locks.
5. Run post-clone setup. Connection strings, environment-specific seed data, configuration tables.

End-to-end, even on a well-tuned restore pipeline, this is rarely under two hours. On a busy DBA's day, with queue time and context switching, it routinely stretches to half a day or more — and that's before you factor in failed restores, mismatched SQL Server versions, or "we forgot to run the masking pass on this one."

The DataTamed path: scan, import once, clone forever

1. Scan for backups. Point the Backup File Scanner at any folder. ~seconds.
2. Import once. A four-step wizard turns the .bak into a reusable, masked database image. PII is detected and masked automatically. The image is typically 60–70 MB. ~10–20 minutes for a multi-hundred-GB source backup, run once.
3. Clone in seconds, every time after. Pick the image, pick a target server, optionally pick a SQL Script Set for environment setup. Clones complete in seconds because they're 70 MB, not 500 GB.

The trick is that the expensive part — masking and reduction — runs once, at import. After that, every clone is cheap. A team can spin up twenty fresh environments in the time the old workflow takes to do one.

What about the bulk data?

This is the question we get most often, and the answer is: most teams discover they didn't actually need it. The clone keeps the schema, the constraints, the relationships, and a representative sample. Anything you specifically need (a particular customer record, a certain row count for load testing) you script in via the SQL Script Set step — once — and it's applied automatically to every future clone.

The numbers nobody talks about

Cloning isn't only about the time the clone itself takes. It's about everything that gets faster downstream when cloning gets faster:

• CI build wall-time drops because integration tests run against a fresh database for every build.
• Sprint capacity goes up because feature branches don't share a single dev DB and stomp on each other.
• DBA bandwidth opens up for actual DBA work — capacity planning, query tuning, DR testing.
• Audit time shrinks because every masking event is logged in a single exportable report.

Use our clone-time calculator to put a number on what your team specifically would reclaim. Most estates see between 12 and 40 engineering days per year recovered — for a tool that costs less than the cloud bill they were paying for the storage of full-size clones in the first place.

← Back to all articles