SDO,
3) You previously stated that dedupe within the Sepaton/HPP is post process based. This leads to me to several other questions:
3a) I would expect that OST replication cannot begin until the post process deduplication has completed. Is this true for Sepaton/HPP?
I can't recall since this has been a few months now that we decided to not use replication to our hotsite domain; but if I remember correctly, a full backup occurrs at the local site, compression occurs immediately even if a second backup set has not been create for dedupe; but if you are referring to a situation like "opt-dupe" (never used, just heard about), the data lands and sent off immediately before a full backup image is comopletely created and is reconstituted at the remote site, then the answer is no, the first set would need to complete before data is ship to the remote site via AIR. However, we are not in need of an opt-dupe approach and can live with data replication occuring over several days. I'll have to get a refresher from our Support Engineers about this again.
3b) Does the Sepaton/HPP prioritise receipt of backup data over and above the deduplication processing, i.e. does it only perform deduplication as the devices get quieter?
In memory, I think the most recent backup is not deduped until the next backup set occurs, as it lands on backend disks, and line speed backup rates are able to be maintained without a drastic performance impact on the enclosures.
3c) Are threshholds configurable, i.e. do you as a backup/system admin have control over settings to tune/adjust when deduplication begins, and how much processing capability to apportion to deduplication?
We haven't needed to perform much tuning of Sepaton, but the support group has made some modification to increase performance, and it seems to be running more lean. Really, if you need to cruch i/o, gain some speeds for data processing, just indicate how much data you plan to backup to the appliance(s) and they can configure how many master and slave nodes to install at your site(s). Also let them know how what your data growth change rate is at and forecasted.
3d) Is the Sepaton/HPP like Exagrid, in that... does the device retain a non-deduplicated copy of the most recent backups in the landing zone (prior to deduplication) so that restores from the most recent backup never have to be rehydrated? Or are all ingested/received backups always deduplicated and always removed from the landing zone?
In my understanding, the most recent backup set is not de-dedupe, but dedupe begins as soon as the new backup image is being created.
It does have this capability where you can designate a non-dedupe storage pool as a temporary landing site. In our experience with any type of backup storage appliance, we don't like to have all our eggs in one basket, and if the appliance requires downtime for maintenance, we can't get to our data, especially hire tier data of importance such as DB logs, and non-dedupe images. Instead we setup a separate enclosure for DSU's (Advanced Disk) -large enough hold up to 28 hours for instance recovery purposes. This non-dedup data is then spun off to tape.
3e) How many 'threads' of deduplication can each Sepaton/HPP server/storage box perform concurrently?
By default, and if you are using OST, each VTL/OST FC (4 gig with our g7 series appliance) port handles six streams per port, and four ports per appliance server/storage node. However, I think there is a limit of 256 streams per port -you'll have to ask HDS sales about this; we are using the default. It is also import to know the limitations of your master/media servers in regards to HBA FC port speeds.
In our situation, we have two appliance nodes (master and slave), each with 4 OST/VTL ports, we use 48 streams for OST over FC backups.
