Move between machines of the same byte order

If the IP address of the new machine is different from the old machine and the Helix Core Server license is current, obtain a new license file to reflect the new IP address.

Fill out a Change of Server Request.

Install the Helix Core Server software on the new machine. Use the same release on the new machine as on the old machine. However, we recommend that you to use the latest patch of that release from the download page for Helix Core (P4D) Server.

By default, depots that contain the versioned files Source files stored in the depot, including one or more revisions to each file. Also known as archive files, archives, and depot files. Versioned files typically use the naming convention 'filename,v' or '1.changelist.gz'. that the server manages are located relative to the P4ROOT directory. To see the location of the root directory, run p4 info and look at the value for Server root.

Depots might be located elsewhere, so do the following:

1. Run p4 configure show server.depot.root

   If a path is shown, make sure that the depots locations are relative to that path.

2. Get the list of depots by running the p4 depots command.

3. For each depot listed, run the p4 depot -o depotName command.
   

4. Look at the Map field for the location of the depot versioned files.

5. Make sure that all relevant file systems are mounted.

6. Check for any symlinks that might correspond with depot paths.

Make sure that there are no missing or corrupted versioned files.

1. Make sure that the command syntax for your operating system console or shell captures standard error (stderr) to the output file.

2. Run the p4 verify command on the old server:
   p4 verify -q //... > verify.errors 2>&1

3. If you use shelving:

   p4 verify -q -S //... > verify.shelf.errors 2>&1

4. If you unload data, such as clients and labels:

   p4 verify -q -U //... > verify.unload.errors 2>&1

5. If you use an archive depot to archive file revisions:

   p4 verify -q -A //... > verify.archive.errors 2>&1

6. Examine the output files.

   If the files are empty, no errors were found.

   If any errors are listed, see How to Handle p4 verify BAD Errors and MISSING! errors from p4 verify at the Perforce Support Center.

To provide signatures for any files that do not already have them, on the old server, run the following command:

p4 verify -qu //... > verify.update 2>&1

This allows all revisions of all files to be verified by using p4 verify after the move in Step 11.

Copy over the versioned files from the old machine to the directory on the new machine. Files and directories can be moved using rsync, tar, ftp, a network copy, or any other method that preserves the files as they were on the old server.

On Unix servers

Run rsync (or the equivalent).

cd old-server-P4ROOT
rsync -avz ./depot perforce@gabriel:/home/perforce

where ./depot is one of the directories to be copied on the old server, perforce@gabriel would be replaced with the user and hostname of the new server, and /home/perforce is the root directory on the new server.

Copy over all the versioned file directories.

Note the following:

• Any directory size differences on the new server versus the old server are explained in the third-party post, #rsync FAQ.

• It is possible to copy most of the files before the server move, then update the versioned files later. To update the versioned files, run the same rsync command. The rsync flags used by this command will only transfer files updated since the command was last run.

On Windows servers

Run xcopy (or the equivalent):

cd old-server-P4ROOT
cd depot
xcopy *.* S:\perforce /s /d /c /e /i /h /y

where S:\perforce represents the network drive that contains the corresponding directory on the new server. Copy over all the versioned file directories.

1. On the old machine, take a checkpoint A backup copy of the underlying metadata at a particular moment in time. A checkpoint can recreate db.user, db.protect, and other db.* files. See also metadata.. The checkpoint creates a checkpoint file, checkpoint.n, along with an associated checkpoint.n.md5 file that can be used to validate the checkpoint file. The checkpoint file will be used to rebuild the database (db.* files) in the P4ROOT directory on the new machine. Creating and restoring a checkpoint provides a rudimentary validation of the database. To learn more, see Checkpoint files.

To take a checkpoint, run this command on the old machine:

cd old-server-P4ROOT
p4d -r old-server-P4ROOT -J D:\perforce\journal -jc

where D:\perforce\journal represents the directory path and name of the journal.

After the checkpoint operation completes successfully, copy the checkpoint file from the old server to the P4ROOT directory on the new server.

2. Before restoring a checkpoint, on the new machine, erase any existing db.* files, as well as any *.lbr files, any journal or log, any state file, and the server.locks directory.

On UNIX, open a terminal window and restore the checkpoint using:

cd new-server-P4ROOT
rm db.*
rm *.lbr
rm -r server.locks
p4d -r new-server-P4ROOT -jr checkpoint

On Windows, open a command prompt and restore the checkpoint using:

cd new-server-P4ROOT
erase db.*
erase *.lbr
rmdir /s server.locks
p4d -r new-server-P4ROOT -jr checkpoint

3. If you use LDAP or Active Directory, copy the ldap directory from the master to the replica.

This step is optional, but recommended to prevent unwanted connections while performing work on the new server.

Use localhost for the P4PORT setting when starting the server. This will deny remote connections while allowing access from the server host itself. Alternatively, start the server on a non-standard port such as 1234

For example, open a command prompt and run:

p4d -r new-server-P4ROOT -p localhost:1234

or

p4d -r new-server-P4ROOT -p 1234

This will start the server listening for network connections. Be aware that the command prompt will not return. See Start the Helix Core Server and Configure the server.

In a separate command prompt, check that that the most recent dates, times, and changelist numbers submitted to the old server are present on the new machine by running this command:

p4 -p localhost:1234 changes -t -m 10

Check whether the P4ROOT, P4LOG, and P4JOURNAL variables on the old server have the default values.

If not, follow the instructions of Moving Helix Core Server Components on the Same Machine at the Perforce Support Center.

Stop and restart the new server using the production host and port number to allow full access.

1. To stop the server, run the p4 admin stop command.

• On Unix, start the server using startup scripts copied over from the old server.

• On Windows, start the server under Services.

2. Stop the old server.

3. Change the port number on the old server so users will not accidentally connect to the wrong server. For example,
p4 set -S Perforce P4PORT=1234

Check for the following to see if any need to be updated, migrated, and tested:

• Custom triggers - Check for any changes in executable and script paths and dependencies, such as the version of Perl or derived APIs, such as P4Perl.

• Daemons - Check daemons, such as the review daemon or p4thumb.

• Cron jobs or scheduled tasks - Check automated backup or checkpointing scripts.

• Startup Scripts - Check Helix Core Server startup scripts.

• Anti-virus software and backup scripts - Make sure to exclude the database (db.*) and versioned files directories.

• Other servers - Change Helix Proxy servers, Replica servers, P4Broker servers, P4DTG servers, and so on to point to the new server. This will include modifying the P4TARGET and re-logging service users into the master server.

• DNS IP adddresses and reverse DNS entries - If the name server name or alias name of the new machine is different, users will likely need to change their P4PORT settings to point to the new-server:port

  Helix Core client software defaults to connecting to a server named perforce at port 1666. So, if the Helix Core Server is run on the default port of 1666 with a name service alias for the machine running the server set to perforce, users never need to set P4PORT. In that case, when changing the machine running the Helix Core Server, have the IT department update the company name server (DNS) and reverse DNS entries so that the name record perforce refers to the new machine rather than the old.