Move perf.data Analysis Safely with perf archive

You will create an archive containing the object files that a perf.data recording refers to, so you can analyse that recording on another Linux machine. Allow about ten minutes for a small recording, plus the time needed to copy the resulting archive. The command reads the recording and gathers files identified by build IDs. It does not turn the recording into a report by itself.

This guide covers the perf archive subcommand shipped with Ubuntu's linux-tools-common package. The installed package here is version 6.8.0-142.142, and the local manpage is dated 9 January 2026. The executable is kernel-version sensitive on this host: the installed wrapper reports that tools for kernel 6.8.0-139 are missing. Check your own executable before relying on an example's exact diagnostics.

1. Confirm the installed tool and recording

Start in the directory containing the recording, or provide its path explicitly. The synopsis is perf archive [file], where file is the recording to archive. Check the package and command without changing anything:

$ dpkg-query -W -f='${Package} ${Version}\n' linux-tools-common
linux-tools-common 6.8.0-142.142
$ command -v perf
/usr/bin/perf
$ test -r /path/to/perf.data && echo 'recording is readable'
recording is readable

Replace /path/to/perf.data with the real path. A recording can have a different filename, but the path must point to the file produced by your profiling run. If test prints nothing, fix the path or read permission before using sudo. Running the command as root will not repair a missing recording.

Checkpoint: the input is ready

• perf is present and its version matches the kernel tools you intend to use.
• The recording is readable by the account that will run the archive.
• You know where the output archive will be created and have enough free space there.

2. Create the archive beside the recording

Run the command with the recording path. In this example the output is created in the current directory, which is also where the command is run:

$ cd /path/to/capture
$ perf archive perf.data

The manual describes perf archive as running perf-buildid-list --with-hits and collecting files whose build IDs occur in the recording. That gives later analysis access to the binaries and shared objects needed to resolve recorded samples. The archive name and exact progress text are version-dependent, so do not script against a guessed filename or a decorative status line. Inspect the directory after the command returns:

$ printf 'status: %s\n' "$?"
status: 0
$ find . -maxdepth 1 -type f -printf '%f %s bytes\n' | sort
perf.data 184320 bytes
perf.data.tar.bz2 532480 bytes

The sample listing shows a common result name, perf.data.tar.bz2. Use the name that actually exists on your installed version. A zero exit status is the first useful check, but the directory listing confirms that an output file was created and gives you its size.

3. Keep the recording and archive together

Copy both the original recording and the generated archive to the analysis machine. The archive supplies object files; the recording supplies the events and samples. Treat them as a pair and preserve their filenames where possible:

$ stat -c '%n %s bytes' perf.data perf.data.tar.bz2
perf.data 184320 bytes
perf.data.tar.bz2 532480 bytes
$ sha256sum perf.data perf.data.tar.bz2
8d4e...  perf.data
1f2a...  perf.data.tar.bz2

The hashes above are illustrative output, not values to copy. Record the real values, then verify them after transfer. For example, copy to a destination you control with your normal transfer tool, then run sha256sum there and compare the two lines. Do not paste sensitive recording data into an untrusted service: performance data can reveal process names, paths and workload details.

4. Verify the received files before analysis

On the analysis machine, check that both files arrived and that their hashes match the source values:

$ test -r perf.data && test -r perf.data.tar.bz2
$ sha256sum perf.data perf.data.tar.bz2
8d4e...  perf.data
1f2a...  perf.data.tar.bz2

Then use the normal analysis command, such as perf report, against the recording after making the archived objects available as the installed perf tooling expects. The perf archive manpage points to perf-report and perf-buildid-list for the surrounding workflow. This command does not guarantee that every symbol will be available: build IDs can be absent from a recording, files can have been removed from the source machine, and the analysis machine still needs compatible perf support.

5. Diagnose failures without overwriting evidence

If the command cannot open the recording or an object file, first inspect paths and permissions:

$ pwd
$ ls -l -- perf.data
$ test -r perf.data && echo readable
$ df -h .

If the command warns about the running kernel's tools, install or select the matching tools through your normal system administration process, then repeat the version check. This guide does not assume that linux-tools-common alone provides the version-specific executable for every kernel.

Do not delete the original recording after a successful archive until the archive has been transferred, its hash has been checked and a test analysis can resolve the samples you care about. There is no rollback operation for a deleted recording. If an attempt leaves an incomplete output, remove only that specifically identified incomplete archive and rerun after fixing the cause:

$ rm -- ./perf.data.tar.bz2
$ perf archive ./perf.data

The rm command is destructive. Confirm the filename with ls -l first, and do not use a wildcard. No elevated privileges are normally required when the recording and output directory belong to you. If the data is owned by another account, ask its owner or administrator to perform the operation rather than broadening permissions casually.