Copy iw-store

I am trying to copy my production iw-store folder and move it to my development server.

I ran "iwfreeze +3600". Copied the iw-store folder and tried to past it onto a folder on the same server. Whe I do so I get the error - "Cannot copy LOCKFILE: It is being used by another person or program. Cloase any programs that might be using the file and try again."

The files are
f:\iw-store\default\LOCKFILE
f:\iw-store\iwadmin\LOCKFILE
f:\iw-store\workflow\LOCKFILE

Do I need to do something other the run "iwfreeze +SomeNumberOfSeconds" to get the system to unlock these files? I can run "Unlocker" on these files but wonder of the ramifications.

Suggestions?

Find more posts tagged with

Comments

nipper

Is f: the source or destination ?

I do this already

Win 2003 ?

BTW, I use xcopy to do this, not copy/paste

SethHickel

Sorry - F is the source. And yes - win 2003.

nipper

Sorry - F is the source. And yes - win 2003.

Try x-copy. If I can I will bring up my Win install and try it out.

nipper

Strange I used xcopy before but I just tested it and I got a sharing violation as well.

You may need to shut down teamsite first

SethHickel

Which requires a re-boot to start back up - correct?

nipper

Which requires a re-boot to start back up - correct?

You can do it from control panel. However it is not a shock if you need to restart the computer

Adam Stoller

You may need to shut down teamsite first

Which requires a re-boot to start back up - correct?

No - back in the 3.x and perhaps 4.x days you needed to reboot the [Windows] server in order to restart the TS services, since then if you just make a note of the order the services are stopped / started when using something like

iwreset -a

you can write your own stop / start script using the

net stop / net start

Windows commands and manage it all from the command line without having to reboot the actual server.

And yes - you do need to stop the server processes in order to make a truly good / clean copy of the backing store because the server processes do hold on to these lockfiles that prevent a clean copying from happening otherwise.

SethHickel

And yes - you do need to stop the server processes in order to make a truly good / clean copy of the backing store because the server processes do hold on to these lockfiles that prevent a clean copying from happening otherwise.

Which services - all or just "Interwoven TeamSite?"

I'm confused because according to a response to a ticket I opened executing "iwfreeze +SomeNumberOfSeconds" without stopping any services is all that is needed for a clean back-up. (As long as the SomeNumberOfSeconds is long enough for the back-up to occur)

Now, the caveat is that they suggest specifying an option to skip particular files or locked files in the backup. (Not an idea that my server back-up folks like) The files they suggest skipping are:

\iw-store\default\journal
\iw-store\default\LOCKFILE
\iw-store\default\inodes\handletonode.dir
\iw-store\default\inodes\handletonode.pag
\iw-store\default\inodes\numtonode.dir
\iw-store\default\inodes\numtonode.pag
\iw-store\workflow\journal
\iw-store\workflow\LOCKFILE

So now I have a specific question - which services do I need to shut down in order to release locks on files in iw-store.

And a request for thoughts and/or suggestions - should I NOT shut down services and exclude the files listed above during my backup?

I have two needs - make a copy of the iw-store from prod to lay down on development AND to work with my server back-up folks to make sure that we get a good nightly backup to tape.

Guidance please.

Thank you.

nipper

This is what I use:

iwfreeze +500
xcopy e:\iw-store e:\iw-store-backup /E /H /EXCLUDE:d:\interwoven\exclusions.txt
iwfreeze --

cat exlusions.txt
LOCKFILE

Adam Stoller

I would suggest shutting down all IWOV services and not excluding any files.
IMO - that's the cleanest, surest way to get what you're looking for. Anything else is a short-cut which may or may not do what you want.

nipper

I don't know about that, I have restored without the LOCKFILE with no issues.

Now the one advantage to shutting down TS is that you can cycle logs as well.

mvusthipalli

You don't have to stop TeamSite for taking backup. As per the KB article: https://customers.autonomy.com/support/secure/docs/FAQ/Interwoven/50141.html, your back up process should avoid the LOCKFILE.

The problems with stopping the processes to take a back up is, some times the processes do not come down and you might end up rebooting the machine(Especially windows).

SethHickel

Now the one advantage to shutting down TS is that you can cycle logs as well.

Can you define "shutting down TS for me? Are you saying stop the Interwoven TeamSite service or are you talking about stopping all TeamSite services?

As per the KB article: ...

My concern about that article is that it dates from 2003 and refers to TS5.5.x.

Additional questions: If we shut down all TeamSite services do we still need to freeze the store? And, if we shut down only some of the services (say "Interwoven TeamSite" - depending on what the definition of "shutting down TS" is) is there still a need to run iwfreeze?

Thanks.

ISCBorisB

Freeze flushes TS I/O Caches and blocks System writes. Users can still log-in and read TS Data.
There is neither need nor the ability to freeze your Store(s) if you stop "Interwoven Teamsite" Server.

Adam Stoller

You don't have to stop TeamSite for taking backup. As per the KB article: https://customers.autonomy.com/support/secure/docs/FAQ/Interwoven/50141.html, your back up process should avoid the LOCKFILE.

The problems with stopping the processes to take a back up is, some times the processes do not come down and you might end up rebooting the machine(Especially windows).

If you shut down the services - the LOCKFILE goes away and you don't have to worry about an exception.

If you have a problem with "some time the processes do not come down" - then you have a significant problem that should be fixed anyway.

As nipper indicated, bringing down the services also allows you to rotate log files (this may become less of an issue if/when 7.0 really comes out) - but since you are going to be disrupting service at least a little bit, why not just do the whole thing cleanly - by shutting down all the TS services and then make the copy of the store.

Keep in mind - we're not talking about backing up here - we're talking about replicating the production server's backing store completely on the dev server. I prefer to make the instructions simple:

mvusthipalli

Any way, that varies from people to people. I see no issues in doing the usual way of freezing it and then backing up or synching up with the other servers (avoiding the LOCKFILE). We have been doing the same process with TeamSite 6.7.2 boxes though the KB is old, it is still same. Also, you can always confirm with IW support about the same if you have doubt.

SethHickel

Thank you all for your suggestions and comments concerning taking a full copy of iw-store for restoration and/or copying to another server.

Additionally, I am putting in place for our nightly tape incremental back-up of the server and thus iw-store a call to
"iwfreeze +SomeVeryLargeNumberOfSeconds" before the incremental server back-up and then a call to "iwfreeze --" when the incremental back-up is complete.

Would there be a consensus that this is sufficient for incremental nightly backups or would the consensus be to shut down all TeamSite services for a nightly incremental back-up?

ISCBorisB

Thank you all for your suggestions and comments concerning taking a full copy of iw-store for restoration and/or copying to another server.

Additionally, I am putting in place for our nightly tape incremental back-up of the server and thus iw-store a call to
"iwfreeze +SomeVeryLargeNumberOfSeconds" before the incremental server back-up and then a call to "iwfreeze --" when the incremental back-up is complete.

Would there be a consensus that this is sufficient for incremental nightly backups or would the consensus be to shut down all TeamSite services for a nightly incremental back-up?

We do exactly that (freeze/back-up/unfreeze) for both iwstore daily Deltas and Weekly full back-ups.

nipper

Would there be a consensus that this is sufficient for incremental nightly backups or would the consensus be to shut down all TeamSite services for a nightly incremental back-up?

Freeze will be OK if the LOCKFILE does not effect you.

I am not a fan of incremental backups for TeamSite. Once you try to restore from backup the iwstore, you will understand why.

Bjorn

[QUOTE=ghoti]If you shut down the services - the LOCKFILE goes away and you don't have to worry about an exception.

If you have a problem with "some time the processes do not come down" - then you have a significant problem that should be fixed anyway.

As nipper indicated, bringing down the services also allows you to rotate log files (this may become less of an issue if/when 7.0 really comes out) - but since you are going to be disrupting service at least a little bit, why not just do the whole thing cleanly - by shutting down all the TS services and then make the copy of the store.

Keep in mind - we're not talking about backing up here - we're talking about replicating the production server's backing store completely on the dev server. I prefer to make the instructions simple:

Since everyone is chiming in...In the past I've just disabled the stores using the CLT, then done the copy, then reenabled the stores using the CLT. This is especially handy if you have multiple stores but don't want to have them all be inaccessible.Of course, I don't know if this is "good" or "bad" . It's worked and I haven't been particularly concerned about it given that I've always been copying to a dev environment, where as long as it seems to work, I usually have few complaints.

SethHickel

I am not a fan of incremental backups for TeamSite. Once you try to restore from backup the iwstore, you will understand why.

I'm not sure I understand your concern with incremental backups. We restored our production iw-store yesterday (corrupted store) from an incremental back-up and have not seen any issues related to that fact yet. What types of issues might I see from using an incremental back up for a restoration?

Are you advocating that, in addition to the normal nightly incremental server back-up, that we also do a complete back-up of iw-store?

As an FYI - our iw-store is about 70Gb.

One thing that I have not considered is using more than one store. I wonder if it might be advisable to separate out our e-commerce content into its own store and keep all intranet content in a separate store. What considerations do you take into account when considering using more than one store?

Thanks.

Bjorn

What considerations do you take into account when considering using more than one store?

Cost, basically. It's a licensing issue. (Plus the rework of modifying any paths you might have, I guess.) If I remember, the original point of "multistore" was to make backups easier (faster) if you didn't have something like snapdrive for doing quick backups. I'm sure the hardcore guys may have more insight.

nipper

What types of issues might I see from using an incremental back up for a restoration?

Are you advocating that, in addition to the normal nightly incremental server back-up, that we also do a complete back-up of iw-store?

As an FYI - our iw-store is about 70Gb.

One thing that I have not considered is using more than one store. I wonder if it might be advisable to separate out our e-commerce content into its own store and keep all intranet content in a separate store. What considerations do you take into account when considering using more than one store?

Thanks.

It is a pain. That is all. But since you have gone through it, you know what to expect.

We do nightly complete backups, however our store is < 10GB

Multiple stores would be nice, you can put them on different disk subsystems and back them up differently (and in parallel), there should also be performance improvements by splitting the sites (all depending on your system however). Major difference is cost of getting to multiple stores and the effort to do so. Splitting branches with history is a pain, not difficult just time consuming.

SethHickel

Splitting branches with history is a pain, not difficult just time consuming

A fact that might make the move to multiple stores easier for me is that the division of stores would mimic my sub-branches under default\main.

with iwmigrate something like:
iwmigrate -m Y_or_CurrentMountDrive:\default\FolderName -o D_or_CurrentIWStoreDrive:\iw-store\NewStoreName -b
\default\main\NameOfSubBranch

But I am not sure what to put in FolderName if anything since the use of -b \default\main\NameOfSubBranch seems to negate the need for anything other then -m Y_or_CurrentMountDrive:\default\ -- or -- is FolderName used to identify the branch and/or location under Y_or_CurrentMountDrive:\default\ that the executable is to grab and relocate to the NewStoreName?

So does this executable read from the Y: drive (-m switch) the contents of the identified branch (-b switch) and then pull the appropriate binaries out of the existing iw-store and write them to the new store with history (-o switch)? And does it at the same time (or after succesfull migration) remove the content that has been migrated from the original store?