28 September 2017
A Guide to P6 Archiving - Part 2
Archiving P6 Project Data and the Question of Location
This is part 2 of a series of blogs discussing best practices of P6 archiving. In Part 1 we discussed the question of time:
- How long should you keep a P6 project file?
- How do you track the date to archive your P6 project?
Now we will discuss the question of location.
Where to archive your P6 project data?
Clients used to want to remove projects ASAP from the active database to save on storage space, but today the costs of storage have dropped dramatically. The risks of multiple XER files kicking around your network (usually in someone's personal drive) and potentially being lost may outweigh the costs of keeping the P6 project in your current database.
So, the options are:
- XER/XML flat file backup of the archived projects - stored in an appropriate place
- Store the archived files in your existing P6 database, perhaps in a new EPS node
- Store the archived files in a dedicated archive database
Let’s look at how they stack up:
|Option||Storage Cost||Risk of Data Loss||Future Compatibility Risk||Recovery Time|
|XER/XML File Export||H||H||H||H|
|Archive in Live DB||M||L||L||L|
|Archive in Dedicted DB||L||L||L||M|
XER/XML backup – this has been the go-to solution for Primavera schedulers for decades. They'd export their current files from the database and save the resulting files on a portable drive, local machine, cloud drive or a network drive. There are a number of issues with this approach:
The files are very inefficiently stored – all of the project information is duplicated in every file. This is required to make the files portable between databases. This means that even global data such as activity codes and resources has to be included in every file as compared to normalized database storage where data is captured only once. Most of our clients have recovered from the POBS virus which made XER files grow outrageously.
For the same reason, these files can actually pollute the current database by bringing in obsolete codes, calendars, etc.
These files can often be hard to locate – shares get deleted, portable drives get lost, computers get replaced or personal cloud accounts don’t get renewed.
Restoring files can be problematic – Primavera occasionally changes their import file formats and the version that you exported the file in may no longer be supported when you need it. For example, the newer versions of P6-web do not support the XER format that schedulers have used for decades.
Importing the files is tedious and time consuming, particularly if the files are poorly labelled. In particular, Primavera XML files are brutally slow to import, much slower than XER files (and the files are much larger).
Archive in Live Database – this is the easiest approach; you add some EPS nodes for Archived Projects and move the projects to those nodes. They are always available, always backed up and always on the current version of Primavera. The downside is that your database is always storing data that is rarely used. However, as database engines become more and more powerful and storage becomes cheaper and cheaper, this is a viable solution. This is also the best solution when your data is in the the Cloud, because the cost of adding additional databases for archiving is usually more expensive than the additional cost of more disk space. It is worth checking the relative costs, though - often there are hidden costs in cloud storage.
Archive in a Dedicated Archive Database – this approach is quite popular with clients who have large numbers of databases located in house. The archive database can be stored on a non-HA server, with less frequent backups since the data doesn’t change that often.
When a project is ready to be archived, someone can export it from the production database and import it into the archive database. The archive has the same advantages as the live database option in that it’s always available, always backed up and always on the current version of Primavera. The downside is the export/import process is tedious and in the real world, so moving the projects from Production to Archive often just doesn’t get done.
So what's the best solution?
Creating an Archive EPS node in your production system is the easiest to implement and probably the cheapest solution in the long run, particularly if you are in the cloud.
A dedicated archive server is a good alternative for a large organization with their databases in house and a Primavera administrator who will move projects when their archive date is reached.
The flat file (XER/XML) backups are the least desirable.