Juha Jäykkä wrote: >> up things my moving volumes to the new server only to realize that I >> did something wrong in the process. I though that "copying" ( if such a >> thing exists) would be safer. But from the response of Russ only one >> copy should exist on a cell so I am not really sure what to do. >> > > I'm not sure, if this will work, but it SHOULD. Someone with more > experience and knowledge may want to confirm whether I'm right or not. > > Anyway, if you're really paranoid about it, you might just do this for > all your volumes: > > 1) vos addsite -server old -partition /wherever_it_is_NOW -id volume_name > 2) vos addsite -server new -partition /wherever_it_fits -id volume_name > 3) vos release volume_name > 4) vos move -id volume_name -fromserver old -frompartition > /wherever_it_is_NOW -toserver new -topartition /wherever_it_fits > > This way you'll have two copies at all times, but still end up having > moved the read-write volume to the new server. The addsite commands just > set up two read-only replicas. > > Next, you'll replicate the DB server, too. Easiest way to do this is to > create an upserver process on the old machine and an upclient process on > the new host. (Read the AFSLore or man bos_create for details.) Adding DB > servers to an AFS cell is rather tricky for the *clients*, so you'll need > to be sure you do it right; otherwise your client will lose access to > their files (nothing serious, just inconvenient: it can be fixed easily). > > At this point you can test how things work by unplugging the network from > the old server - if things go wrong, you just plug it back. > > If everything works, just use "vos remsite" to remove the RO replicas > from the old server and "bos delete" to remove the upclient and upserver > processes. After that, just scrap the old server. > > -Juha > > My 2 cents: Trust afs to do the right thing. If your cell is healthy you will not lose a volume during a vos move. Best advice is create a volume on old server load it with some data and "vos move" it to your new server if you want to test it. Do Not use a unix command like mv or cp or tar. Just let afs do it. I move volumes all the time and my users don't even know it. /sd
-- Steve Devine Storage Systems Academic Computing & Network Services Michigan State University 506 Computer Center East Lansing, MI 48824-1042 1-517-432-7327 Baseball is ninety percent mental; the other half is physical. - Yogi Berra _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info