[prev in list] [next in list] [prev in thread] [next in thread] 

List:       adsm-l
Subject:    SV: EXPORTs versus NODE REPLICATION
From:       Bent Christensen <BVC () COWI ! DK>
Date:       2013-12-15 16:47:04
Message-ID: 09256CD9E51DDF4B95F213E986079CA0B43D08F4E3 () DKLYEXMBX00 ! COWI ! Net
[Download RAW message or body]

Thanks Wanda,

Now I am kind of hoping I am not the only one who thinks export/import is slow - that \
would imply that I might be doing it wrong somehow :-) 

My recent experience with exports was from a TSM 5.5 (4 cores, 8 GB RAM) to a 6.3.4 \
(32 cores, 256 GB RAM), servers and nodes Gbit LAN connected. What I saw was that the \
TSM 5 server was able to back up a node with a 1 TB filespace in just below 4 hours, \
but when I exported that node to the TSM 6 it took almost 24 hours - and both those \
servers even have trunked GB NICs. Absolutely nothing was maxed out on the servers. 

The file spaces I need to bring back home are between 2 TB and 8 TB, most branch \
offices only have one file space.

We tried the copy solution some years ago but were not too happy about it, TSM \
decided to back up approx 1/3 of the node data anyway. It might have been an \
attribute issue, we didn't dig that much into it back then.

I should mention the portable TSM server I am playing with: It is actually small QNAP \
NAS devices featuring a big iSCSI-published disk for the storage pool and a VMware \
image containing a Windows server with TSM 5.5.7 which will connect to the iSCSI disk \
by its DNS name .  If the branch office already have a VMware host running I just \
mount the image on that or else it is just borrowing a capable workstation for a \
weekend, install VMware Player and spin the image up on that - works like a charm :-) \
The main reason for this solution is footprint, you can have travelling employees \
carry it in their luggage and the risc of the equipment getting stuck in customs in \
certain countries is so much reduced. TSM 5.5.7 is due to less ressources required \
compared to TSM 6, it is just easier to find a "host" with sufficient RAM and disk in \
the branch office.

 - Bent


________________________________________
Emne: Re: [ADSM-L] EXPORTs versus NODE REPLICATION

That's a curious question, and an interesting idea.

I see the advantages of  "set it and forget it" with replication, let it catch up on \
its own, without manual intervention.

But I'm also wondering *why* your export/import is sooooo slow.  No inherent reason \
it should be.

I'm assuming your portable TSM server just has a really big disk to hold all the data \
from the remote client? Do you start multiple exports? If you start multiple \
filespaces concurrently you should be able to run at the full bandwidth available \
between your portable and home TSM server, on your in-house network.

If that's not happening, I wonder if the problem could be the disk speed on the \
portable server, or the NIC is already too  busy on your home server. If the problem \
is a resource bottleneck, then you'll have the same problem with either replication \
or export/import.

Also,
if your portable TSM server has enough disk to hold all the data from the remote \
client, Have you ever tried  just copying the data wholesale to the disk, with \
drag&drop or xcopy? (assuming Windows here as an example).  Then bring it back, do \
the first back up in house, rename filespaces on the server end as needed.

W



We just started a project around consolidated backup of WAN-connected branch offices \
to a central TSM server. As always distant nodes, the first problem to cope with is \
how to get the first full backup of the node without waiting for days, weeks or \
months. We usually do that by sending a small TSM server to the branch office, do a \
first full backup, send it back to HQ and import the node(s) to the production TSM \
server.

However, export/import is sooo ridiculously slow so the export often takes days. So \
we have discussed upgrading the temp server to v6.3.4 and use node replication to \
"copy" the nodes. Lots of advantages, it can be put in a set-and-forget configuration \
until the nodes are fully replicated so switching the nodes to the prod server is \
pretty easy, but how fast is node replication actually?

Is node replication faster or slower than exports in a setup like this? Any thoughts \
or real-life experience?

- Bent=


[prev in list] [next in list] [prev in thread] [next in thread]