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
|
