Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
THRUST SERVICES & TOOLS
CLOUD EDITIONS
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Backing Store Questions
System
1) How does one know if their data is going to a backing store
in my directory \iw-store\default\inodes I see several files with handletonode.dir being the most megs but it's date is from one month ago?
2) Once I know the answer to 1) - how does one revert back to their old data via a backing store - is their some command sequence one runs?
3) I don't believe we are running a -iwfreeze when we are doing back-ups to tape - is this a problem?
Note - as I understand backing stores - it saves your content in nodes which you then if you lose your data - restore the nodes to get your content back
Finally - I'm using TS 5.5.2 SP2 on a Windows 2000 server
Find more posts tagged with
Comments
james1
> 1) How does one know if their data is going to a backing
> store in my directory \iw-store\default\inodes I see several files
> with handletonode.dir being the most megs but it's date is from
> one month ago?
All of your content is under \iw-store\default\d0.
> 2) Once I know the answer to 1) - how does one revert back
> to their old data via a backing store - is their some
> command sequence one runs?
If you want an older version of a file in your workarea, the iwrevert CLT will do that, or View -> History. If you want to roll back the enter server to another moment in time, you need to restore the backing store to a backup copy.
> 3) I don't believe we are running a -iwfreeze when we are
> doing back-ups to tape - is this a problem?
That is the worst thing you could be doing to yourself. None of your backups are likely to be valid.
> Note - as I understand backing stores - it saves your content
> in nodes which you then if you lose your data - restore the
> nodes to get your content back
This doesn't make much sense to me, but I get the feeling that you don't understand the backing store. You may want to read manuals and posts in these forums, and take some training courses.
-- James
--
James H Koh
Interwoven Engineering
Migrateduser
I would recommend the admin guide available here:
https://support.interwoven.com/library/manuals/teamsite/html/552/ts.552.admin.win.htm
as far as training, you probably would find the TeamSite admin course the most useful. There also may be others at your site with some of this knowledge, you might want to ask around.
Hope this helps.
lissa
Migrateduser
Lissa/James -
1) james - thanks for the info - when I asked:
"as I understand backing stores - it saves your content
in nodes which you then if you lose your data - restore the
nodes to get your content back" -
I don't believe I was far off the mark as the users manual which Lissa sent states:
"All mounted backing stores are assigned a unique store ID number and maintain their own set of inodes that are stored persistently inside each backing store"
2) Lissa - thanks for the link - I did indeed take the Teamsite admin class last July - but we didn't cover backing stores too in-depth and up till this point in time - I haven't had to really worry about them - since live-data has only gone into the system the past few weeks
Thanks
Excel spreadsheet example.docx
Migrateduser
In addition to reiterating James' caution to absolutely make certain the backing store is frozen during backups I have an additional recommendation WRT backstore backups: test them. My experience is that about 1/2 of untested backups are write-only media. If tested every month, they become very much more reliable as a read-write media.. When smoke seeps out of the hard-drive enclosure, as it someday will, it's _very_ good to know that you've had a successful restore test in the last month.
If you have multi-store, this is very easy to do and very worthwhile. You can create a restore testing store, restore a recent backup to it and examine the restored content. If you do not have multi-store, I'm not exactly sure what to tell you since I''ve usually had either multi-store or a spare TS server available to serve the restored content (the spare server was my approach before multi-store was available).
Migrateduser
Thanks for the advice - I do have a development teamsite server to muck around with - but I'm not using a multi-store - I have one single store directory because right now I have only one branch - therefore any suggestions on moving the back-up store from the staging server to development
Migrateduser
Backup is the most important step in TeamSite implementation, you have to treat teamsite backend store as a database, just imagine if we don't have a good backup on database what worst thing could happen.
We recently changed our backup procedure to make sure we have a good backup. Here is the backup procedure:
1. run /iwhome/iw-home/bin/iwfreeze +25200
2. copy the /iwstore to /iwstore_c (We use gnu tar to transfer files from /iwstore to /iwstore_c)
3. backup /iwstore_c to tape.
I also tried to restore the iwstore to our development server and everything seems to be working fine. I just wonder is there anything else I should test to ensure the integrity of iwstore.
Migrateduser
Running 'iwfsck' on the restore would be good. We do that before a visual examination.
When we first started doing test restores, we'd sometimes mistakenly configure the server so it was still serving the live content instead of the restore. We'd do a change immediately after the backup and make sure the backup did _not_ have the change. Thus demonstrating that it was the backup being served, not the live content. From your description, of your process this is not necessary since you can see both sets of content simultaneously (as we can since starting to use multi-store).
Oh! This is not peculiar to TS backups, but perhaps bears stating anyway: stagger backups. Keep a set of 6 media for daily backups; a set of 4 for weekly; a set of 3 or more for monthly. This way if you lose some data that doesn't get noticed for a while, you have the option to go back further in time to retrieve it. Always having a b/u less than a day old; less than a week old; less than a month old. Plus older b/us. AFAIK, this is not compatible w/incremental b/u.
So make a choice between increased security and shorter b/u time. We use a NetAppliance to snapshot the store and b/u the snapshot. So the server is only frozen for <5sec. to do a b/u. I don't really care if the b/u takes 1hr every day since the server is available in 5sec. And the same thing, though not as quickly, can be achieved by copying the store to another filesystem, unfreeze the store and b/u the copy.