info > BTRFS-RECEIVE

📖 NAME

btrfs-receive — receive subvolumes from send stream

🚀 Quick Reference

Use CaseCommandDescription
Receive a subvolume from a streambtrfs receive /pathRead send stream from stdin and replicate subvolume(s) into /path
Receive from a filebtrfs receive -f backup.btrfs /pathRead the send stream from a file instead of stdin
Dump stream metadatabtrfs receive --dumpValidate the stream and print one operation per line (no filesystem changes)
Stop after first end markerbtrfs receive -e /pathTerminate immediately when an end command marker is encountered
Limit error tolerancebtrfs receive -E 0 /pathProcess all commands even if errors occur (no error limit)
Explicit root mountbtrfs receive -m /mnt /pathSpecify the root mount point when /proc is not accessible

📋 SYNOPSIS

btrfs receive [options] <path>

or

btrfs receive --dump [options]

📝 DESCRIPTION

Receive a stream of changes and replicate one or more subvolumes that were previously generated by btrfs send. The received subvolumes are stored to path, unless --dump option is given.

If --dump option is specified, btrfs receive will only do the validation of the stream, and print the stream metadata, one operation per line.

btrfs receive will fail in the following cases:

  1. 📁 receiving subvolume already exists
  2. 🔁 previously received subvolume has been changed after it was received
  3. 📂 default subvolume has changed or you didn’t mount the filesystem at the toplevel subvolume

A subvolume is made read-only after the receiving process finishes successfully (see 🐛 BUGS below).

⚙️ Options

🌐 Global Options

🐛 BUGS

btrfs receive sets the subvolume read-only after it completes successfully. However, while the receive is in progress, users who have write access to files or directories in the receiving path can add, remove, or modify files, in which case the resulting read-only subvolume will not be an exact copy of the sent subvolume.

If the intention is to create an exact copy, the receiving path should be protected from access by users until the receive operation has completed and the subvolume is set to read-only.

Additionally, receive does not currently do a very good job of validating that an incremental send stream actually makes sense, and it is thus possible for a specially crafted send stream to create a subvolume with reflinks to arbitrary files in the same filesystem. Because of this, users are advised to not use btrfs receive on send streams from untrusted sources, and to protect trusted streams when sending them across untrusted networks.

🚪 EXIT STATUS

btrfs receive returns a zero exit status if it succeeds. Non zero is returned in case of failure.

🌐 AVAILABILITY

btrfs is part of btrfs-progs. Please refer to the btrfs wiki for further details.

📚 SEE ALSO

mkfs.btrfs(8), btrfs-send(8)

BTRFS-RECEIVE
📖 NAME 🚀 Quick Reference 📋 SYNOPSIS 📝 DESCRIPTION
⚙️ Options 🌐 Global Options
🐛 BUGS 🚪 EXIT STATUS 🌐 AVAILABILITY 📚 SEE ALSO

Generated by phpman v4.9.26-5-g7740029 Author: Che Dong Under GNU General Public License
2026-08-14 21:21 @2600:1f28:365:80b0:4d23:66fa:c2bb:7bae
CrawledBy CCBot/2.0 (https://commoncrawl.org/faq/)
Valid XHTML 1.0 Transitional!Valid CSS!