Bent,
I have been down the road that you are about to travel, only on a smaller scale
(26 sites).
It was however before TSM offered de-duplication but I am sure that's of little
help regarding your initial backup. Some of our sites had 256k lines and a few
had single T1's. All of them had some degree of latency issues.
After proposing several solutions to our management team, none of which were
attractive for one reason or another the decision was made that we were to kick
the initial backups off across the WAN. They could only run after close of
business each day and we were held responsible for canceling them during
business hours. Fortunately, they could run all weekend long or they may still
be running. Eventually they completed but that was only the beginning of the
nightmare. Daily backups would often run all night and bleed into business
hours at which time management would get a call from either frustrated end
users or our network team complaining about the processes bringing the WAN to
its knees. I won't even get into the whole nightmare of performing a simple
restore!
After wrestling with the poor performance, customers at the sites screaming
about the backups hogging the WAN, and the TSM Admins reminding how ugly
recovery would be, the decision was made to budget for increasing the
bandwidth. In the end I think management regretted not procure the funds needed
to address WAN speed up front as they had to endure an enormous amount of
criticism and bad PR due to the aforementioned issues.
While I understand that none of this may be what you want to hear, or the
solution to your immediate need, the bottom line is that the key to a competent
centralized backup solution is to procure the tools that will make is operate
efficiently. Sure increasing bandwidth across 100+ sites is a costly venture,
but I will go out on a limb and guess that it's much cheaper and more efficient
than buying 100+ backup servers, the associated licensing and storage for each
location. Not to mention the man hours to manage them.
On a closing note regarding our implementation; once management committed to,
and budgeted for, the higher performing WAN links, and seen what it meant to
the solution operationally their perspective changed. People began bragging
about the solution rather than being constantly beat-up about it.
~Rick
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Huebner, Andy
Sent: Wednesday, January 16, 2013 12:14 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM 1st full backup of remote low-bandwidth nodes
The only realistic solution to complete what you are trying to do over the wire
is a client side de-duplication solution. In that case you can seed the backup
server with local data.
I did not understand the quantity of sites you had to deal with.
Andy Huebner
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Bent Christensen
Sent: Wednesday, January 16, 2013 10:25 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM 1st full backup of remote low-bandwidth nodes
Andy,
I do not totally agree with you here.
The main issue for us is to get all 107 remote sites converted to TSM
reasonably fast to save maintenance and service fees on the existing backup
solutions. With the laptop server solution we predict the turn-around time for
each laptop to be around 2 weeks, which includes sending the laptop to the
remote site, back up all data, send the laptop back to the backup center,
export the node. With say 10 laptops this will take at least 6 months. We could
buy more laptops but we cannot charge the expenses to the remote sites, and we
are stuck with the laptops afterwards ...
Disaster restores is a very different ball game. Costs will not be a big issue
and we have approved plans for recovering any remote site within 48 hours,
which for a few sites includes chartering an aircraft to transport hardware and
a technician.
- Bent
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Huebner, Andy
Sent: Tuesday, January 15, 2013 5:17 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM 1st full backup of remote low-bandwidth nodes
You should use the same method to seed the first backup as you plan to use to
restore the data.
When you look at it that way a laptop and big external drive is not that
expensive.
Andy Huebner
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Bent Christensen
Sent: Tuesday, January 15, 2013 9:37 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] TSM 1st full backup of remote low-bandwidth nodes
Hi,
We are starting up a backup consolidation project where we are going to
implement TSM 6.3 clients in all our 100+ remote sites and having them back up
over the WAN to a few well-placed TSM backup datacenters.
We have been through similar projects with selected sites a few times before,
but this time the sites are larger and the bandwidth/latency worse, so there is
little room for configuration mishaps ;-)
One question always pops up early in the process: How are we going to do the
first full TSM backup of the remote site nodes?
So far we have tried:
- copy data from the new node (include all attributes and permissions) to
USB-disks, mount those on a TSM server (as drive X) and do a 'dsmc incr
\\newnode\z$ -snapshotroot=X:\newnode_zdrive -asnodename=newnode'. This works
OK and only requires a bunch of cheap high capacity USB disks, but our
experience is that when we afterwards do the first incremental backup of the
new node then 20-40 % of the files get backed up again - and we can't figure
out why.
- build a temp TSM laptop server, send it to the remote site, direct first full
backup to this server, send it back to the backup datacenter and export the
node(s). Nice and easy, but requires a lot of expensive laptops (and USB disks,
the remote sites typically contain 2 to 10 TB of file data) to finish the
project in a reasonable time frame.
So how are you guys doing the first full backup of a remote node when using the
WAN is not an option?
- Bent
|
