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; } } }

Freeze and backup on 6.7.1

dqueen

We are in the process upgrading to TS 6.7.1 (from 6.5) on new hardware running Solaris 10. I am noticing the time it takes to freeze and backup the new store is doubled from one hour to two on the new server, despite an upgrade in hardware and OS. The size of the backup has also doubled from 23G to 50G.

We did run iwmigrate on the backing store. We also now have teamsite search running with all branches indexed. Would this be increasing the size of the store? I didn't check the size in between running the iwmigrate and building the indexes, unfortunately.

Find more posts tagged with

Comments

Adam Stoller

We are in the process upgrading to TS 6.7.1 (from 6.5) on new hardware running Solaris 10. I am noticing the time it takes to freeze and backup the new store is doubled from one hour to two on the new server, despite an upgrade in hardware and OS. The size of the backup has also doubled from 23G to 50G.

We did run iwmigrate on the backing store. We also now have teamsite search running with all branches indexed. Would this be increasing the size of the store? I didn't check the size in between running the iwmigrate and building the indexes, unfortunately.

After running iwmigrate (with new, target backing store down) - you should always run iwfsshrink (with new, target backing store up - it runs in background).

Read more about iwfsshrink in the CLT manual.

dqueen

I am also migrating the workareas with iwmigrate -w.
Should I wait until all the iwmigration is complete before running iwfsshrink?

Frederik

it's possible your disk space growth is caused by iwmigrate only, and then can be solved by iwfsshrink.

another possibility is this: the iwstore contains many many small files. The install guide therefore recommends putting it on a partition that is formatted with a very small fragment size (or block size, or whatever the word is). If your new hardware comes with a disk with a fragment size larger than the old disk, you can also see an increment in used disk space. If this is the case, I recommend you reformat your data disk.

Baracus

...fragment size (or block size, or whatever the word is)

Sectors.

You make a very good point -- both sector size and stripes size (for those with RAID solutions) can make a huge difference in storage space. "Most" hard drives (SATA/ATA) are 512 bytes/sector, but I've seen many different setups within server environments, particularly those leveraging SAS drives.

However, it would take large differences in these sizes/settings to cause storage space to double, such as it did for dqueen. Leveraging iwfsshrink should resolve almost all storage related issues for users.

Proper disk management is usually ignored when migrating from one machine to another. Performance gains (RAID) are also overlooked regularly...

</rant>

dqueen

Running iwfsshrink brought the size back down in line with what it was before, so we will follow the recommendation to run this monthly to stay fit and trim.

Thanks for the help,
dqueen

Adam Stoller

Running iwfsshrink brought the size back down in line with what it was before, so we will follow the recommendation to run this monthly to stay fit and trim.

Thanks for the help,
dqueen

You could probably do it quarterly, semi-annually, or even annually - the amount of duplicate data created over time is generally fairly small except after performing an iwmigrate (in which case you should run it as soon as possible)

Migrateduser

If earlier mentioned tips are ot solving your issues, you might consider mirroring the store and take a backup from the mirror to limit downtime.

I just posted an example under:
http://devnet.interwoven.com/forums_vb/showthread.php?t=28383&page=2&pp=10

Ron

jed

If earlier mentioned tips are ot solving your issues, you might consider mirroring the store and take a backup from the mirror to limit downtime.

Better yet, since the OP is running solaris 10, they can use ZFS for the backing store and utilize a snapshot for a backup.

http://blogs.sun.com/twothirds/entry/zfs_and_interwoven_teamsite

Currently we keeping a rolling week of snapshots. This has also saved our **** when someone decided to perform a greedy "rm -rf" in a workarea. We were able to quickly create a "clone" of an old snapshot, mount it as an alternative store and get the data back in about ~10 minutes. If we had to go to a backup, this would have taken a day+.