Privileges Necessary for MySQLDump

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.

TSM Deduplication Increases Storage Usage (for some values of deduplication)

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:

TSM Windows Client OS Level Demystified

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:

Operating System Client OS Level
Windows 95 4.00
Windows 98 4.10
Windows ME 4.90
Windows NT 4.0 4.00
Windows 2000 5.00
Windows XP 5.01
Windows Server 2003 5.02
Windows Vista 6.00
Windows Server 2008 6.00

Scheduling TSM VMware Backups

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.

TSM Full-VM Image Backup With VStore API

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.