Recently I have seen some strange behaviour with the later levels of firmware (around version 7.10 upwards) whereby a failed drive that has reconstructed to the hot spare does not automatically copyback when a new drive is inserted. The disk appears in storage manager as Optimal and Unassigned and logs indicate it has been picked up without error.

In later versions of IBM Storage Manager (versions 10.10 and up). There is a new function included "Replace Drives" that allows the user to select whether to replace a failed drive with any unassigned drive in the subsystem or the hot spare drive. It should be possible use this function to initiate the copyback. In some cases, I have seen that when the option "Replace Drives" is selected, the message is displayed "no drives available for replacement", despite the fact that unassigned drives are clearly available. In my investigations I have checked that the new drive was inserted correctly (leaving 30 seconds between the pull of the old and insertion of the new). I have seen that the new disk is of exactly the same type and brand and running the same level of firmware and that there do not appear to be any obvious problems within the event log,

The resolution so far has been simply to wait (even up to 2 days), and eventually, the "Replace Drives" option will recognise the available drive(s). So far, the only indication of what has occurred between these times has been that the regular media scan (scrub) has kicked off. Note that if a Storage Subsystem password is set, this is required to authorise the copyback.


The "Replace Drives" function does not appear to be clearly documented in the new Storage Manager client Redbooks so I will blog regards what I know of this function later.

( 2 Votes )

With today's news, IBM is expanding its portfolio and furthering its investments in information and analytics with:

The DS3000 subsystems become less of a range with the announcement of the DS3500, as it's a bit of a jack of all trades which outdoes all its smaller siblings. Available June 15th there are two versions, the DS3512 and DS3524 supporting either 3.5" and 2.5" disks, with 12 or 24 disks accordingly. There are also EXP3512 and EXP3524 expansion enclosures to match. Both units are 2U high, and this basically brings the DS range into line with the HP MSA2000 range in terms of spindle capacity and density, to the point that the only real difference is the GUI used to manage it.

Of most note with the DS3500 are the changeable host interfaces similar to the DS5020/DS3950, which means that the DS3500 can have a mix of four 6Gbps SAS and an optional four more SAS connections, eight 8Gbps FC or eight 1Gbit iSCSI ports. If you have the FC ports, unlike the smaller DS3000 units the DS3500 *will* support remote mirroring between the DS3500 and any other DS3500/DS4000 or DS5000 subsystem.

LTO-5 has now been announced for the IBM tape range... well, the TS3100, TS3200, and TS3500 anyway. If you want LTO-5 for the TS3310 unfortunately you'll have to wait a little bit longer.

A quick technical summary, LTO-5 has a native data transfer of up to 140 MB/sec. and a 1.5 TB Data Cartridge uncompressed, or up to 3TB with the drive's 2:1 compression. It also continues to follow the LTO standard of writing back one generation and reading back two, ensuring that your LTO-3 and LTO-4 tapes still have some life in them. Finally  the drive also has a 8-Gbps Fibre Channel dual-ported interface on the back end, so you can finally have a more resilient connection through to the drive itself when connected to a SAN.

Be aware that unlike like DS4000 range, the cache batteries within the DS3000 Storage Subsystems (including DS3200, DS3300 and DS3400) are not covered under IBM warranty. This means that when they fail a replacement part must be purchased even if the unit is under standard or uplifted warranty.

IBM state in Retain Tip H194543 that "the battery is designed to have a life expectancy of two (2) years and to maintain the data in cache for up to three (3) days in the event of a power outage".

The replacement part can be requested from your IBM Sales Representative or an IBM Business Partner. The part required is:

DS3000 System Memory Cache Battery, Option 39R6519

Retain Tip H194543 also recommends that users upgrade the subsystem controller firmware to 07.35.41.00 or later to benefit from the Smart Battery Learn Cycle technology which monitors battery life and will override the "Battery Nearing Expiration" warning if it determines that the battery is still in good order.

Note that in order to calculate battery life, the "Smart Battery Learn Cycle" performs a discharge and charge every 13 weeks during which time write cache will be suspended and this could impact on the performance of the system. This Smart battery feature can be disabled if preferred.

*A small set of batteries may not support this Smart battery technology - see the Retain Tip for more information*

http://www-947.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-5079213&brandind=5000008

( 2 Votes )

Having checked out an implementation of TSM for Sharepoint, I was surprised to see that backup data was being retained for longer periods than set in the backup plan. I checked the usual places (Server copygroups, expiration processing, etc) but everything seemed in order. I then turned to google and user groups and after many searches I finally stumbled across an answer to the problem. 

This can be caused by two different TSM server settings for the DocAve node.
1.  The node does not have Del Backup set to Yes
2.  The node's txngroupmax is too low Diagnostics:
1. Check the following:
 Query Node F=D for the node in question and ensure the following is set :
      Backup Delete Allowed: Yes

2. Check the actlog for the following
ANR0445W Protocol error on session 1115630 for node nodename (DocAve) - maximum group transaction size exceeded. (SESSION: 1115630) In the case where the node's Backup Delete Allowed is set to No, update the node so that it is set to Yes. In the case where you are getting the delete errors due to maximum group transaction size exceeded, then you need to update the node's txngroupmax.

During a DocAve backup, the data is segmented into 50mb chunks. This is stored individually on TSM as an object. Because DocAve uses the TSM API, the deletion of the old data is done as a single transaction. If the number of objects it is trying to delete is greater than txngroupmax, then the deletion will fail.

( 2 Votes )
The Garage and Loft is full of boxes of stuff you don't use or need. So whats the first thing you do?  That's right call the real estate agent and move house. Or maybe not. If you did this your friends and neighbours would think you had gone mad, you would be permanently wasting money on removals men, legal fees, taxes etc. and not spending it on stuff that makes your life easier, more enjoyable, or both. So why do businesses accept it in IT systems?

( 3 Votes )

Storage at it's most fundamental level is a bucket, where you store useful stuff that you may or may not want again later. Of course what you put that stuff into can vary in design; it might not be a bucket but a box instead, or a sieve, or a safe, or the dog's basket because he never sleeps in the damned thing anyway. Likewise with disk based storage there are various methods to implement a storage subsystem design, all slightly different, all have their own way of doing things.

( 1 Vote )
A  web posting for a cloud/remote backup provider asked the question “is a 30 day retention policy sufficient?” and suggested that a much longer  retention policy was the way to go to ensure availability of data, whether it be 60 or 90 days or even longer. I challenge this question and believe that for many 30 days retention is excessive.

Why?

Informatica's announcement in the India online Press  (CIOL)  of the industry first Cloud based archiving solution has got me thinking.