Perforce Public Knowledge Base - Archiving Depot Content Off-line
Reset Search
 

 

Article

Archiving Depot Content Off-line

« Go Back

Information

 
Problem

How do I remove old data from my Perforce server and store it off-line?

How do I export the contents of a specific depot branch?

Solution

Creating an archive server


To archive a section of a Perforce Server, do the following:
  1. Obtain a license for the new archive server
Fill out the Duplicate Server Request.
 
.
  1. Copy the entire Perforce Server to a new archive server. 
Either stop the production server and copy the files over, or take a checkpoint and copy the checkpoint and versioned files over.  Make sure your archive server is the same version as your production server.  Old versions of Perforce can be obtained from
ftp://ftp.perforce.com/perforce/
Steps to copy a server are documented in Moving a Helix Server.
 
  1. Start the archive server.
 
  1. Obliterate everything on that archive server that you do not need.
 
  1. Obliterate the archived files on the production server

The result is a new server that contains only the content that you want archived.

To reiterate, archiving requires creating a duplicate copy of your server and then obliterating everything from that archive server that you do not want, leaving you with just the content that you do want.

The most important part of the archiving process is determining which files to obliterate. An efficient method of selecting files to obliterate is by creating a special client workspace dedicated to this purpose.
 

Speeding up obliterate


For example, on the newly created archive server, to archive the "//depot/OldStuff/..." section of the depot, create a client workspace, such as "archive-tmp" below, with a View that maps the entire depot. Then use exclusionary View mappings to exclude the files you wish to save (archive):
 
Client: archive-tmp
View:
   //depot/... //archive-tmp/...
  -//depot/OldStuff/... //archive-tmp/OldStuff/...

Then on the archive server you can obliterate everything you do not need by providing the entire client workspace as an argument to the p4 obliterate command.
For  example:
 
p4 snap //... //archive-tmp/...
p4 obliterate //archive-tmp/...
p4 obliterate -y //archive-tmp/...

Likewise, on the production server, you can obliterate the now archived data.
 
p4 snap //... //depot/OldStuff
p4 obliterate //oldStuff/...
p4 obliterate -y //oldStuff/...

This "depot copy and obliterate" approach to archiving is also discussed in "Making Large Depots Smaller".



Restoring the archive server


Once you have copied your original server content to an archive server instance, you take a checkpoint of the archive server, compress the depot file contents, and store the checkpoint and depot files on a backup medium.

If you need to recover the archived Perforce Server content for future use, you can rebuild the archive server from checkpoint, restore the compressed depot files, and restart the archive server to browse and use it.

The p4 obliterate command can permanently remove contents from your Perforce Server based on depot path, date, or a combination of both. For details on usage, see the Perforce Command Reference.
 

Notes:

  • The above offline archiving solution is simple and effective, but can also be resource and time intensive. You need enough disk space to duplicate the entire contents of the original server.
     
  • If necessary, you do not need to copy over all the subfolders in the server root - just the ones necessary for the archived files.  For example, if you want to archive the branch //depot/branchX/..., then it is not necessary to copy over all the subfolders of $P4ROOT/depot, just the folder $P4ROOT/depot/branchX.  Before you do this, however, you need to resolve the lazy copies in //depot/branchX/...  This is done using the p4 snap command. For example, run:
    p4 snap //depot/branchX/...
    
    For more information about p4 snap, run:
    p4 help snap
  • You might want to modify your production server protections table to prevent write access to the obliterated directory name. For example, to prevent anyone from adding the "OldStuff" directory, you can add a line to your protections table similar to this:
    write user * * -//depot/OldStuff/...
    This modification can make it easier to merge the archived data back into the production Perforce server by preventing naming conflicts.
     
  • You might want to restore your Perforce server database after a large obliterate. This can reduce fragmentation in the Perforce metadata, which can improve performance. More information on restoring the Perforce server database can be found in the Perforce System Administrator's Guide.
 
Related Links
Making Large Depots Smaller
KB articlePerforce Command Reference
Documentationp4 obliterate
Perforce Command Reference

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255