Sizing a New Spectrum Protect Server for Deduplicated Disk and Offsite Protection

Start with the logical footprint, not the SAN size. Initial 80 TB plus 30 days at 8 TB per day is 80 + 240 = 320 TB logical. At 3:1 dedup that is about 107 TB physical before metadata, container overhead, and migration workspace, so a 100 TB pool cannot hold all 30 daily restore points. I would not simply shrink the dedup assumption. I would either request about 160 TB for a 30-day disk cache or design a tiered hierarchy: a 100 TB directory-container pool for roughly the first 14 days (80 + 14 x 8 = 192 TB logical, about 64 TB physical, leaving headroom), migration of older backup versions to a primary tape pool, and the 12 monthly points on tape or through an archive copy group. The next pool should be a tape pool in the library; the copy pool is a separate tape pool at the DR site built with BACKUP STGPOOL, not the same pool. Tier-1 restore in 4 hours is the constraint that decides placement: tier-1 data must stay on disk or be replicated, because recalling from tape with four drives will not consistently meet 4 hours. Therefore the 100 TB SAN is defensible only as a 14-day disk cache, not as the full 30-day repository.

Placing DB, active log, archive log, and container pool on one LUN concentrates random DB I/O, sequential log writes, and large streaming container I/O on the same spindles and queue. The active log is the most dangerous: a long transaction or log-full condition can stall the server, and if the LUN is also serving restores or migration, recovery time grows. I would approve separate volumes: DB on fast mirrored storage sized with growth headroom, active log on low-latency dedicated storage sized for the largest transaction and peak concurrency, archive log on separate capacity storage, and the directory-container pool on its own SAN volume or set of volumes. Also keep the DB backup target off the same LUN and monitor QUERY DB and QUERY LOG. The 100 TB pool should not be shared with DB or log storage. If the SAN team can only present one LUN, I would request additional LUNs before installation, because moving the DB or logs later is a rebuild or outage project.

Tape copy from a deduplicated container pool is not a copy of 100 TB physical; migration and BACKUP STGPOOL write logical data. The 320 TB logical footprint would need roughly 18 LTO-9 cartridges per full copy before overhead, and four drives cannot write that within a 6-hour window. Node replication is better for the 4-hour tier-1 RTO, but the initial 80 TB seed at 2 Gbps is about 89 hours, so seed by tape or portable media, then replicate nightly. Nightly changed data is 8 TB logical, about 2.7 TB after 3:1 dedup, which at 2 Gbps is roughly 3 hours, inside the window if the WAN is dedicated. I would replicate tier-1 nodes first and use tape copy for monthly and long-term retention, not as the only offsite method. Verify target server capacity and replication lag before committing.