Home
TeamSite
to copy backing store from one server to another
RoseRuby
Hi
I want to copy a backing store from one teamsite server (Teamsite 5.5.2) to another (Teamsite 6.5)
Can I use iwmigrate to do this? Can some one enumerate the steps? I read the tech article (
https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=50601
)
Can someone help me?
Thanks in advance
Rose
Find more posts tagged with
Comments
Nicholas
There some threads available on this topic, try reading them. One of below
http://devnet.interwoven.com/forums/cgi-bin/showflat.pl?Cat=&Board=PRODUCTS_TEAMSITE&Number=58127&page=3&view=collapsed&sb=5&o=&part=
Thanks Nicholas
gzevin
that article has no relevance to your case.
basically, you need to physically copy the backing store, no migration or conversion is required.
if you are unsure how to do it, I'd reccomend to engage either Interwoven's PSO for a day or two or someone else who can help/ It's a simple process, but this might help.
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
RoseRuby
Thanks Nicholas and Greg
As Greg said that article won't solve my problem.
Can I follow the steps listed in article (
https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=50407
) i.e
Stop the servers
run iwfsck
tar the store
ftp the tar to target machine
extract
Restart the machine
All will be fine?Is it?
Please try to reply soon.
Thanks in advance
Nicholas
Copying the backing store physically means loss of EAs
Greg, may be this thread is not useful but the script, frogman was talking about may help.
This was my intension to provide thread link. btw Interwoven's PSO always the better option.
Thanks Nicholas
RoseRuby
Hi Nicholas
I have raised a request to frogman to share that script if possible.
Any way thanks once again!! Do reply if you have a solution at hand.
Thanks
Rose
gzevin
what do you mean 'loss of EAs'?
it's not true.
5.5.2 and 6.5 have 100% compatible stores. do not copy the IFS (e.g. Y: drive or /default..)... but rather the PHYSICAL copy. it will retain all the store.
I have done this so many times...
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
Nicholas
Below article may be helpful to transfer EAs, if you are planning for physical transfer
http://devnet.interwoven.com/site.fcgi/techlib/048789
Thanks Nicholas
gzevin
you did not say which platform it is on.
if it's Solaris, your system administrator should be able to copy /iwmnt to a tape (or anything esle you think is suitable) and restore to a new location.
the store administration routines are described in the manual, but if you are copying a single store, this should be very straightforward
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
gzevin
please do not confuse people. this script is not for this particular task.
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
Nicholas
Greg, I think, am confusing somewhere. can you please just eloborate "do not copy the IFS (e.g. Y: drive or /default..)... but rather the PHYSICAL copy"
Thanks Nicholas
RoseRuby
Thanks greg
I am working on Unix servers
I don't think I can go into copying the backing store to a tape. I need some other way ftp or the like.
Can u suggest on the same?
Thanks in advance
Rose
RoseRuby
Thanks greg
I am working on Unix servers
I don't think I can go into copying the backing store to a tape. I need some other way ftp or the like.
Can u suggest on the same?
And a side note (actually a question
)
Is a WWF(Word Writable File) a file which has its permissions set to 0777?
Can some one suggest me on remediation of WWF file (Is it by giving umask 002?)
Thanks in advance
Rose
Nicholas
Greg, as per my understanding, whenever we transfer the DCRs from one Teamsite machine to another Teamsite machine, they losses the Extended Attributes and we need to set them thru “iwextattr -s Teamsite/Templating=<DCRPath>”
I am also not understanding, what do you mean by “do not copy the IFS (e.g. Y: drive or /default..)... but rather the PHYSICAL copy”
Please explain and clear my doubt.
Thanks Nicholas
gzevin
well. I think we need to get into the TeamSite basics now.
TeamSite exposes its backing store via IFS (Inteligent File System). So, when you see it via, say, Samba connection (in the case of Unix), or /default/main and Y: drive (Windows), it 'looks' like a file system. So one can copy files from/to it.
However, this backing store looks like a set of jibberish files and directories, when you look into it to /iwmnt or /.iwmnt. So, THIS is the backing store, so THIS is what you need to physically copy. And you won't loose any EAs, (or even workflows, as a matter of fact).
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
gzevin
the transfer will depend on the standard within your organisation. I would not do FTP..
what is the size of your backing store?
I've done this in many ways. from backing up/restoring tapes to using rsync (which is way better than FTP).
having said that, I believe you need some serious help to get this job done. Get a consultant from IWOV for a day/two. This will be money well spent.
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
Nicholas
Okay. And for windows we need to copy only iw-store directory to new machine. Am I correct?
Adam Stoller
Greg - running a clinic for Nicholas?
Nicholas - you're thinking of individual file copying from within TeamSite to someplace else -- RoseRuby (and Greg) are talking about copying/moving the underlying backing store as a whole from one machine to another -- they are *very* different operations.
I think using rsync or OD, or some other decent recursive file transfer program to copy the entire backing store from A to B is probably faster than dumping to tape and then restoring it - unless you have a problematic network connection between A and B (in which case tape may not only be faster, but would probably be much more reliable).
As noted - remember to stop TS on *both* servers prior to doing the transfer to ensure that all data is flushed from cache and that nothing is being written into the backing store location at the same time as the copy is being performed.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Nicholas
Ohhh...this is the case. I was assuming files are also be the part of backing store so they require EAs setup and moreover I read some articles also on this, those created confusion from my side
Greg. I apologize for inconvenience and Ghoti, thanks for clearing my doubt
Thanks Nicholas
gzevin
There's no inconvenience. Simply leaving this key issue out and unanswered was something I could not do
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
gzevin
we actually experimented on a large backing store - rsync was a bit faster than tape backup, but in most of cases I'd agree that real-time file transfer of some sort is better.
Actually, last time we had to move backing stores (during 5.5.2 -> 6.1 upgrade, where I set up 6.1. and then moved the store), rsync helped a lot - we did some big transfer once, and then sending deltas ...rsync is really good at that.. I am not sure OD will do this job as good (having said that, I think OD as such is way more advanced).
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
RoseRuby
Hi
Thanks to all those who replied
Hope to hear from you all again!!!
jed
We perform backing store xfers quite frequently. We have found the following to be the fastest way to xfer it:
1. login to source teamsite server
2. cd to the backing store directory such as: cd /iw-store
3. Run a command similar to the following:
tar cf - . | dd bs=64k | rsh target-server "cd /path/to/store/on/target; dd bs=64k | tar xfp -
(You need rsh and a rhosts file setup correctly before you can do this.)
rsync is our next preferred method, and in some cases, can be faster. If we the store is not that out of sync, rsync can be faster since it is only brining over the diffs. If we are copying the entire store, the rsh method is faster.
As a side note, I was talking with our ops guy the other day, and tape might actually beat both rsync and rsh. Of course, depending on your tape/backing system and network, the speed will vary greatly. As an added benefit, we would also get to "test" our backup when restoring from tape.
--
Jed Michnowicz
jedm@sun.com
Content Management Engineering
Sun Microsystems
smenon
I just wanted to chime in regarding the issue of migrating from 5.5.2 to 6.5. As many of you have already pointed out, there is no need to migrate your store from 5.5.2 SP6 to 6.5. You can just physically copy the store and bring it up on a 6.5 server.
However, there are some benefits to migrating your backing store. If you physically copy the store and bring it up, the server will automatically convert your store to the new format in 6.5 as and when you access your content. On the other hand, if you migrate your store, all of the data is automatically converted into the new format during the migration and this could end up giving you a much more optimal backing store both in terms of size and also for performance. Again - this is left to your discretion about whether you want to just get up and running quickly by copying the store or if you want to spend some time and migrate your store.
thanks
--Sunil Menon
Product Manager
Interwoven, Inc.
Adam Stoller
Is there a way to force/coerce the full conversion of the backing store after having copied it over?
We noticed that our 6.5 SP1 / Solaris 9 system took about 7 hours to iwfsck a 25+ Gb backing store, and our recollection is that it took our 5.5.2 SP2b / Solaris 8 system only about 2-3 hours to do the same.
If this is a byproduct of our having copied the 5.5.2 backing store onto the 6.5 system - I'd like to know if there is a way to cooerce the full conversion of the backing store *without* starting over and *without* touching / modifiying each and every file in the system (i.e. we don't want to mess up last-modified dates and such).
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
