Layout Books on a Server

[Anonymous]

We are finding that ArchiCad is very greedy on server resources especially when using a back up programme like Retrospect.

Our PM layout books are getting large and when any changes are made they are backed up automatically at the next back up session. The idea of having one book for a porject is great untill you see how large the LBK gets, its huge. We've resorted to breaking up the layout books into smaller ones. Does anyone have any hints on whoe to streamline this a bit??

Maybe I'll just have to get a bigger tape drive.

Pete Dallyn

[Anonymous]

I don't worry about file sizes. Storage is so cheap and the work is so valuable.

As I have written elsewhere, I recommend dumping the tape drives. They have too many problems to be considered reliable and they are not that cheap either.

The best approach (IMHO) is to mirror the server to an external hard drive every night and rotate two such drives at least weekly. For archival back-up use CDs or DVDs. Just mack a stack (the hard part is getting it started) take it off site. The incremental discs go to join the main gang as they get filled up.

[Anonymous]

We generally have no problem with tape drives and the advantages of having snapshots of all files across the whole of any project, is and has proved invaluable. Switching drives every week does not provide this kind of historical snapshot?

We use Mac OS 10.2.8 Server with Retrospect and a Sony AIT tape drive, the tape drive although expensive, is worth every penny in my opinion.

Pete Dallyn

[Anonymous]

No the mirror drives do not provide historical backup. That is what the CD/DVD archives are for.

I have rarely needed to recover files deleted weeks or even just days before. Since I have always backed up projects to CD (well, since I got my first CD writer in 1992) at each significant issue, and I generally keep all significant revisions of a current project on the hard drive, I have always been able to find the files I need among these.

Usually the day to day emergencies like "I just saved and now I need to undo all the stuff I deleted by mistake..." or "My project file is all messed up..." (for whatever reason) can be taken care of using the .BPN file, the teamwork backups, or the mirror backup from the night before.

If you really want full historical backup (for more immediate access than the off site archive) then get an really big hard drive and do an archival backup to that. Lacie has a 1 TB (terabyte = 1024 GB) drive for $1199US. This is less than a high end tape drive (last I looked) and it includes the storage medium. How many tapes do you have to buy to store a terabyte? And remember, tapes are not an archival medium; they degrade over time like floppies (remember them?) and so are not a suitable substitute for CD/DVD archiving.

BTW. Keep in mind that professional archivist laugh when they hear computer people talk about archiving. Twenty five years seems like forever in the computer world whereas one hundred years is short term thinking for most archivists.

[__archiben]

Pete wrote:
We've resorted to breaking up the layout books into smaller ones. Does anyone have any hints on whoe to streamline this a bit??

pete

breaking the project book down into smaller ones will not necessarily save you space on the server - although i guess it will help retrospect back up only those smaller books that have changed since the last backup.

the way i understand it, plotmaker saves the most recently imported data from archiCAD into the plotmaker file by default (you can have this data saved as a cache file into a folder of your choice too).

all of this archiCAD data comes from your viewsets, right? now, without knowing how you set up your archiCAD viewset structure i can only comment on our experience:

traditionally, we have set our (quickviews->)viewsets up by drawing number so that a drawing can be found quickly and worked on. what this means is that on a big job you could potentially have a LOT of different views saved that all contain the same information! i.e. same layer combination, display combination and scale, etc..

plotmaker will then load each identical view and save that in the data cache with the layout book, resulting in disastrously large files! unfortunately, we haven't yet done anything about reviewing how we should tackle this as a practice, but luckily our layout books are already broken down into smaller ones simply because we need the ability to have more than one person work on drawing output at the same time. (don't forget that if you also use this method you will no longer be able to efficiently use <plotmaker> automatic section and detail referencing . . .)

i have begun to set up some 'drafting only'/'plotmaker only' views within our viewsets so that we can quickly find drawing content whilst drafting, but so that plotmaker only takes one view for x number of drawings in the layout book. this is contrary to my own better judgement - i really do hate duplicating anything unnecessarily - and relies on manual (read:human) understanding of the principle behind it.

i do remember something that matthew once wrote about viewset structure - quite possibly stemming from an entirely unrelated topic - but i've been unable to find it. (it may well have been at the archiCAD university in nottingham last year also . . . my memory is not what it used to be )

~/archiben

[SeaGeoff]

Currently I've decided to not imbed the files into the .lbk and instead go the cache folder route. The .lbk for a current permit set is less than 3MB. You might give this a try and see how Retrospect reacts. PM erroneously acts like all the views from a given AC file are in need of update if any changes have been made to that file. But Retrospect will likely get it right if the cached .pmks reflect only actual changes. That is, if you update views in PM only as they change, as opposed to updating the entire book, then the cached .pmks representing unmodified view will not be overwritten by PM and therefore will not be re-backed-up. I haven't examined our back-up to confirm this, so check it out for yourself.