ADSM-L

?'s about Backup of Cyrus email, LTO3 vs 3592 tapes, and using Copy tapes

2007-01-03 06:29:48
Subject: ?'s about Backup of Cyrus email, LTO3 vs 3592 tapes, and using Copy tapes
From: James R Owen <Jim.Owen AT YALE DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 3 Jan 2007 06:22:01 -0500
Happy New Year to All!

@Yale, we will do several conversions soon/later during 2007:
        email:  from U.Washington IMAP servers to Cyrus IMAP servers.
        tapes:  from 3494 w/ 3590 drives to 3584 w/ LTO2-3 and/or 3592's.
        TSM:    from server 5.2.3 to 5.3.4, and then to 5.4?
        Copies: ?using Copy tapes for all/some/no client Backups?

1. We seek experience/advice from sites using TSM to backup Cyrus servers:

Email currently accounts for 1/3 -> 1/2 of the 5 TB of backups received
nightly across all of our TSM servers.  We anticipate that the IMAP->Cyrus
conversion will significantly reduce TB's backed up, but significantly
increase the number of files backed up and, thus, our TSM database sizes.

Has "Cyrus -> increased TSM database size" been a problem at your site?
Did you adjust any TSM client/server settings specifically for Cyrus backups?

2. LTO3 vs 3592 Tape Performance:  (and TCO?)

We also expect to replace aging 3590 tapes and drives with LTO3 and/or 3592
technology.  If you have experience to recommend one/another technology, we
are interested.  We expect either LTO3 or 3592 technology will be satisfactory
for large files, but wonder about performance for restoring someone's Cyrus
email directories:
        perhaps several thousands of discrete, small email files
        scattered variously across several/many large tapes?

Do 3592 tapes perform significantly better than LTO3 for many small files?

3. Use Copy Tapes?:  (or NOT?)

Several years ago, Yale's IT management decided that we could and would
afford the loss of backup data if a tape becomes unreadable because the
risk of "unable to restore" is perceived to be very small and manageable:

The probability of a client needing to restore data (failed disk/user error)
is itself very small.  The simultaneous probability that a tape is unable to
restore that data is much smaller.  If a tape becomes unreadable, whatever
backups are lost are either inactive or will be recreated with the next
client backup after the damaged tape is discovered and deleted.

We backup to Copy tapes all Archives (might be deleted from client)
and any Backups that remain >24h on unmirrored disk (BackupPool) space.
Otherwise, we do NOT use Copy tapes for most of our TSM services.
In actual practice, this "(Almost) No Copy Tapes" policy has NOT hurt us
for several years now, but management is now reconsidering whether/not
to apply this policy for backups from some/all of our "more important"
clients, and is also considering the greater potential data loss with
much larger capacity tapes.

We welcome your experience and considered advice regarding Copy tapes.

4. Attached file:  (and replies?)

Attached is a txt file detailing topics we think might be of interest.
We've included Yale's information and some questions.  Please send back
to the list if your reply is of general interest.  Otherwise, reply
directly to me if you are interested to discuss any of this with us.
We may want to schedule some time to talk on the phone.
If you prefer that, please include phone#(s) and preferred time(s).

Thank you for your time and consideration.
--
jim.owen AT yale DOT edu  (203.432.6693)
[jim (dot) owen (at) yale (dot) edu]


Questions for TSM Contacts Backing Up Cyrus IMAP Servers:
--------------------------------------------------------
>>> For each physical TSM service host machine:
(1) hardware
(2) operating system
(3) # of CPU processors

@Yale: Three IBM P650 (7028-6M2) servers, AIX, ea. w/ 4 CPU proc's.

>>> For each logical TSM service:
(1) number of clients
(2) amount backed up nightly
(3) database size

@Yale:  (ws = workstation/personal computer client)
TSMs1a: 3050 ws + 250 server clients, ~1TB/n, 270GB TSMdb
TSMs1b:   11 server + 4 UWemail clients, ~1TB/n, 80GB TSMdb
TSMs2a:  635 ws clients, ~100GB/n, 60GB TSMdb
TSMs2b:  330 server + 4 UWemail clients, ~2TB/n, 80GB TSMdb
TSMs3:  1420 ws + 75 server + 2 UWemail clients, ~1TB/n, 180GB TSMdb

>>> Disk backup STGpools:
(1) make/model of disk hardware
(2) RAID type
(3) usable GB
(4) Do you use a VTL or TSM Sequential Files?

@Yale:
TSMs1,2* backup STGpools are on SAN attached Shark 800 arrays.
About 7TB total RAID5  (146gb, 10K) storage pool space on Sharks.
TSMs3 backup STGpool resides on mirrored SSA disk.
We are interested in, but not using VTL or TSM Sequential Files.

>>> Tape storage:
(1) make/model of library, drives, tapes
(2) TB of primary tape storage
(3) TB of copy tape storage
(4) What subset of clients have copy tapes?
(5) How do you collocate?

@Yale:
Two IBM 3494 libr's, each w/ 6 * 3590E drives (will phase out)
Two IBM 3494 libr's w/ 4 and 6 * 3590H drives (will phase out)
Two IBM 3584 libr's, ea. w/ 4 * LTO1 + 8 * LTO2 drv's (to expand)
Total 160TB of primary tape storage
Total 42TB of copy tape storage (mostly @ TSMs3 service)
WS client backups collocated by node
Server and UWemail client backups mostly collocated by filespace

>>> Network environment:
(1) Do you backup over public network, private network, LAN free?
(2) Do you use gigabit Ethernet with jumbo frames?

@Yale:
Backing up over public and private networks.  No LAN free backups.
Each TSM server machine uses multiple gigabit Ethernet interfaces,
but not using jumbo frames.

>>> Cyrus:
(1) How many Cyrus IMAP servers do you backup?
(2) How many users per Cyrus server?
(3) Do your users have quota limits for their email?   @Yale: No!
(4) Do you dedicate TSM services for Cyrus backups?
(5) Any special TSM service or client settings for Cyrus backups?
(6) How to collocate/aggregate backups to optimize Cyrus restores?
(7) Any problems associated with backing up Cyrus email servers?
(8) Do you prefer something other than TSM for Cyrus backups?
<Prev in Thread] Current Thread [Next in Thread>
  • ?'s about Backup of Cyrus email, LTO3 vs 3592 tapes, and using Copy tapes, James R Owen <=