Re: is send/receive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Apr 01, 2017 at 05:25:06PM +0200, Lukas Tribus wrote:
> Hello experts,
> 
> 
> quick question about btrfs send/receive:
> 
> Is btrfs send/receive is prone to cause destination filesystem
> corruption/failure, when the source file system is bogus (due to
> bugs, or due to other factors like memory bit-flips happening, both
> *within* the source file system)?
> 
> Or asked differently: does send/receive transfer metadata/tree
> (which may be corrupt) from source to destination?

   Not at that level, no.

   A send stream consists of a sequence of FS operations (copy, mkdir,
reflink, mv, snapshot, etc) which can be used to create a subvolume
which is logically equivalent to the source subvolume. Thus, if there
are broken invariants in the metadata of the source FS, they cannot be
recreated in the destination FS, because you can't create broken
metadata using those operations.

> I would like to know if send/receive is a *completely* appropriate
> to backup data to a destination btrfs filesystem, or if there is a -
> even a one in a million - chance it may corrupt the destination FS.
> Would it be preferable to use a non-btrfs destination FS for backup
> purposes? What do you guys think?

   If you have corruption which results in otherwise valid POSIX
metadata (say, somehow a UID got changed, or some permissions bits got
set into a silly but valid configuration), then that could be
transferred. Corruption leading to a "broken" filesystem (say, an
undeletable directory), no.

> Also, if I understand correctly, checksum are not transferred
> through send/receive, therefor a corruption while transferring is
> possible (just like with rsync), right?

   Correct.

   Hugo.

-- 
Hugo Mills             | Dullest spy film ever: The Eastbourne Ultimatum
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |                                       The Thick of It

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux