Reclaim disk space with an archive depot

Over time, P4 Server can accumulate many revisions of files. Some files might be from projects that are no longer active. Therefore, you might want to reclaim the disk space. One way is by transferring those versioned files into an archive depot A special depot into which versioned files (also known as archive files) can be transferred. See also 'depot'.. Archive depots free up disk space by moving files that are rarely accessed to bulk storage.

The actual file content held in the P4 Server depots is often referred to as an archive file Versioned files that users submitted to a depot., no matter what the depot type is. An archive depot is used to store obsolete or little used file content (archive files) to free up disk space in other depots on the system. To learn about depot types, see p4 depot in the P4 CLI Reference.

Compare the advantages of using an archive depot and p4 archive to the p4 delete and p4 obliterate commands:

p4 delete	p4 archive	p4 obliterate
No disk space reclaimed. File history is preserved and "deleted" files can be restored, Merely marks files as deleted at the head revision.	Disk space reclaimed on the storage used for your local depot. Files moved into the archive depot on the central server The one server that is innermost in a multi-server deployment. In the server specification form field for Services, the central server might be specified as “standard” or “commit-server”. If edge servers are part of the multi-server deployment, the central server must be a commit server. See also 'upstream server'., not on replica servers. File history is preserved and archived files can be restored.	Disk space reclaimed. Obliterated files cannot be restored. Permanently removes file and its history.

Task streams must be unloaded with the p4 unload command prior to the task stream file revisions being archived to an archive depot.

Transferring versioned files to an archive depot is not allowed if the files are in a remote depot or are already in an archive depot.

In a commit-edge environment, the archive depot is not replicated between the commit server The innermost P4 Server server in a topology with one or more edge servers. and the edge servers A server that is part of a commit-edge environment that can independently support work in progress for locally-bound clients, thereby reducing the load on the commit server..

When lazy copies A method to conserve disk space by referencing files instead of duplicating their content. are copied into the archive depot, the archive depot will contain the full content of the source file until the lazy copy is restored from the archive depot back into the original depot. Archive depot disk usage might therefore be higher than expected. To learn more, see Criteria with -z in P4 CLI Reference.

Transfer files into an archive depot

Create a new depot by using the p4 depot command.
```
p4 depot -t archive ArchiveDepot
```
where ArchiveDepot is the name for your new depot of type archive.
Set the archive depot’s Map field to an absolute path where the archived files will be stored. The path can be locally mounted network storage, detachable storage, or a mounted block storage device for the Cloud. If you are using S3 storage, see S3 storage for archive depots.
To transfer all unbranched binary files to the archive depot from your existing depot:
```
p4 archive -D ArchiveDepot //LocalDepot/...
```
where LocalDepot is the name of your standard depot of type local.
Binary files, compressed and uncompressed, are the default file types that p4 archive transfers. You might want to adjust the behavior of the command, so consider its Options, such as -t to make p4 archive transfer text files. To learn more, see File type modifiers in the P4 CLI Reference.
(Optional) Unmount the volume to which the LocalDepot archive files were written, and store it in a secure location.

Restore files from an archive depot

Mount the volume on which the archive depot’s files are stored.
Make sure that the path matches the Map field of the archive depot.
Use the p4 verify -A command to verify files before you restore them.
For example, p4 verify -A //ArchiveDepotName/... checks for corrupt or missing files.
Files archived into this depot have their original path but with the depot name.
For example, //ArchiveDepotName/LocalDepot/Mainline/... includes the LocalDepot from which the files were transferred to the archive depot.
Use p4 restore to transfer the files from the archive depot to the original local depot.
```
p4 restore -D ArchiveDepotName //LocalDepot/...
```
(Optional) Unmount the volume from which the archive files were restored.

Purge files from an archive depot

If you purge files from an archive depot, they are permanently deleted.

Mount the volume on which the archive depot files are stored.
If you want P4 Server to retain the metadata Information that P4 Server maintains, such as who created file revisions in the depot, whether the file is a 'lazy copy,, the current state of client workspaces, protections, groups, users, labels, streams, and branches. Metadata is stored in the server database and is separate from the 'archive files' that users submit from their client workspace into the depot. of the files you are going to purge, see the -p option of the p4 archive command.
Use p4 archive -p to purge files.
(Optional) unmount the volume from which the archive files were purged.

S3 storage for archive depots

You might want to consider using S3 storage, which supports all depot types except remote depots. To learn more, see S3 storage.