New data protection

Upgrading TSM server from Q9650 Core 2 Quad 3.0GHz, 8GB DDR2 on Win 2008R2.

New system is HP Z600, two-socket, 6-core 2.66GHz Xeon X5650 and 48GB of RAM. Wattage is the same per socket, but two sockets now. 3x the cores, 4x the performance.

SSDs for DB and Log are also moving to EVO 850 from Corsair M100. I’ll set up a container pool to replace the dedupe file class, and put that on 3x 3TB RAID5 instead of 2x RAID1.

OS will be Ubuntu 16.04.2 LTS. I’d like to just use Debian 9.1, but Debian and long-term-support seem to not be synonymous. I’d hate to run a patch update and have everything break, then fight with debian testing repo to try to get it all back to normal. Plus, I have no Ubuntu boxes, only Debian. It’ll give me a chance to see what operational differences I run into.

Old TSM is 6.4. New will be “Spectrum Protect” 8.1.3. Yes, the billions spent to rebrand to the same name as Charter Cable’s rebrand really seems like money well spent.

Anyway, Since I lost the offsite replication provider for the dedupe file pool, and it was having trouble keeping up anyway, this will let me change to server-side encryption, and object storage. We’ll see which provider wins out on price once everything is rededuped properly.

If the fan noise is not too bad, maybe this platform can be considered for a low-cost upgrade to the kids’ game machines. Though, these are heavy, with 2 big handles on the top.

Also, really, something new enough to have USB3 on the motherboard is probably better. I have some laptops picked out, but that’s re-buying every component, including ones that are presently decent. *sigh*


After DR of a TSM server, do you need to restore the primary storage pool from the copy cool ?

It depends on if it’s small files or not. I normally have a small-file pool, which is the DIRMC, VMTLMC, and TOCDESTINATION. The offsite for this is kept reclaimed down to 1 tape, and I try to restore that primary pool first.

For large file, TDP, VM and image full backups, they can restore directly from tape, no problem.

For small files, block level incrementals, or instant restore, it depends on the number of tapes, number of drives and number of concurrent restores.

One restore with 6+ tape drives and it’s not much of an issue.

Ten restores with 6 tape drives could be an issue.

This is where properly setting your RTO/RPO and tiers in advance matters.

Tier-0 would be your TSM server, the DIRCOPY/DIRPOOL, ESX hosts, switches, arrays, etc. You’d restore or rebuild these directly before anything else.

Tier-1 would be the things you can restore within the first couple of days. It would be in one collocation group or one storage pool. You could restore those first, direct from tape. It should only be a small number of systems, such as a NIM server, HR/Payroll, and inventory/medical tracking. Primary systems only.

Tier-2 systems would be what can be restored within a week or two. This might be direct from tape, or restore to disk first. It would be any other important systems that your company can run without, but which is a serious pain to go a long time. Generally, this would be under 50 systems. You wouldn’t usually restore all of these at a normal DR test, but maybe a different subset at each DR test, just to make sure you *can* restore them.

Tier 3 might be the systems that you don’t restore for a few months. Some might be rebuilt from production clones, and some might just restore a source tree for critical system development. Dev, QA, HA, and anything else that you can operate without, but which should eventually be taken care of. You probably won’t ever restore this at a DR site, rather you’d wait until you fail back to new-production. If they were unrecoverable, they could be rebuilt, or decommissioned, without business risk.