Unsolved

This post is more than 5 years old

826

December 21st, 2005 11:00

planning backup at remote site

I everyone,

I am in the process to install a backup solution for 15 remotes sites. I would like to ask the group, what they are doing for theirs remotes sites backup. Almost all my remotes sites have a 10MB link with us. We have to install new server in each site. We scale a maximum of 300GB of data per site with 5% of data movement per day. We estimate a standard backup solution with a Networker licence/tape backup/cartridge at 10K$. So we have at 150K$ to spend.

Can we do better with that 150K$? We love to remove the backup from the user hands and make them centrally. Sadly, we have to choose the solution rapidly, so not much time to test.


I am looking for your reply.

Alain.richard@mrnf.gouv.qc.ca

6 Operator

 • 

14.4K Posts

 • 

56.2K Points

December 21st, 2005 13:00

I have seen two major approaches to this:
a) each site is backup server or storage node to central server where remote site write to local small libraries which are very small (no more that 40 slots).
b) each site is storage node where data goes to disk (staged to tape later) and cloned to server or another remote site.

b) is tricky due to cloning component as sometimes remote sites are too far to get DWDM work (besides, its not that cheap). Due to that mostly today such sites still exists as small standalone backup servers with small libraries (autoloaders), but they are being extinct by migration of data to big data zones where everything is much much easier.

2 Intern

 • 

1.1K Posts

December 22nd, 2005 03:00

Your other option is to replicate data back to the central site and back everything up there (using something like EMC FullTime Replistor) - the advantages of this are:

* data is stored off site immediately
* data is managed centrally by (hopefully) people who know what they are doing rather than the office muppet
* jukebox is scaled with enough tapes so you are not reliant on someone changing the tapes
* possible more efficient use of tapes
* less hardware to manage/rely on
* may be possible to fail over to server at central location allowing users to continue to work

With 15GB you should have no problem replicating over a 10Mb link though you will probably have to use a tape to bring the initial sync of data across.

Your downside:

* if data changes significantly the link may not be able to cope
* a full restore over the link is not feasible
* long distance replication (1000s miles) will be hit by TCP latency issues
* costs go down at remote sites but up at central site!

Regards

David

2 Intern

 • 

724 Posts

December 22nd, 2005 04:00

Are you planning to have cloned tapes to store offsite?

I think the best solution would be one storage node at each site, backing up to disk (or a small jukebox, as any LTO2 tape alone would fit your 300Gb needs), and one backup server which will control all of them.
Then you could clone data on the storage nodes to the central server over the night. Easy, fast and secure... but I don't know if it would be cheap :)

March 3rd, 2006 07:00

Hi David,

We like to go with Replistor in a configuration mainy to one, so all my 15 remote site will replicate to 1 central server. That create one directory for eatch remote site on my server to replicate data(only).

There still 2 questions about that solution.

First, what will I do for DR, the software don't let me replicate all my C:\ to my central server. Usaly whit networker, we install a windows server and recover c:\ system DB,system files... and the server is back the same as before the crash. What are you doing for a server crash ??? All the sharing security and software configuration will be lost if we dont replicate the OS???

Next, what about the security aply on client file an directory, it look like I lose that when I recover a file from the central location. how are you recovering file for user when using replistor???

Alain

2 Intern

 • 

1.1K Posts

March 31st, 2006 01:00

When you lose your client at the remote site you have two approaches:

1. rebuild your machine locally on your head office site and fail back the Replistor client. Then shut it down and ship it out to the client.
2. rebuild your machine at the remote site then fail Replistor back - this may be slow if you have a lot of data.

Your data will be stored locally at your head office and backed up there; if something happens to that you will restore it as if it was a regular server that had failed there. Hopefully your client sites will not be hit by the same issue that caused the failure at head office.

What you need to assess is:

(1) the amount of data involved (plus the amount of change of data)
(2) speed you need to get the remote servers back
(3) local skill levels at the remote sites (would they rebuild/restore the data themselves or would you ship out an expert from head office?)

When the answers are:

(1) large
(2) quick
(3) high

it leans towards being a better choice to have a storage node on these sites; when the answers are:

(1) small
(2) slow
(3) muppets

replication is the better option. It may be a mix of these is the correct solution for you.

9 Posts

April 4th, 2006 09:00

To add to Davids recommendations, for DR perhaps some imaging software to stand the boxes up faster would be appropriate. What are your policies for downtime? This should develop your DR plan. If corporate says 99.999% then explain that that comes with a hefty price tag. Do you have redundant hardware?

Good Planning!!

0 events found

No Events found!

Top