Thanks to everyone for thoughts and ideas. Most planning, sizing, bandwidth usage forecasting, SLAs and stuff like that are almost done, it was how to do the initial full backup in the fastest and cheapest way that bugged my mind.
One possible solution that just came to mind the other day is to create a virtual TSM server, put the virtual image file on a USB disk and ship that to the remote office. Then mount the image at the remote site (2/3 are vmWare sites already, use VirtualBox on the rest), create a backup pool on the USB disk, backup up the clients, put the image file back on the USB disk and ship the disk back home. This saves the laptops. TSM performance might be crawling in this setup, but we can live with that. At the larger sites it is probably going to be a setup like Neils suggestion. - Bent -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Neil Strand Sent: Thursday, January 17, 2013 7:04 PM To: [email protected] Subject: Re: [ADSM-L] TSM 1st full backup of remote low-bandwidth nodes NAS device replication may not be a real option. The initial seed still has to transfer all of the data. Assuming a T1 operating at 1.5Mbits per second, it would take at least 14,814 hours (about 2 years) to transfer 10TBytes. You may consider shipping a SAS attached LTO5 tape drive with a small form factor (mini ITX MB) PC. at remote site - Backup locally to encrypted LTO5 media - Backup the TSM server DB to LTO5 media - Ship the encrypted tapes to the home office - ship the TSM server and tape drive to the next remote office and repeat at home office - Perform a TSM server recovery at the home office - export/replicate remote client data to primary TSM server - point remote client to primary TSM server which is now seeded with remote client data LTO5 is less expensive than 10TB of JBOD and probably what you use at the home office and can be easily encrypted and shipped. Small form factor headless PC is less expensive than laptop and can be managed remotely. All you need is someone to plug it into the ethernet, attach the tape drive and swap tapes when requested. Faster turnaround since the travelling TSM server(s) only returns to the home office when all remote site backups are complete. Thank You, Neil Strand From: Bill Boyer <[email protected]> To: [email protected], Date: 01/16/2013 01:04 PM Subject: Re: [ADSM-L] TSM 1st full backup of remote low-bandwidth nodes Sent by: "ADSM: Dist Stor Manager" <[email protected]> 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:[email protected]] On Behalf Of Bent Christensen Sent: Wednesday, January 16, 2013 11:25 AM To: [email protected] 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:[email protected]] On Behalf Of Huebner, Andy Sent: Tuesday, January 15, 2013 5:17 PM To: [email protected] 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:[email protected]] On Behalf Of Bent Christensen Sent: Tuesday, January 15, 2013 9:37 AM To: [email protected] 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
