I recently setup a backup process to dump a MySQL database to a file for backup. With this database, our DBA group has been using the ‘root’ account setup the by software vendor for administration. This server is used for internal system administration and sending performance data off to our software vendor. So, other than being bad form to use the ‘root’ ID, there’s probably no regulatory responsibility to use user or role specific IDs.
I ran into an interesting problem recently. A de-duplicated pool containing TDP for Oracle backups was consuming much more space than would otherwise be indicated. Here’s what the occupancy looked like:
Node Name Storage Number of Logical Pool Name Files Space Occupied (MB) ---------- ---------- ----------- ----------- CERN_ORA_ADMIN CERNERDISK 810 31,600.95 CERN_ORA_BUILD CERNERDISK 1,189 74,594.84 CERN_ORA_CERT CERNERDISK 402 3,876,363.50 CERN_ORA_TEST CERNERDISK 905 7,658,362.00 LAW_ORA_PROD CERNERDISK 1,424 544,896.19 OEM_ORA_RAM CERNERDISK 2,186 524,795.31
That works out to about 12.7 TB. And, here’s what the storage usage looked like:
The client OS level field in TSM for most operating systems is pretty straightforward. On Linux, it’s the kernel version, HP-UX and AIX show a recognizable OS level. For windows the OS level is more cryptic. Here is a list of the OS levels:
|Client OS Level
|Windows NT 4.0
|Windows Server 2003
|Windows Server 2008
UPDATE: I got some feedback that some people are not clear on creating multiple schedulers, so I’m updating this post.
Since I wrote about doing TSM Full-VM Image Backups With VStore API I’ve done more testing, and have put it into “production” with our smaller VMWare cluster. This cluster is managed by one department inside IT. It has some VMs used by customers inside the enterprise, some VMs used for development or testing, and some VMs used by the group inside IS. Now that I’m ready to put VMWare backups into practice, I need to schedule the backups. And, I got some great feedback on the first post, so I thought I would follow it up.
As a request from one of our VMWare admins, I’ve started testing the VMWare image backups. In the past, we’ve installed the regular backup/archive client on each VMWare guest OS. This has let us standardize our install regardless of if it’s a virtual or physical server. This doesn’t allow you to take a full snapshot of a VM, instead you have to rely on your baremetal recover procedures just as if it was a physical server.
Unfortunately, an application admin messed up a server, almost beyond repair. If the VMWare admins had been made aware of the work, they could have generated a snapshot just before the work started, and recovering would have been quick and simple.
DRAFT – I’m still working on it
In TSM 5.4+, there is an option for backup encryption. Unlike SSL encryption, the data is stored on the server in an encrypted format. So, your tapes are finally, really, secure. Without paying for encryption capable libraries and drives. I always thought it was kind of lame of IBM to say that the TSM backup takes are useless without the TSM database. It looks to me like the data is in the clear on the tape, there’s no reason you couldn’t read the whole tape into a huge file and text search it if you really wanted it bad enough.
I haven’t looked at TSM backup encryption before, even though it’s been in TSM since version 5.4 (maybe earlier). But, if you think about it, there isn’t any data MORE important than your backup data. Data that is usually encrypted on the wire, is most likely sent in the clear by the TSM client. There are a couple of ways to slice this, but I started with the SSL encryption feature. There is a client encryption option in TSM 6.1 (possibly earlier) that encrypts the data with an encryption passphrase, but that has more issues and isn’t very compatible with server-side de-duplication.
If your wondering who is restoring files, and what they’re restoring, you can capture that information to a custom log file. It’s a pain to get the same kind of data out of the activity log, but you can dump it to a “formatted” text file. You can send it to a user defined script or program too. The offending codes we’re looking at are ANR0503 and ANR0504.
First, we need some options added to our dsmserv.opt file:
These are various server SHow commands I’ve picked up from various sources. This is definitely not an exhaustive list, and these commands are added and dropped from TSM based on the version, these commands are not supported and may not work for you.
If you have a client session or process stuck, it may be waiting for a drive. You can use this command to see if there are sessions queued waiting for mount points.
If you are having problems with sessions or processes queued, or waiting for tape volumes, then this command will display the in-memory list of assigned volumes.