Move perf.data Analysis Safely with perf archive

perf archive packages the object files a perf.data recording refers to, so you can analyse that recording on another Linux machine. The command reads the recording and gathers files identified by build IDs; it does not turn the recording into a report by itself.

Allow about ten minutes for a small recording, plus time to copy the resulting archive. This guide covers the perf archive subcommand shipped with Ubuntu's linux-tools-common package, version 6.8.0-142.142, from a local manpage 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 your profiling run actually produced. If test prints nothing, fix the path or read permission before reaching for sudo; running as root will not repair a missing recording.

Checkpoint: the input is ready

• perf is present. Its version matches the kernel tools you intend to use.
• The recording is readable by the account that will run the archive.
• Space is available. You know where the output archive will land and have enough free room there.

2. Create the archive beside the recording

Run the command with the recording path. Here the output lands in the current directory, which is also where the command runs:

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

The manual describes perf archive as running perf-buildid-list --with-hits and collecting every file whose build ID occurs 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 once 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 whatever name actually exists on your installed version. A zero exit status is the first useful check, but the directory listing confirms 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 keep 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, not values to copy. Record the real values, then verify them after transfer: copy to a destination you control with your normal transfer tool, run sha256sum there, and compare the two lines.

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 once the archived objects are available as the installed perf tooling expects; the manpage points to perf-report and perf-buildid-list for the surrounding workflow. This does not guarantee every symbol will resolve: 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, inspect paths and permissions first:

$ 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 linux-tools-common alone provides the version-specific executable for every kernel.

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

Confirm the filename with ls -l before running rm, and never 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 run the operation rather than broadening permissions casually.