nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Backing store conversion 6.1SP2 > 6.7.1 question

System

Hi DevNetters -
I'm researching backing store migration as one of the many steps of a 6.1 > 6.7.1 upgrade.

I'm getting a new Solaris server in a month or so and have the luxury of doing a fresh 6.7.1 install on the new machine. Meanwhile, I've wiped our old Solaris dev server, installed Solaris 10 on it and done a fresh 6.7.1 install on it. The server was barely up to the task, but the install succeeded and is running well.

Our dev server has a limited amount of available disk space available on it, so tarring up our production iw-store and moving it to the dev server isn't really an option. Since this is the case, I've started looking into iwmigrate. I had good experiences back with the 4.2 > 5.5 upgrade using iwconvert between two servers and was looking for a similar tool to do partial migrations between our 6.1 production repository and our new 6.7.1 repository.

After an unsuccessful initial try of mounting the production store to the dev server and trying iwmigrate, I've spent the past hour looking through other's posts on DevNet about trying this. They don't really paint a rosy picture, even mentioning the possibility of corrupting the remotely mounted production backing store.

Just like we did previously with the 4.2 > 5.5 conversion, our goal is to do a gradual migration from the 6.1 version on one machine to 6.7.1 on a new machine, running both servers as production during the migration period. This gives us time to address workflow, deployment and other conversion issues on a more individual basis for the different groups we support.

Having an incremental migration tool for individual branches would really help with this.

In your experiences, do you think that using iwmigrate in the fashion I've described is a possibility? If not, I'd appreciate any suggestions that would support the gradual migration scenario I've described.

Thanks in Advance,
Wally Box
Nike, Inc.

Find more posts tagged with

Comments

Adam Stoller

If you have disk space somewhere see if you can place a copy of your production backing store and mount it on your 6.7.1 DEV server - then configure that mounted backing store as if it were a (temporary) second store (iw.cfg entries + iwstoreadm).

Once you've activated the (temporary) second store for 6.7.1 - the server will do a "quick" conversion of it (you will not be able to use this copy on your existing production server after this!).

Once you've gotten the initial conversion done, then you need to deactivate the default store on your 6.7.1 box and use iwmigrate to from the (temporary) 2nd store into default.

Note: As has been posted - the size of the migrated backing store tends to be larger than the source store - this can be a very significant difference if you try to migrate a lot all at once. Given your shortage of disk space for your default store - if you don't need the full history, just migrate over the last 1 to 5 editions of each branch, and do it in a 2-step process:

to touch the temp_workarea's that iwmigrate creates - those are used to maintain state information between incremental migrations.The initial migration will definitely take longer than the subsequent incremental migration(s).When you're finally done and cut over to the new 6.7.1 store - don't forget to deactivate and remove the (temporary) second store - remember to remove the iw.cfg entries as well.Good luck

Migrateduser

Fish -
Many thanks for the info. That's pretty much as I suspected; I'm going to have to copy the store from one machine to another to get a conversion that will maintain the info in the backing store. I'm pretty sure I won't be able to test that on my current dev server.

That's not particularly ideal, given the way I laid out the way we'd prefer to do this and it's much less convenient than than the iwconvert tool from the 4.x > 5.x conversion - but I've got to work with the tools available!

Thanks again,
Wally

Migrateduser

Thought I'd do a short follow up for this thread:

I watched a Devnet best practices webcast last week and realized that (in my opinion anyhow) the tools for the upgrade don't really take in to consideration the production nature of many (ours included) TeamSite installations where several day outages aren't possible while we run conversion scripts on our fairly massive repositories.

So, as another option, I wrote a shell script on our current production machine that takes the output of the iwlist CLT as the control for calling some OpenDeploy configurations to move a subset of a branch's history to the new machine. The script takes as input:
- the branch to migrate,
- the number of editions to migrate,
- (optionally) the TeamSite group for the workarea being targeted.

It then:
- executes the iwlist CLT on the branch name, returning the output (a listing of workareas and editions) into an array for processing.
- figures out which edition to start from for migrating history. If I input 5 for number of editions to migrate, it'll find the newest edition, count back 5 from there and start processing.
- runs a 'dummy' deployment just to execute a dnr script on the target that checks if the branch already exists. If it doesn't, it creates the branch, creates the TeamSite group for sharing and then creates a workarea shared with the new group.
- runs a compare deploy between the oldest edition being transferred and the INITIAL edition and deploys the difference (in this case the whole edition) to the new workarea. The deployment ends with executing a dnr script on the target that submits the workarea's content and submits the STAGING area creating an edition.
- runs a series of comparison deploys between the increasingly newer editions until all of the edition history has been published to the new server.
- runs a final deploy based on comparing the source workarea to its STAGING area and deploying the diffs to the target workarea. This basically copies the 'work in progress' from one machine to another.

While this isn't capturing much of the 'who did what' info from the source repository, it does end up copying several editions of content and the work in progress to the new environment. We'll probably manually build out the members of the group accessing the new branch / workarea.

Wally Box,
Nike, Inc.

Migrateduser

Wally,

Have you tried using the iwmigrate from TS6.1 and doing an incremental migration? The reason you have to do a full copy is because TS6.7.1 iwmigrate utility cannot communicate with a TS6.1 server since the underlying transport mechanism has changed.

The process would be similar to the way backing store was converted from 4.5 to 5.5.

Thanks,
Shashi

mike_jaixen

I'm trying to think ahead and spec out our requirements for attempting an iwmigrate. I've requested a block of disk space, not realizing that I also needed to load a copy of the old content store.

So, for experimentation purposes, what I'd like to do is copy the backup copy to a subdirectory of the directory I had originally speced to hole the backing store, and then set the new backing store as another subdirectory.

I.E. load the old iw-store to /iwcontent/iw-store-old and then let iwmigrate copy things to /iwcontent/iw-store, with the store being loaded at /iwcontent on the old server.

In other words, when I copy the backing store from the old server, can I create a new directory name to hold the copy of it, or will that cause problems?

Migrateduser

I'm trying to think ahead and spec out our requirements for attempting an iwmigrate. I've requested a block of disk space, not realizing that I also needed to load a copy of the old content store.

So, for experimentation purposes, what I'd like to do is copy the backup copy to a subdirectory of the directory I had originally speced to hole the backing store, and then set the new backing store as another subdirectory.

I.E. load the old iw-store to /iwcontent/iw-store-old and then let iwmigrate copy things to /iwcontent/iw-store, with the store being loaded at /iwcontent on the old server.

In other words, when I copy the backing store from the old server, can I create a new directory name to hold the copy of it, or will that cause problems?

Let me restate the approach you want to take (just to make sure I got it right).

You have an existing server where the command "iwgetlocation iwstore" returns /iwcontent. You have installed a new TS6.7.1 server and on that you want to activate a copy of the original store. You plan to copy the original store to /iwcontent/iw-store-old on the new server. This will work as long as you copy everything under /iwcontent in the old server to /iwcontent/iw-store-old on the new server and the new server is configured such that "iwgetlocation iwstore" returns /iwcontent/iw-store-old. This can be done by editing /etc/defaultiwstore.

If you look at /iwcontent what you'll see there is a directory structure like

/iwcontent/default -> this is the default content store
/iwcontent/workflow -> this is the workflow store
...
..

What iwmigrate creates is an equivalent of /iwcontent/default. So when you say you want to create the migrated store under /iwcontent/iw-store (of the new server) make sure you give the -o option to iwmigrate as /iwcontent/iw-store/default

Then when you are ready to test the new store you can change /etc/defaultiwstore to have /iwcontent/iw-store instead of /iwcontent/iw-store-old.

Hope this helps.

Shashi

Piers

Hi - we're attempting something very similar - and running into an error.

We have a new Install of 6.71 on Windows 2003

A default backing store created at e:/iw-store.

According to the above post - we need to 'bring up' a copy of 6.1 backingstore.

The steps I took

a: ) 6.1 taken off line, back up made. (approximately 260 GB)
b: ) Copied 260GB to new machine
c: ) added the following lines to iw.cfg

store_directory_tempstore=s:\iw-store
store_comment_tempstore=6.1 Store

d: ) with TeamSite 6.7 running, tried to add the 'old' store.

iwstoreadm -a tempstore

Receive error 'Unable to activate store I/O error'

This isn't what I was expecting, I can get the backup of 6.1 to start if I make it the default store, eg. by updating the registry entry to point to s:\iw-store

Are we missing something here? We've not used multistores before...

Many thanks

Piers

Adam Stoller

Hi - we're attempting something very similar - and running into an error.

We have a new Install of 6.71 on Windows 2003

A default backing store created at e:/iw-store.

According to the above post - we need to 'bring up' a copy of 6.1 backingstore.

The steps I took

a: ) 6.1 taken off line, back up made. (approximately 260 GB)
b: ) Copied 260GB to new machine
c: ) added the following lines to iw.cfg

store_directory_tempstore=s:\iw-store
store_comment_tempstore=6.1 Store

d: ) with TeamSite 6.7 running, tried to add the 'old' store.

iwstoreadm -a tempstore

Receive error 'Unable to activate store I/O error'

This isn't what I was expecting, I can get the backup of 6.1 to start if I make it the default store, eg. by updating the registry entry to point to s:\iw-store

Are we missing something here? We've not used multistores before...

Many thanks

Piers

Is S: a local partition or a mapped drive to some other system?

Piers

S is SAN connectivity (not a true mapped drive)

Want to reiterate the point that if the SAN drive is the default the store it is 'activated' correctly. (Could there be a limitation with SAN drives as additional stores?)

Is our approach correct?

I notice in this thread - they are also bringing up the old store as the default.

Any thoughts much appreciated.

Adam Stoller

S is SAN connectivity (not a true mapped drive)

Want to reiterate the point that if the SAN drive is the default the store it is 'activated' correctly. (Could there be a limitation with SAN drives as additional stores?)

Is our approach correct?

I notice in this thread - they are also bringing up the old store as the default.

Any thoughts much appreciated.

I think the problem might be in this line

store_directory_tempstore=s:\iw-store

If memory serves correctly - it should be pointing to the archive name not just the store location - so something like:

store_directory_tempstore=s:\iw-store\default

might work

artem

Hi,

I'm not sure about windows, but I've had a similar problem on Solaris. I've been getting "Unable to activate store I/O error". The problem was in the file and directory permissions:
on 6.1:
- the files were owned by root and group was root
- the directory permissions were 600 (read by owner + write by owner)

on 6.7.1
- the files should be owned by iwts and group iwts
- the dirs should be 700 (read by owner, write by owner and execute by owner)

Once that was changed, it mounted the old iw-store. I'm not sure if this will help you, but try checking your permissions.

Artem.

Piers

I think the problem might be in this line
store_directory_tempstore=s:\iw-store
If memory serves correctly - it should be pointing to the archive name not just the store location - so something like:
store_directory_tempstore=s:\iw-store\default
might work

You're totally correct. DOH - can't believe I didn't catch this.

Many thanks for your quick turnaround - you've been supporting me funnily enough for about 4 years now Smiley Happy

Piers

Hi,

I'm not sure about windows, but I've had a similar problem on Solaris. I've been getting "Unable to activate store I/O error". The problem was in the file and directory permissions:
on 6.1:
- the files were owned by root and group was root
- the directory permissions were 600 (read by owner + write by owner)

on 6.7.1
- the files should be owned by iwts and group iwts
- the dirs should be 700 (read by owner, write by owner and execute by owner)

Once that was changed, it mounted the old iw-store. I'm not sure if this will help you, but try checking your permissions.

Artem.

Thank you for that too - we actually verified permissions first Smiley Happy

but it is an important point.