Hi, I am considering implement "btrfs send/receive" API in libguestfs. But seems its usual condition is incremental backup which is pretty complicated (see 5.7.1: http://docs.oracle.com/cd/E37670_01/E37355/html/ol_sendrecv_btrfs.html) and not suitable for implementation as I think. So I am considering, does it make sense to implement a simplest form: $ btrfs send -f sent_file subvol $ btrfs receive -f sent_file mountpoint which just backup a subvolume and restore it. Anyone have suggestions? -- Yours Sincerely, Cao Jin
Richard W.M. Jones
2015-Jun-23 08:58 UTC
Re: [Libguestfs] Question about "btrfs send/receive" cmd
On Tue, Jun 23, 2015 at 02:57:30PM +0800, Cao jin wrote:> Hi, > I am considering implement "btrfs send/receive" API in > libguestfs. But seems its usual condition is incremental backup > which is pretty complicated (see 5.7.1: http://docs.oracle.com/cd/E37670_01/E37355/html/ol_sendrecv_btrfs.html) > and not suitable for implementation as I think. > > So I am considering, does it make sense to implement a simplest form: > > $ btrfs send -f sent_file subvol > $ btrfs receive -f sent_file mountpoint > > which just backup a subvolume and restore it. > > Anyone have suggestions?The natural way would be to map this to FileIn/FileOut so that the input/output can be streamed to the client. Compare the tar-in and tar-out APIs: https://github.com/libguestfs/libguestfs/blob/master/daemon/tar.c Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/
Apparently Analagous Threads
- CentOS 7, container question
- CentOS 7, container question
- [PATCH v3 1/2] Modify the function: analyze_line, make it more flexible
- [PATCH v2 1/2] Modify public function: analyze_line, make it more flexible
- [PATCH v2 1/2] Modify the function: analyze_line, make it more flexible