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 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 original 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, check for the depots being 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. Check 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. Check 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 original 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 original server, run the following command:

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

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

Copy over the versioned files. 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 original server.

On Unix servers

Run rsync (or the equivalent).

cd <Perforce original root>
rsync -avz ./depot perforce@gabriel:/home/perforce

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

Copy over all the versioned file directories.

Note the following:

• Any directory size differences on the target versus the original 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 <Perforce original root>
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.

Note the following:

• It is possible to copy most of the files earlier, then update the versioned files later using the /d or /d:mm-dd-yyyy flags and arguments.

• To find out more about the xcopy command, see the Microsoft xcopy article.

Note that the original db.* files should remain on the old server for safekeeping.

1. On the new machine, rebuild the database (db.*) files in in the P4ROOT directory. The creation and restore of a checkpoint provides a rudimentary check of the database and also re-balances the database for better performance. See Checkpoints for database tree rebalancing.

To take a checkpoint, run the command:

cd <old server P4ROOT>
p4d -r 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 original 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 original 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 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 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.