Have you looked at replication of those remote sites as opposed to backup of
the sites directly?
For those sites that could use a storage replication device to replace the
file server (Netapp, Data Domain,...) and replicate it to possibly a central
or hub sites. Then back up from there? Replace the file server with a NAS
CIFS device and let it do the replication. If you use a solution like
Netapp, snapshots can even be your backup solution for the site.
Possibly "cloud" solutions. An example could be CarbonCopy and DATTO. Just
to name them as examples as opposed to recommending those specific products.
Or (and I can't believe I'm going to suggest this!) Microsoft DFS
replication.
Just some other thoughts on the subject....
Bill
-----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 11: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
|
