If you are up to date with your VMware versions and you are using the latest in backup software (Netbackup 7, TSM6 veeam, vRanger etc) you will enjoying the pleasure of vmdk image backups without client software in each VM.

There are some good reasons for wanting to do VMware image backups:

Found a nice blog that explains the difference between VCB and vStorage API's. Useful if you are looking into ways of backing your VM environment. Netbackup 7 supports both methods.

http://www.vnotion.com/?p=181

( 2 Votes )

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

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.

( 1 Vote )
March 2010 was the last month before a number of changes to the penalty and enforcement rules are expected to the Data protection act, (including custodial sentences and far heftier fines), and it was local government and Finance/Insurance houses that came out badly. With 3  reported breaches  to each industry it was an unwanted draw, although hospital trusts will be happy to have  avoided recognition this month. What is most interesting however is the range of risks exposed. We had the usual lost Laptops and memory sticks but we also had wider process failings and a return of the age old "lost tape"

Concerning the process failing I have long advocated businesses reviewing how information is processed and managed through an organisation and generating a process map/ information flow policy.

( 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.

( 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?

It seems that IBM hasn't slowed down the development of Tivoli Storage Manager (TSM) since migrating the internal database to a DB2 database, as TSM v6.2 has just been announced this week. Availability will be electronic from March 19th, with physical media a month later. (Not that many people rely on physical media for software distribution these days.)

There's some interesting new features as well with this release. The most notable feature is block-level deduplication at the client level, so if you've got a client with a lot of similar files then this feature can provide significant benefit. both in terms of storage and network utilisation. Note that this dedupes at the client level, not the server, so if two clients have the same files this feature will not dedupe between those clients. {Edit: I'm told it's actually cross-client, however I'll wait until the official documentation is available before making further comment.) If you want cross-client dedupe then this can be achieved via other means, such as file based disk storage pools or deduped based storage at the back-end.

For many years, the NetBackup™ product suite has frowned upon technologies that didn’t use full backups as they claimed it impacted the RTO. In a change of face, Symantec now offer both source and target de-duplication in both NetBackup™ and BackupExec™.

This is achieved through the PureDisk™ when storing data in a media server de-dupe pool or a PureDisk storage pool.

For more information see:  http://eval.symantec.com/mktginfo/enterprise/fact_sheets/b-symc_netbackup_7_core_DS_12995286-2.en-us.pdf

EMC also have source and target de-duplication through its acquisition of Avamar and DataDomain.

I have to admit that I was struggling with the wording of this blog. The reason for this is that I am trying to gauge what  the most common reaction or implementation to reducing restore and recovery times is. I have some strong views on this subject so here is the deal, before clicking read more please note down the one action you feel is most likely to help or  that your organisation has implemented. Then  please post this as a comment back to me.