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
