Clone an XFS Filesystem Safely with xfs_copy

xfs_copy clones an XFS filesystem sector by sector onto another device or into an image file, ready to stand alone with its own UUID. The copy can be mounted as a separate filesystem without colliding with its source. Allow 15 to 30 minutes for preparation and checking, plus the time needed to read the filesystem.

The examples here use xfs_copy 6.6.0 from xfsprogs 6.6.0-1ubuntu2.1. You need an XFS source, a target with enough capacity, and permission to read the source and write the target. Writing a real block device normally requires elevated privileges.

1. Check the installed command

This is an ordinary, read-only check. It does not need sudo:

$ xfs_copy -V
xfs_copy version 6.6.0
$ dpkg-query -W -f='${Package} ${Version}\n' xfsprogs
xfsprogs 6.6.0-1ubuntu2.1

Your version may differ. Read the local manual for the installed version before copying a production filesystem, especially if the command came from another distribution.

2. Pick and verify the source and target

Set explicit shell variables for the paths so a slip of the finger does not land on the wrong device. Replace the placeholders with the paths from your change plan. A regular file target becomes a filesystem image; a device target receives a filesystem directly.

$ SOURCE=/dev/mapper/vg0-data
$ TARGET=/dev/mapper/vg0-data-copy
$ printf 'source: '; readlink -f "$SOURCE"
$ printf 'target: '; readlink -f "$TARGET"
$ lsblk -o NAME,PATH,SIZE,FSTYPE,MOUNTPOINTS "$SOURCE" "$TARGET"

• Stop if either path is not the object you expect. A typo here is more dangerous than a typo in an option.
• Never point it at a mounted target. xfs_copy overwrites whatever is already there.
• Check space if the target is a file. Pick a new pathname and confirm the holding filesystem has room. The image takes the source's logical size, though on XFS it can consume roughly the source's used data and log space, since free blocks are skipped and sparse files are efficient.

3. Put the source in a consistent state

The safest choices are an unmounted source or a read-only mount. If the filesystem must stay mounted, freeze it for the copy. Freezing blocks new modifications and flushes pending data, metadata and log information, so this can pause applications using that mount.

$ sudo xfs_freeze -f /srv/data
$ sudo xfs_copy "$SOURCE" "$TARGET"
$ sudo xfs_freeze -u /srv/data

Keep the unfreeze command ready before you start. If the copy fails, unfreeze the source once you have captured the error and log path: do not leave a live service blocked while you investigate.

If you can unmount the source instead, do that through the service's normal shutdown and mount-management procedure rather than guessing which processes are safe to stop. A read-only mount still needs to be a genuinely read-only view for the whole copy.

4. Copy to one target

With an unmounted, read-only or frozen source, run the copy. This command changes the target and may need elevated privileges:

$ sudo xfs_copy -L /var/tmp/xfs-copy-data.log "$SOURCE" "$TARGET"
source filesystem copied successfully

The exact progress and success text can vary. The result that matters is exit status 0:

$ printf 'exit status: %s\n' "$?"
exit status: 0

xfs_copy uses synchronous writes and records diagnostics to standard error and its log. By default the log is a generated file under /var/tmp; -L gives you a predictable location. Keep that log with the change record until the target has been checked.

5. Copy to several targets in parallel

You can pass more than one target. The command writes them in parallel, creating one additional thread for each target:

$ sudo xfs_copy -L /var/tmp/xfs-copy-2026-09-28.log \
    "$SOURCE" \
    /dev/mapper/vg0-data-copy-a \
    /dev/mapper/vg0-data-copy-b

Parallel output does not make target checks optional. A write error aborts that target while the others continue, and the command exits with status 1 if any target fails, even when another succeeds. Inspect the log and treat each target as a separate result.

6. Copy into an image file instead

A file target suits an image workflow, or moving the copy through storage that is not a block device:

$ IMAGE=/srv/images/data-copy.xfs
$ sudo xfs_copy -b -L /var/tmp/xfs-copy-image.log "$SOURCE" "$IMAGE"
$ ls -lh "$IMAGE"
$ file "$IMAGE"

The -b option selects buffered I/O so direct I/O is not attempted on target filesystems that do not support it. It does not make the source safe to copy while it is changing. The output file is created if it does not exist, so check the name first and never point it at a valuable existing file without an explicit replacement plan.

7. Understand the UUID and clone boundary

Normally, each new target is identical in content but receives a new, unique filesystem identifier. That is what you want when the source and copy will be mounted as separate filesystems. Verify the identifiers before mounting both in the same host environment:

$ sudo xfs_info "$SOURCE" | grep -E 'meta-data=.*uuid'
$ sudo xfs_info "$TARGET" | grep -E 'meta-data=.*uuid'

The formatting of xfs_info output is host-specific. Confirm that the target is recognised as XFS and that the UUID values differ. If your workflow needs a true duplicate UUID, use xfs_copy -d only when the new filesystem replaces the original, such as a disk replacement, never for two independently mounted copies.

8. Know the boundaries

• No real-time section or external log. xfs_copy does not copy either and aborts with an error. Check the filesystem design before scheduling a long copy, and use a workflow built for that feature instead.
• Growing later needs a different tool. For a source much smaller than a replacement disk that will later be grown, the manual recommends mkfs.xfs followed by xfsdump and xfsrestore. That workflow can produce a better layout than copying and then running xfs_growfs, though this is a layout decision, not a reason to skip the source-consistency rule.
• A failed target is not a filesystem. Check the exact target named in the diagnostic, its writable state and available capacity. Do not mount or reuse a failed target as if the copy had succeeded. Correct the cause, clear or replace the target deliberately, and rerun the copy. The source itself is never altered by xfs_copy.