A SAN of a WAN problem.

You might want to look at "seeding" copy the data to additional hardware, and send the hardware over. Then when you're making additions to the backups [not always fully resynching, I hope] that much traffic will fit over your pipes.

If you are doing full backups each night, you might consider changing strategies. Rather than spending the money on a fatter pipe, perhaps you want something like eVault to run your backups. We now backup each site locally, then backup the backups to the remote sites.

The % change for the backups is relatively small and easily fits over one to four T-1s. (several remote offices of various sizes)

I'm not associated with eVault, but we somewhat recently moved to their technologies (away from Veritas) and the whole team is rather enthusiastic about how much faster and easier the backups have become. When I find software like that, I share it.

From a support viewpoint, they have also been great. I highly recommend looking into them (or someone ith technology like theirs) before throwing money at a bigger pipe.

YOu might want to investigate synchronous or asynchronous SAN replication. This approach provides a realtime (sync) or deferred (asnyc) replication capability. Also the use of a "snapshot" of the data and then performing backups from the "snapshot" might solve the issue.

yep, you cna do the tlog backup overnight, enterprise edition of sql 2000 is easier to do this on, put the database into full model and get the database to backup the tlog every hour and transfer this across and apply this log to a copy of the server you have created the other end. sql 2005 makes this a lot easier as it is designed with this functionality in mind and it isn't too far away now.

Evault has a good product and it works very well, if you are interested let me know, and we can discuss or talk over the phone. Email me your personal or company contact infomration.

Bob

NetApp storage works in a SAN and NAS environment simultaneously and its disk to disk backup is at the block level. So, its use of WAN backup is optimized. The federal government loves using this technology for local central repositories that store repllicated backups from remote locations.

http://www.netapp.com/tech_library/3252.html

First and foremost your management team should find answers to the following questions prior to accepting the current mode of operating your data stores:

What data needs to be backed up and why?
When does the data need to be backed up and why?
When and/or how often does the backed up data need to be accessed and why?
What is the physical distance to manage an offsite storage solution that makes sense to your business?

A professionally developed business contingency plan will answer the questions above - plus dozens more.
Thank you,
James.

There are two software programs I will suggest. I have looked into them both, and am deciding to go with NSI Double Take. The other is Legato.

Both of these will backup your data to a remote site at the bit level. This is especially great for SQL, since you do not need to backup the whole DB across the WAN everynight. The system will send the updates instantly.

You can have your DR site running in less than 30 minutes.

Ditto on the recommendation for NSI Software's Double-Take. You might want to do some I/O profiling to determine how much bandwidth real-time replication will consume. Double-Take gives you read access of the replication target, so you can backup the target with no disruption to the source server. You can also fail services over to the target.

HP recently announced WAN Accelerators that increases throughput up to 100x in environments where latency and application 'chattiness' is high, or up to 20x in environments where latency is low. Testing has yielded over 15Mb/s over a T1 line. Models are available for connection speeds ranging from 512Kb/s to 45Mb/s.

Signiant has a white paper that takes a look at wide area backup best practices.

www.signiant.com/documents/WhitePaper_RemoteDataBestPractices2005.pdf

Their Mobilize product automatically initiates backup consolidation on a scheduled or event-driven basis. It identifies changes made to remote files since the last backup and moves only the bytes of those files that have changed to the central site. They have a calculator tool that will estimate the process time.

It is not the amount of your data (which is small) that is the problem. It is your mixed hardware assets. There are no case studies or white papers that can address your specific SAN to SAN backup issues because each situation is unique. They range from mildly problematic to impossible. It is the realm of high priced consultants who will gladly tell you that, 'if you have to ask, you're out of your league'. The fact that you are talking about 'replicating...backups' suggests that you may want to re-visit some fundamental concepts of disaster recovery. Not being offensive, just friendly advice.

You are correct that replicating your FULL 1.2 TB over a DS3/T3 (44.736 Mbps) connection is not workable, however it should only take about 3600 minutes (60 hours / 2.5 days) not three weeks. This assumes you have the full pipe available for your replication tasks - so you should probably double this replication time estimate to 120 hours / 5 days. However, I question why you want to replicate monolithic backup files versus doing block-level synchronization of your actual files and databases. Sure it might take 5 days to get the first copy across the DS3/T3 but the problem you should be looking at it is what % of your data CHANGES on a DAILY basis AT BLOCK LEVEL. In our work with hundreds of companies, we have seen a <5% DAILY RATE OF CHANGE AT BLOCK LEVEL (as opposed to file level changes). If the replication was done in a batch mode at night, this could be accomplished in about 180 minutes (3 hours) over a dedicated DS3/T3 circuit. Far better would be to synchronize changes several times a day - perhaps as frequently as every 10 minutes. Please contact me directly at plinden@datapreserve.com if you would like to discuss potential options.

Take a look at this product. After the first copy (full replication) it can replicate just the changes - very close to real time (you can choose how much bandwidth to use - which will impact on how fast the changes are replicated). We use it in just such a situation for our clients, it's been around for 15 years so it's very stable. Supports file and block data (such as Exchange and SQL).

The DS3 would give a throughput of 2.25 MB/sec of actual data transfer rate. Depending upon your current data size of 1200 GB and I ssume incremental growth of 12 GB daily, it would take 75 hours for a full transfer and 0.65 hours for incremental data to be transfered.

You need a REO4000 2TB box at both ends with the REO Multi-site Pac option providing you byte level incremental transfers with compression capabilities. The cost sums up to around 9000 $ per site.

Have you looked into what FalconStor has to offer?They offer replication as well as remote asynchronous replication for heterogeneous storage environments.
They should be able to provide you with multiple options for replicating.