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:
|Operating System||Client OS Level|
|Windows NT 4.0||4.00|
|Windows Server 2003||5.02|
|Windows Server 2008||6.00|
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.