Moving a Perforce server to a new machine

How you move an existing Perforce server from one machine to another depends on the following factors:

  • whether the machines use the same byte order
  • whether the machines use different byte ordering, but the same text file (CR/LF) format
  • whether the machines use different byte order and a different text file format.

Additional considerations apply if the new machine has a different IP address/hostname.

The Perforce server stores two types of data under the Perforce root directory: versioned files and a database containing metadata describing those files. Your versioned files are the ones created and maintained by your users, and your database is a set of Perforce-maintained binary files holding the history and present state of the versioned files. In order to move a Perforce server to a new machine, both the versioned files and the database must be successfully migrated from the old machine to the new machine.

For more about the distinction between versioned files and database, as well as for an overview of backup and restore procedures in general, see “Backup and Recovery”.

For more information, see "Moving a Perforce Server" in the Perforce knowledge base:

http://answers.perforce.com/articles/KB_Article/Moving-a-Perforce-Server

Moving between machines of the same byte order

If the architecture of the two machines uses the same byte order (for example, SPARC/SPARC, x86/x86, or even 32-bit Windows to 64-bit Windows), the versioned files and database can be copied directly between the machines, and you only need to move the server root directory tree to the new machine. You can use tar, cp, xcopy.exe, or any other method. Copy everything in and under the P4ROOT directory - the db.* files (your database) as well as the depot subdirectories (your versioned files).

  1. Back up your server (including a p4 verify before the backup) and take a checkpoint.
  2. On the old machine, stop p4d.
  3. Copy the contents of your old server root (P4ROOT) and all its subdirectories on the old machine into the new server root directory on the new machine.
  4. Start p4d on the new machine with the desired flags.
  5. Run p4 verify on the new machine to ensure that the database and your versioned files were transferred correctly to the new machine.

(Although the backup, checkpoint, and subsequent p4 verify are not strictly necessary, it’s always good practice to verify, checkpoint, and back up your system before any migration and to perform a subsequent verification after the migration.)

Moving between different byte orders that use the same text format

If the internal data representation (big-endian vs. little-endian) convention differs between the two machines (for example, Linux-on-x86/SPARC), but their operating systems use the same CR/LF text file conventions, you can still simply move the server root directory tree to the new machine.

Although the versioned files are portable across architectures, the database, as stored in the db.* files, is not. To transfer the database, you will need to create a checkpoint of your Perforce server on the old machine and use that checkpoint to re-create the database on the new machine. The checkpoint is a text file that can be read by a Perforce server on any architecture. For more details, see Creating a checkpoint.

After you create the checkpoint, you can use tar, cp, xcopy.exe, or any other method to copy the checkpoint file and the depot directories to the new machine. (You don’t need to copy the db.* files, because they will be re-created from the checkpoint you took.)

  1. On the old machine, use p4 verify to ensure that the database is in a consistent state.
  2. On the old machine, stop p4d.

  3. On the old machine, create a checkpoint:

    p4d -jc checkpointfile

  4. Copy the contents of your old server root (P4ROOT) and all its subdirectories on the old machine into the new server root directory on the new machine.

    (To be precise, you don’t need to copy the db.* files, just the checkpoint and the depot subdirectories. The db.* files will be re-created from the checkpoint. If it’s more convenient to copy everything, then copy everything.)

  5. On the new machine, if you copied the db.* files, be sure to remove them from the new P4ROOT before continuing.

  6. Re-create a new set of db.* files suitable for your new machine’s architecture from the checkpoint you created:

    p4d -jr checkpointfile

  7. Start p4d on the new machine with the desired flags.
  8. Run p4 verify on the new machine to ensure that the database and your versioned files were transferred correctly to the new machine.

Moving between Windows and UNIX

In this case, both the architecture of the system and the CR/LF text file convention may be different. You still have to create a checkpoint, copy it, and re-create the database on the new platform, but when you move the depot subdirectories containing your versioned files, you also have to address the issue of the differing linefeed convention between the two platforms.

Depot subdirectories can contain both text and binary files. The text files (in RCS format, ending with ",v") and binary files (directories of individual binary files, each directory ending with ",d") need to be transferred in different ways in order to translate the line endings on the text files while leaving the binary files unchanged.

As with all other migrations, be sure to run p4 verify after your migration.

Warning

Windows is a case-insensitive operating system. Files that differ by case only on a UNIX server will occupy the same namespace when transferred to a Windows machine. For instance, files Makefile and file makefile on a UNIX server will appear to be the same file on a Windows machine.

Due to the risk of data loss due to case collision, migrations from UNIX servers to Windows are not supported.

Contact Perforce Technical Support for assistance when migrating a Perforce server from Windows to UNIX.

Changing the IP address of your server

If the IP address of the new machine is not the same as that of the old machine, you will need to update any IP-address-based protections in your protections table. See Authorizing access for information on setting protections for your Perforce server.

If you are a licensed Perforce customer, you will also need a new license file to reflect the server’s new IP address. Contact Perforce Technical Support to obtain an updated license.

Changing the hostname of your server

If the hostname of the new machine serving Perforce is different from that of its predecessor, your users must change their P4PORT settings. If the old machine is being retired or renamed, consider setting an alias for the new machine to match that of the old machine, so that your users won’t have to change their P4PORT settings.