Ten-Hour Window, Nineteen-Hour Full: Is 10 GbE the Fix?
A media company protects 180 TB of unstructured data on 14 Windows file servers holding about 22 million files. The weekly full starts Friday at 20:00 and must finish by 06:00 to avoid contention with rendering workflows. On a dedicated 1 GbE backup network the full now takes 19 hours; the daily incremental, with a 4% change rate, takes 5 hours and sometimes collides with the full when the previous one overruns. The team keeps 60 days of daily backups and 12 monthlies on a PowerProtect DD appliance. A storage engineer proposes replacing the 1 GbE links with 10 GbE and declaring the problem solved. The backup administrator wants to move to a deduplicated incremental-forever model with synthetic fulls and parallel streams, but is concerned about the first full and about restore time for a single 400 GB file server volume. The CISO has set an RTO of 8 hours for file services and an RPO of 24 hours.
1. Quantify whether the 10 GbE upgrade alone can close the gap, showing your calculation. State the assumptions that matter.
Read the worked answer
Required throughput for a true full is 180 TB / 10 h = 18 TB/h = 5 GB/s = 40 Gbps at line rate. A 1 GbE link at roughly 125 MB/s moves about 0.45 TB/h, so 180 TB would take about 400 hours. The observed 19 hours proves the current job is not moving 180 TB at line rate; it is likely using changed-block or deduplicated movement, or the 'full' is not a true full. A 10 GbE link at about 1.25 GB/s moves about 4.5 TB/h, so 180 TB still takes about 40 hours, four times the window. Even 25 GbE at about 11.25 TB/h takes about 16 hours. Therefore the link upgrade helps but cannot meet the window by itself. Key assumptions: sustained line rate, no file-system metadata bottleneck, no dedupe benefit, and no source read limit. With 22 million files, namespace scan and metadata overhead are material. The correct conclusion is to size the network for daily change and parallel streams, not for a repeated 180 TB full, and to change the data movement model.
2. Recommend a target design that meets the RPO/RTO while controlling first-full risk. Include at least three controls and how you would validate restore.
Read the worked answer
Use an incremental-forever policy with periodic synthetic fulls on PowerProtect DD, so the weekly window carries only change data. Enable DD Boost and multiple streams, and run backups per file server in parallel with concurrency limits so 14 servers do not saturate the source or the appliance. For the first full, seed in waves by server group, throttle during business hours, and use a temporary seeding device if the WAN or backup link cannot carry the initial copy in the window. Keep the 60 daily and 12 monthly points on DD; move older monthlies to cloud or tape only if restore requirements allow. Controls: (1) synthetic full creation and chain validation; (2) per-server backup streams with QoS on the backup network; (3) monitored snapshot or VSS release so no snapshot survives the job; (4) restore testing of a 400 GB volume and random single files. To validate the 8-hour RTO, restore the 400 GB volume to alternate storage and measure elapsed time from request to mounted, validated data, not just restore throughput. If 400 GB restores at 300 MB/s, data transfer is about 22 minutes, leaving ample time for mount and validation; if the chain requires rehydration, measure that too.
3. The application owner asks for a 2-hour RTO for the 400 GB volume. What evidence would you require before agreeing?
Read the worked answer
I would require a documented, repeated restore test that starts with a failure declaration and ends with the application owner validating data, not a lab copy of a single file. Evidence should include: restore throughput from DD to the target host, including any rehydration; the number and size of incremental extents in the chain; time to mount and present the volume; file-system consistency check time; and application validation time. I would also require a test with the backup network and production network under normal load, because a 1 GbE shared uplink may make a 400 GB restore take over an hour before mount. The math matters: 400 GB at 500 MB/s is about 13 minutes, but at 100 MB/s it is about 68 minutes, leaving little margin for validation. If the test cannot consistently finish inside 2 hours with at least 30% headroom, I would not agree; I would add a local recovery copy, dedicated restore network, or a standby volume. The RTO commitment must be based on measured recovery, not backup throughput.