What circumstances are you planning to deal with here? What I mean is ...expectation management? From your description it sounds like this is business continuity restricted to database corruption only: you state the hardware will be the same: you mean identically the same I take it.
2tb of DB : thats not a lot of data really and if your DBs are like mine (Oracle) eg a small number of large files then the LTO can hit peak speed so long as you can feed it/them. Thats 140M/s RAW, twice that typically for average compression.
2tb = 2000000 Mbytes so 2000000M/140M/s= 233minutes so lets say 4hrs, possibly as little as 2hrs with compression and hig bandwidth.
So if you can feed just one drive at that speed, then very achievable by the drive, rather depends on if the server/storage can meet the same demand, but tape not likely to be the bottleneck and as is its own media server then effectively the tape is directly attached to the data. Tune your blocks to tape and it'll fly.
You can test this with a synthetic test as NB can rapidly generate data for a backup ie exercise the backup without going near your intended dta and thus showing whats possible via the cpu/tape.
Restore is a different proposal as you want to avoid contention. And you can deal with that to a degree with 2 drives. I suspect with 2 drives and careful segregation of policies to use different pools ie different media (balanced data volumes per pool) then your backups will be well within the window and your restores wont be affected by mpx at all.
If you struggle to achieve then you'll have to go MPX route or analyse the data layout eg are all dbs across the same spindles? If not then you will be able to select data from different spindle sets to be backed up at the same time so spreading reads across the maximum number of spindles.
Get back to the forum with your progress please.
Jim
