Sumthin' wrong with those numbers.

If you have a GigE pipe, you should be able to send 70-80 MB/sec.  thats
400+ MB/min, 240+ GB per hour, 4+ TB in 24 hours.

So, either
- your clients are having performance issues with their own disks
- maybe you have compression or something else slowing down the client:?
- maybe your client NIC isn't really set to GigE
- You have a switch somewhere that is not pumping GigE...
- Your NIC on the TSM SERVER is maxed out

Or something like that.  I'd try some testing with FTP, to see where the
bottleneck is, before deciding this isn't feasible.

W


On Mon, Aug 24, 2009 at 12:53 PM, Ochs, Duane <Duane.Ochs AT qg DOT com> wrote:

> Good day everyone,
> I'm looking for some workable suggestions for larger lun backups.
> I'm talking 1.5tb and larger lun sizes. I have a number of remote sites
> that have large quantities of hi-res image files and they need an offsite
> backup solution. Usually we are notified before the disks go into production
> and the backups grow as the disk is populated.
> Normally not a big deal. Now we are in the middle of a large conversion for
> many remote sites which will require a full backup for all of the sites. And
> each has in excess of 6 tb of images. In addition we are also migrating a
> number of rogue sites to TSM which also have in excess of 4tb locally.
>
> I tried a test and ran one disk as a full over a 1gb pipe to 2tb of TSM
> diskpool on Sata disks. It has been running for 3 days. Not only is it not
> acceptable in a real DR scenario (Currently we restore to the same site as
> the TSM server then move data back in order of importance),but,  it will
> also take weeks before I can safely say we are back to being fully backed
> up.
>
> Other than local backups for each site... has anybody come across a similar
> scenario and care to offer some advice.
>
> Some specifics: I have 3 TSM servers (AIX) with either a L700 or a T950
> library.  No data is backed up locally. All data is sent over the network to
> a remote TSM server.
>
> Thanks,
> Duane
>