Hi:

We have a 2 steps project. The current situation is no in house backup
for 6 servers (windows: a fileserver cluster, and Exchange Cluster a
Sharepoint and an SQL one). The customer is buying a new MSL6060
library and plans to connect it directly by FC to a backup server as
stage 1, and at stage 2 integrate everything in a SAN.

The question is: how to decide how many LTO3 drives will be
enough/better to backup 1TB? Remember that at first data will be pulled
from a Gb Ethernet LAN. The MSL6060 will be connected via FC by 2 HBAs
to the backup server. The type of files is mostly small (a bunch of)
desktop files (Office, .doc, Excel, etc).

In the case of buying 4 LTO3 drives, will they all used at 100% in a
2Gbps SAN environment? We think that at stage 1 a possible use is to
backup in 2 and replicate in the other 2.

Will multistreaming be of any help here? (sending several backup jobs
from one host to drive).

The main concern the customer has is SPEED...but I don=B4t want to go
overkill nor make him spend money without sense.

Ideas, anyone?

thanks a lot,

JP

[ Post a follow-up to this message ]

"JP" <seasidefan@yahoo.es> skrev i meddelandet
news:1120651386.524327.12780@f14g2000cwb.googlegroups.com...
Hi:

We have a 2 steps project. The current situation is no in house backup
for 6 servers (windows: a fileserver cluster, and Exchange Cluster a
Sharepoint and an SQL one). The customer is buying a new MSL6060
library and plans to connect it directly by FC to a backup server as
stage 1, and at stage 2 integrate everything in a SAN.

The question is: how to decide how many LTO3 drives will be
enough/better to backup 1TB? Remember that at first data will be pulled
from a Gb Ethernet LAN. The MSL6060 will be connected via FC by 2 HBAs
to the backup server. The type of files is mostly small (a bunch of)
desktop files (Office, .doc, Excel, etc).

In the case of buying 4 LTO3 drives, will they all used at 100% in a
2Gbps SAN environment? We think that at stage 1 a possible use is to
backup in 2 and replicate in the other 2.

Will multistreaming be of any help here? (sending several backup jobs
from one host to drive).

The main concern the customer has is SPEED...but I donīt want to go
overkill nor make him spend money without sense.



With 4x LTO3 drives, they will almost certainly not be utilized 100%, not
even close. LTO3 has a native speed of 80MB/s. One of my rules of thumb is
to be able to feed a drive 3x the native speed to be sure it will stream
with compression. That would mean the backupserver would have deliver
4x3x80=960MB/s to stream all drives concurrently. Not very likely in a
single Windows host. Even with the above, using 2 for backup and later
copying to the other two it's still 480MB/s, far beyond what Windows will
deliver.
Switch off compression, well maybe. Using Iometer (search intel.com for this
tool) I've managed to get slightly more than 100MB/s read from a Windows
host. That was using very large I/Os doing 100% sequential reads.

You say your customer is concerned with speed. Speed of what? Backup speed?
Well ok, just pipe it to /dev/nul 

Restore speed? Now it gets a bit more interesting. Although you could gain
backup speed with multiplexing, you're facing a problem during restore. Lets
say you multiplex 8 times. That is, 8 backup streams are interleaving on the
tape from as many as 8 servers.
Call the servers A, B, C, D, E, F, G and H. On the tape it'll look like
this, essentially:
 A|B|C|D|E|F|G|H|A|B|C|D|E|F|G|H|A|B|C|D|
E|F|G|H|A|B|C|D|E|F|G|H|

Now comes the restore of server D. Wind the tape to first D, read a little
data, wind until next D, read a little more data, wind until next D, read...
you get the idea. You risk slowing down restores since the tape is a
sequential medium.

Backup speed again. You say you have mainly small office type files. This
will positively _kill_ backup performance. NTFS will not deliver the speed
to satisfy even a single LTO3, even with compression turned off. From a
regular file server, I get maybe 25MB/s on average. Use mulitplexing? Well
ok, but see above.

My best advice to you is to invest in 2TB of cheap (but not too cheap) bulk
storage. Do backups to disk first, and duplicate to tape later. The exact
process varies with whatever software you use, but most will place large
files representing the "virtual" tapes from disk backup on the bulk storage.
These contents of these files are then copied to tape. Since disk is random
access in nature, restores from disk are much faster generally. You can
multiplex as much as you want to utilize the network properly. When
duplicating to tape, you can "de-multpliex" to make each backup set
sequential.

If you can fit it in your budget, get 4x LTO3. Then you can do
backup/duplication to one drive, copy tape to tape and still have one drive
available for restore. However, if money is a bit tighter, I'd settle for
two or maybe even one LTO3 drive and get some disk storage instead.

[ Post a follow-up to this message ]

What is the client attempting to accomplish? Four LTO3s is a lot of
bandwidth for six servers. The biggest problem with modern tape drives
is that they can be somewhat unreliable when they are run at less than
full speed. The ability to properly utilize the tape drives depends as
much on the servers being backed up as the interconnect used.

We have done some installs using a disk based virtual tape library
(VTL) to handle the initial backup streams and then  replicated to a
tape library. This allows inital backup to be completed as fast as the
servers can provide the data and then the tape drives can be driven as
fast as they can handle.

[ Post a follow-up to this message ]

> With 4x LTO3 drives, they will almost certainly not be utilized 100%, not
> even close. LTO3 has a native speed of 80MB/s. One of my rules of thumb is
> to be able to feed a drive 3x the native speed to be sure it will stream
> with compression. That would mean the backupserver would have deliver
> 4x3x80=3D960MB/s to stream all drives concurrently. Not very likely in a
> single Windows host. Even with the above, using 2 for backup and later
> copying to the other two it's still 480MB/s, far beyond what Windows will
> deliver.
> Switch off compression, well maybe. Using Iometer (search intel.com for t=
his
> tool) I've managed to get slightly more than 100MB/s read from a Windows
> host. That was using very large I/Os doing 100% sequential reads.

It appears very clear to me. You can=B4t put more data into the tape
than you can squeeze from the host.
>
> Restore speed? Now it gets a bit more interesting. Although you could gain
> backup speed with multiplexing, you're facing a problem during restore. L=
ets
> say you multiplex 8 times. That is, 8 backup streams are interleaving on =
the
> tape from as many as 8 servers.
> Call the servers A, B, C, D, E, F, G and H. On the tape it'll look like
> this, essentially:
>  A|B|C|D|E|F|G|H|A|B|C|D|E|F|G|H|A|B|C|D|
E|F|G|H|A|B|C|D|E|F|G|H|
>
> Now comes the restore of server D. Wind the tape to first D, read a little
> data, wind until next D, read a little more data, wind until next D, read=
.=2E.
> you get the idea. You risk slowing down restores since the tape is a
> sequential medium.
I get it again. The main pain they fear about is with Exchange (2000)
protection. If this is the most important job for them, is there any
technique to "multiplex" Exchange=B4s database to several drives even if
they are located in a single host? I=B4m asking this but feel that=B4s a
stupid question if we accept that the limit is imposed by the host...

Another newbie one: are there any real advantages in puting more than 1
Ethernet NICs in the backup host? I=B4ve heard that but have no real
data.

> Backup speed again. You say you have mainly small office type files. This
> will positively _kill_ backup performance. NTFS will not deliver the speed
> to satisfy even a single LTO3, even with compression turned off. From a
> regular file server, I get maybe 25MB/s on average. Use mulitplexing? Well
> ok, but see above.

That is definetly something I=B4ve read studying this case in lots of
places. I agree with you that they will be better spending money on
disk based destaging hardware than filling the MSL with LTO3 beasts.
>
> My best advice to you is to invest in 2TB of cheap (but not too cheap) bu=
lk
> storage. Do backups to disk first, and duplicate to tape later. The exact
> process varies with whatever software you use, but most will place large
> files representing the "virtual" tapes from disk backup on the bulk stora=
ge.
> These contents of these files are then copied to tape. Since disk is rand=
om
> access in nature, restores from disk are much faster generally. You can
> multiplex as much as you want to utilize the network properly. When
> duplicating to tape, you can "de-multpliex" to make each backup set
> sequential.
Thanks a lot for this recomendation, I=B4m starting to see the benefits
of this approach.
> If you can fit it in your budget, get 4x LTO3. Then you can do
> backup/duplication to one drive, copy tape to tape and still have one dri=
ve
> available for restore. However, if money is a bit tighter, I'd settle for
> two or maybe even one LTO3 drive and get some disk storage instead.

The last one: as we compete with other provider, the customer says than
someone is trying to get them into the "iscsi wagon". Do you think that
technology is mature enough this days? Will they REALLY get a cheaper
solution with enough cappabilities? Am I wrong...or is iscsi better
suited to distributed infrastructures? This people has all 6 servers in
the same place.

thanks a lot to you both,

JP

[ Post a follow-up to this message ]

Hi:

One of the new features LTO3 has is that it properly addapts to feed
slowdowns from 27 MB/s to 80 MB/s. I=B4ve read somewhere that in a test
it proved very efficient. Can we think that at sub-ideal speeds the new
LTO3 unit will be more reliable/speedy than a LTO2 because of this?

regard,  and I really appreciate this help

JP

[ Post a follow-up to this message ]

"JP" <seasidefan@yahoo.es> wrote in message
news:1120683995.901567.38750@g47g2000cwa.googlegroups.com...
> The last one: as we compete with other provider, the customer says than
> someone is trying to get them into the "iscsi wagon". Do you think that
> technology is mature enough this days? Will they REALLY get a cheaper
> solution with enough cappabilities? Am I wrong...or is iscsi better
> suited to distributed infrastructures? This people has all 6 servers in
> the same place.

iSCSI is just a transport, like SCSI or Fibre Channel. The main advantages
are that it works over a very well known infrastructure (Ethernet), and that
components for that infrastructure are usually already present in most
organisations. This means you save on training, and possibly on building a
new infrastructure if your current network can sustain the extra traffic.
For serious iSCSI work you still need to invest in new TOE Ethernet cards
for your servers which are similarly priced to Fibre HBA's, and you may need
to invest in new GbE switches.

If your customer is looking at hooking up the library through FC, why not
get the servers onto the same FC SAN and use the shared tape drive
(LAN-free) approach? All servers see the tape drives, the backup server
assigns which server can access which tape drive. Backups will be local to
each server, at full FC speed.

Rob

[ Post a follow-up to this message ]

Hi Rob:
I=B4ve been with the customer and with the help of you all I think I=B4m
guiding him in the right direction. The LAN-free issue is on the table
now, and I think it will be made that way. My worry was not to loose
sight from new ideas that can lead him in other directions and me not
having what to say.
The new doubt is this, and related with everything we wrote before: in
a "bad" network, which tape drive will suffer more? LTO2 or LTO3? I
explained that between 27 to 80 MB/s LTO3 adjusts to input, but I
don=B4t know which one will be slower at sub 20 MB/s speeds.

thanks a lot,


JP

[ Post a follow-up to this message ]

GigE switch is USD 100 for 5 ports. The card is something like USD 30
(Intel), it has task offload.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Rob Turk" <_wipe_me_r.turk@chello.nl> wrote in message
news:aW3ze.124$jA4.54@amstwist00...
> "JP" <seasidefan@yahoo.es> wrote in message
> news:1120683995.901567.38750@g47g2000cwa.googlegroups.com... 
>
> iSCSI is just a transport, like SCSI or Fibre Channel. The main advantages
> are that it works over a very well known infrastructure (Ethernet), and th
at
> components for that infrastructure are usually already present in most
> organisations. This means you save on training, and possibly on building a
> new infrastructure if your current network can sustain the extra traffic.
> For serious iSCSI work you still need to invest in new TOE Ethernet cards
> for your servers which are similarly priced to Fibre HBA's, and you may ne
ed
> to invest in new GbE switches.
>
> If your customer is looking at hooking up the library through FC, why not
> get the servers onto the same FC SAN and use the shared tape drive
> (LAN-free) approach? All servers see the tape drives, the backup server
> assigns which server can access which tape drive. Backups will be local to
> each server, at full FC speed.
>
> Rob
>
>

[ Post a follow-up to this message ]