Archiving Editions

We are running TeamSite 4.5.1sp2 and Templating 4.5.1sp2 on Solaris 2.7. We typically generate one EDITION per day per locale (currently four locales). We would like to be able to save editions off to optical disc for archival storage and legal requirements.

What options are available for creating a restorable edition "archive" that we can save for later use? Is it possible to simple 'tar' up the edition directory structure, which is in our case /iwmnt/default/main/www/${CONTINENT}/${LOCALE}/internet/EDITION/${EDITION_NUM} ?

If we can do this and delete the archived editions, does the resulting tar file give us a structure that we could restore into /iwmnt and republish if necessary at a later date?

I've always been surprised the TeamSite doesn't offer some form of archiving built-in.

Find more posts tagged with

Comments

tvaughan

A) The first question to ask is: are you sure you need daily editions? If 99% of the content in your STAGING area doesn't change from day to day, you're unnecessarily consuming resources by cutting all those editions.

If you want to "restore an EDITION and republish if necessary at a later date", I assume you're talking about an EDITION that you've saved off the /iwmnt volume and deleted from being "actively available" within Teamsite. Because if the edition is right there in Teamsite, you can just pubilsh it from where it lives. Or, you can create a new WORKAREA in your branch based off the EDITION you want and force-submit that WORKAREA onto your STAGING area.

C) Assuming you want an edition every day and you started moving old EDITIONS off the /iwmnt and onto backup media, yes you can just tar up the EDITION/ed_00xx directory and store it to optical disk. If you wanted it back in Interwoven, I would untar it into an empty WORKAREA and then submit that WORKAREA into STAGING and cut a new EDITION.

Tom

msrich

We have similar concerns. We run TS 4.5.1 on NT.

KB article 1507 says "Editions in and of themselves don't really take up disk space ...." You indicated that having a lot of editions will consume resources? Were you talking about disk space? It seems to me that although within the backing store, an edition might be a collection of pointers, it manifests in the virtualized file system as a collection of files -- files that take up space on the disk.

We've gotten strong recommendations not to delete editions (we have performance concerns). So we're faced with what looks to be a never ending pile of editions we can't get rid of and that take up space. How do other customers handle this?

The virtualized file system is gee-whiz, but the overhead is making it seem unattractive. As with other versioning systems, TeamSite maintains archives via deltas, but here I'm also saddled with numerous copies of all my files. You suggest not cutting so many editions, but what's the alternative, selective deploy? What I really need is some standard labeling so I can collectively refer to certain revisions in my archives, without the burden of having copies of these revisions taking up disk space.

Like pejacoby, we're also interested in safeguarding editions to external storage. In our NT environment, do you think we should OpenDeploy somewhere?

tvaughan

I found this discussion of Edition archiving on the support site:

http://support.interwoven.com/library/whitepapers/customers/backup_best_practice.htm


4.1.3 EDITIONS AND NUMBER OF ITEMS PER DIRECTORY 
Publishing new edition will increase the size of the backing 
store slightly.  This is rather complicated to calculate, and 
depends on several factors.  For every file that is submitted 
and published, there are 2 metadata files created (each about 
600 bytes), and 1 standin file created (about 200 bytes).  2 
more files are created that represent the submit event, and 2 
more files created to represent the edition created (each of 
these 4 are about 250 bytes).  If the different files in different 
directories are touched, the numbers of directories touched 
becomes another factor.  As you can see, it can be quite 
complicated to calculate how much the backing store will 
grow depending, and it ’s nearly impossible to take in factors 
such as how many times you submit a file between 
publishing editions.  Assuming you publish after every submit, 
you would have a rough f ormula that goes something li ke 
this: Increase = n*(nSize + 3*f) + 4*f + (d * dSize) where 
Increase is the increase in size of the backing store, n is 
number of files submitted and published, nSize is the average 
size of those files, f is the fragment size, d is the number of 
directories touched, and dSize is the average size of 
directory metadata files.  For example, submitting and 
publishing 1000 new files that are 64K on average, and 
assuming these files span 10 directories where dSize is 2K 
on average, your backing store (with 1K fragment si ze) 
would increase by: 1000*(64K + 3*1K) + 4*1K + (10 * 2K) = 
67,024K =~ 67MB The data files account for 64MB of the 
growth, so the metadata files account for only 3MB of 
growth is this example.  From the example, we can see that 
publishing a  lot of editions in a branch will result in a 
moderate growth of the backing store.  A related f actor is 
that a director y with a large number of items will have a 
bigger directory metadata size, and each time that directory is 
touched, the backing store wil l grow a bit more than in this 
example.  Furthermore, both of these factors, publishing a 
large number of editions, and having a large number of items 
in a directory, can cause severe performance problems over 
time.  As a result, Interwoven recommends keep ing less than 
1000 editions per branch and less than 500 files per 
directory, but keep the edition count under 500 if there are 
1000 files per directory.  Directories over 1000 items should 
be avoided.  Again, the above calculations apply only to 
TeamSite 5.0X and earlier, and future version of TeamSite will 
have a different backing store format that will require a 
different f ormula.