From days to seconds

28 April 2026 6 min read #FromDaysToSeconds

Backup–restore takes hours. Self-service cloning takes seconds. We sat down and measured both — properly, end-to-end, on a workload that looks a lot like the ones our customers actually run. Here's what came out the other side.

The setup

We didn't want a benchmark that flattered anyone, so we built something that looks like what we see on real customer estates: a single SQL Server 2022 OLTP database, around 500 GB of row data, 320-odd tables, and six of those tables carrying serious PII (users, customers, audit logs, payments, support tickets, marketing contacts). Nothing exotic. Nothing toy-sized.

We timed one thing, and one thing only: request issued → clone usable. That's the number a developer actually feels — everything else is bookkeeping.

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.

On paper, even a well-tuned restore pipeline rarely gets the whole thing done in under two hours. In real life — with a DBA juggling four other tickets, a network share that's having a bad day, and someone in the next room shouting "did anyone run the masking script?" — it routinely stretches to half a day. And that's before we count the runs that quietly fail because the target SQL Server is two versions behind, or because the .bak was copied while still being written.

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 under 50 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 unglamorous: we do the expensive bit — masking and reducing — exactly once, at import. After that, every clone is essentially free. Teams routinely spin up twenty fresh environments in the time the old workflow took to do one, then knock them all down at the end of the sprint without thinking twice about it.

"But what about all the bulk data?"

This is, hands down, the question we get most often — usually with a slightly worried look. The honest answer is that almost every team, once they try it, discovers they weren't actually using that data. The clone keeps the full schema, the constraints, the relationships, and a representative sample of rows. If there's a specific record you genuinely need (a particular customer, a certain row count for load testing, a known-bad payment to reproduce a bug) you script it in once via the SQL Script Set step, and it's applied automatically to every future clone. Nobody has to remember.

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 usually costs less than the cloud bill they were already paying to store full-size clones.

← Back to all articles