No matter how carefully a schedule is built, it is only as safe as the data behind it. A construction programme can represent months of effort: activity logic, resource assignments, cost loads, baselines, and the revisions agreed in countless progress meetings. Losing that data to a failed drive, a corrupted database, or a botched global update can set a project back weeks. Primavera P6 gives planners the tools to protect that data, but the terminology can be confusing. What is the difference between a backup and a Save As? Where do backup files go? How do you automate backups and restore a project? This article is a complete introduction to project backup in Primavera P6, covering each method, the file formats involved, restoration, database maintenance, and the habits that keep project data safe.
Understanding How Primavera P6 Stores Project Data
Before discussing backup techniques, it helps to understand how P6 stores data, because the storage model determines what a backup means in practice. P6 Professional is the desktop application used by planners and schedulers, and it runs in two modes. In standalone mode it uses a single-file SQLite database called the PMDB that holds every project and global setting on the local machine. Because everything lives in one file, backing up is simple: copy the file. In shared mode, P6 Professional connects to an Oracle or Microsoft SQL Server database, where projects are stored in tables alongside the global data shared by the whole organisation.
The second form, P6 EPPM, is the web-based enterprise edition, storing its data in an Oracle or SQL Server database and managed by administrators. The practical consequence is that backup strategy differs by deployment: a standalone user can protect everything by copying one database file, while teams on a shared database need both project-level backups and full database backups taken by the IT or database administration team.
Backup versus Save As: What Is the Difference?
One of the most common misunderstandings in Primavera P6 is treating Save As as a backup. The two operations serve very different purposes, and confusing them creates a false sense of security. Both appear in the same File menu, yet only one protects you from data loss.
Save As: Duplicating a Project Inside the Database
When you choose Save As in P6 Professional, the application creates a second version of the open project inside the same database, under a new Project ID and name. The original is left untouched, and the duplicate is an exact working copy you can edit freely. This is ideal for what-if scenarios, alternative recovery strategies, or programme variants for different bids. However, Save As is not a backup in any meaningful sense: both copies live in the same database, usually on the same disk, and if that database is corrupted or destroyed, the original and the duplicate are lost together. Save As protects you from your own edits; it does not protect you from hardware failure, corruption, or disaster.
Backup: Creating a Portable Snapshot
A genuine backup, by contrast, exports data to a file that is independent of the live database. In P6 Professional, choose Save As and then the Backup option from the File menu to write a .bak file. In standalone mode, the .bak contains the entire PMDB database, including every project and all global data. In shared mode, it is a project-level backup containing the open project and its associated data, but not the global data held elsewhere in the database. This is the file you copy to a network drive, a portable disk, or the cloud, and restore from even if the original database no longer exists. Rule of thumb: use Save As for a working duplicate, and Backup whenever you need data that survives the loss of the system itself.
Primavera P6 Backup File Types and Locations
Where backup files are written matters, because a backup on the same drive as the database it protects has limited value. The default locations depend on the deployment mode, and in every case the files should be moved or copied to a safer destination as part of a routine.
.bak Files and Where They Are Stored
In standalone P6 Professional, .bak files are written by default to the same folder that holds the PMDB database, typically the PMDB directory inside the installation folder. Because this is usually the local drive, a backup created there offers no protection against a disk failure, and Oracle recommends copying these files off the local computer on a regular basis. In shared mode you choose the location when the backup is created, and many organisations standardise on a network folder for central management. Whichever mode you use, adopt a naming convention that includes the project ID and date, such as ProjectName_20260819.bak, so older snapshots are easy to identify.
.xer and .xml Exchange Files
It is also worth understanding the difference between backup files and exchange files. The .xer format is Primavera’s plain-text exchange format, and .xml is its newer XML-based counterpart. Both are created through the Export command and are designed to move project data between systems, versions of P6, or an organisation and its contractors. They are compact and extremely useful for data exchange, but they are not true backups. An .xer or .xml export captures activities, relationships, resources, and calendars, but not everything held in a full database: global data such as the EPS, OBS, security profiles, and some user-defined fields live outside the project file entirely. Use exchange files for sharing and migrating data, but never rely on them as the only copy of a schedule.
Scheduling Automatic Backups
Manual backups are forgotten under deadline pressure, so every serious backup strategy includes an automated component. The options available depend on how P6 is installed.
Automatic Backups in P6 Professional (Standalone)
For standalone installations, P6 Professional includes a built-in automatic backup feature. Open the P6 Professional Options dialog from the Tools menu and go to the General tab, where you can enable automatic backup, set the frequency in minutes, and choose the destination folder. A sensible setting for an active user is an automatic backup every hour during the working day, plus a manual .bak file at the end of each day, copied to a network drive. Remember that automatic backups are still written locally, so the folder you choose should itself be swept by a file-level backup on a schedule.
Database-Level Backup Schedules for Shared Installations
In shared and EPPM environments, the built-in automatic backup applies to individual projects, while the safety of the whole system depends on database-level backups managed with the native tools of the underlying platform. For Oracle this typically means RMAN jobs or Data Pump exports; for SQL Server, maintenance plans or Agent jobs performing full and transaction log backups. A common pattern is a nightly full backup with more frequent log backups, a weekly copy of the backup files to an off-site or cloud location, and a retention policy that keeps daily, weekly, and monthly restore points. Project-level backups by planners complement these: they let the planning team recover a single project quickly without involving the database team, while database backups protect global data, security settings, and the entire system in one operation.
Restoring Projects from Backups
A backup strategy is only complete when the restore process has been tested and documented. Restoring in P6 depends on the kind of backup you are working from, so it is worth rehearsing each scenario.
Restoring a Project from a .bak File
In P6 Professional shared mode, a project-level .bak file can be opened directly through the File menu; P6 reads the snapshot and brings the project back into the database. In standalone mode the same approach works, and because the .bak contains the whole PMDB you can also recover the entire environment by replacing the current PMDB file with the backup copy. Before doing so, rename or move the existing file in case you need to return to it, and make sure P6 is closed while the file is replaced. Whichever mode you are in, open the restored project and check key indicators: activity counts, the data date, baseline names, and a few known activity IDs. A backup that opens cleanly but contains stale data is still a problem, so verify rather than assume.
Restoring the Whole Database
When the database itself is lost or corrupted, the restore happens at the database level with the native tools of Oracle or SQL Server. The database administrator restores the latest full backup, applies any log or archive backups taken since, and brings P6 back online. This requires downtime, which is why the schedule of full and incremental backups matters: the more frequent the log backups, the less work is lost. Note also that database backups are tied to the platform version they were created with, so restoring to a different server usually requires the same or a newer database version, and the P6 application version must match the database schema. This is exactly the scenario that should be rehearsed, not discovered, during a crisis.
Recovering Data from Exchange Files
If no .bak file or database backup exists, an .xer or .xml export may be the only lifeline. Import the file and review the import log carefully for warnings, because data such as assignments tied to missing resources may not import as expected. Exchange files also do not carry global data, so codes, calendars, and resource dictionaries may need to be recreated or imported separately. Treat this as a recovery of last resort: it can rebuild the skeleton of a schedule, but it is not a substitute for a proper backup routine.
Database Maintenance for Long-Term Data Safety
Backups protect data against loss, but they do not keep the database healthy, and a healthy database is the first line of defence. Regular maintenance reduces the risk of corruption. At the database level this means scheduled integrity checks, such as DBCC CHECKDB on SQL Server or equivalent verification on Oracle, plus index maintenance and statistics updates as tables grow. At the application level it means archiving completed projects that are no longer active, monitoring database and disk growth, and keeping an eye on the largest tables, typically the activity and resource assignment tables on busy programmes. Maintenance also extends to the backup files themselves: confirm that backup jobs complete successfully, that the destination has free space, and that old backups are pruned according to the retention policy. Finally, remember that global data, including the EPS, OBS, calendars, resources, roles, and security profiles, exists only at the database level in shared installations. A planner’s project .bak does not contain it, so the database-level backup is the only complete safety net for the organisation’s standards and structure.
Best Practices for Project Data Safety
Bringing all of this together, the following practices form a practical checklist for keeping Primavera P6 project data safe:
- Follow the 3-2-1 rule: three copies of the data, on two types of media, with at least one copy off-site.
- Never rely on Save As as a backup; use .bak files or database backups for protection.
- Move backup files off the machine that runs P6 and ideally off the site, so a single disk failure cannot destroy both the data and its backup.
- Automate backups wherever possible, through P6’s automatic backup feature or through database backup jobs.
- Back up before major operations such as baseline updates, mass changes, imports, or upgrades, so there is a known good restore point.
- Use a clear naming convention and a retention policy covering daily, weekly, and monthly restore points.
- Test restores regularly, and rehearse a full database restore at least once, because an untested backup is only a hope.
- Verify restored data by checking activity counts, dates, and baselines before announcing that a recovery has succeeded.
- Coordinate with IT so P6 backups, server backups, and off-site storage are aligned and documented.
- Restrict backup and restore permissions to trained staff, and keep a written recovery runbook.
Conclusion
Making project backups in Primavera P6 is not a single task but a routine that combines the right tools with the right habits. Save As gives you working duplicates inside the database, while .bak files provide portable snapshots that survive the loss of the system itself; .xer and .xml files are for sharing data, not for real backups. Standalone users can automate protection with P6’s built-in automatic backup, while shared installations depend on disciplined database-level backups managed by the IT team. The restore side deserves as much attention as the backup side, because a recovery procedure that has never been tested is not a procedure at all. Add regular database maintenance and simple habits, such as the 3-2-1 rule and backing up before major changes, and the planning team can be confident that months of careful scheduling will survive the accidents every project eventually encounters. Backups are cheap; re-creating a lost programme is not.