Backups
In order to make a full backup of your data, you'll need to take a copy of the CodeBook project database(s) and also the library files (equipment + room data). As a general rule of thumb it's a good idea to take a backup of your files on a weekly basis and at each project milestone, but it's worth speaking to your IT department to find out how often they run a full studio backup. Typically this is carried out monthly and a backup tape stored locally as well as off site. Larger practices may do this on a weekly basis, but whatever the frequency this will inform the amount of backup files you should keep on your server at any time. If your practice take monthly backups and you are also taking weekly backups, you should only ever need to keep 1 months worth of live backups on your server at any time. The rest can be retrieved from the backup tapes your IT department have taken.
Over the years, I've rarely reverted to a backup file older than one month, as typically the design has moved on substantially during that time meaning you'd lose more than you'd gain. If you take weekly backups and don't delete any of these till the project is over, you could end up with a large amount of unnecessary data stored on your server. That data will also be backed up monthly in the studio backup and so the issue manifests exponentially. The CodeBook data alone won't cause problems, but having a sensible approach towards backups is critical when working in a team environment - if everyone is taking more backups than they really need and never purging these from the server, it is inevitable that you will run into problems at some point.
For large projects you may have a series of staggered milestones and there may be a timeframe of longer than one month between them. This is where milestone image database should be utilized.
Images of the past...
An image database is a single consolidated database which merges the project, equipment and room data files to provide a snapshot of the data at a specific moment in time. If you create image databases at each project milestone, you're able to generate a revision database, which compares milestone image 1 with milestone image 2. The reports that you can generate from a Revision database highlight the differences between the two milestone images.
This can be a very powerful tool if used correctly and can aid with your in-house QA checking. Often clients want validation that their comments (from a previous meeting) have been taken on board, so providing that all of the clients comments have indeed been made, you're able to create a report which demonstrates this.
Generating an image database is quite a simple process, from the Control Centre select Output>Create Image Database... and you'll then be asked to confirm the location where the file will be saved. (In Project Properties you can specify the default location for this) A window will pop up asking you to add a note, which will act as a future reminder. It's obvious right now why you are creating the image database, but may not be 100% clear in the future, especially if you are working on a large project. Speaking from personal experience, clear notes are valuable and will help ensure you can locate the right image database in future and reduce the chances for error.
One very important thing to consider is precisely when you create the image database. If you create the image before producing reports and schedules, there is the chance that "last minute changes" could be made (having reviewed the reports) and your image does not fully reflect the issued set of documents. Similarly if you leave it till a few days after the issue has been made, again there may be differences between the issued set of information and the image you have generated.
The right time to create the image is straight after your reports have been generated and in conjunction with this, you should also be mindful of what other users may be working on. If another user is editing the project, equipment or room data library this may affect your image database. The key thing is communication and it should be possible to organize the production of reports and image databases to happen when the rest of the team are not editing the CodeBook data - or perhaps vice versa, the team are aware when this is happening and that they should not be editing CodeBook data.
The default CodeBook filename used for images includes the current date and time, it's advisable to keep this but to also include the project, sector and/or department the image relates to. This will be useful later on when you want to create a revision database and need to find the right image file to use.
Revision databases
An image database cannot be opened directly in CodeBook per se, it's purpose is to provide a point of comparison - so the way that you access the image information is to create a revision database. The process for creatng a revisions database is straightforward, from the Output menu simply select Create Revision Database and a pop up window will prompt you to specify the latest image and comparison image database. The latest image database should automatically be filled in with details of the last one you created, the comparison image should be the project/sector/department image database you created at the previous project milestone.
So give it a go, explore the Revision database reports that are available and start getting real value out of your data.
