Re: Problems with incremental btrfs send (out of order instructions?)

Xavier Bassery writes: > On 2013-08-01 10:49, Stefan Behrens wrote: >> On Wed, 31 Jul 2013 23:33:59 +0200, Mathijs Kwik wrote: >>> Hi all, >>> >>> For some time, I've successfully deployed btrfs send/receive as a >>> viable backup solution

Problems with incremental btrfs send (out of order instructions?)

Hi all, For some time, I've successfully deployed btrfs send/receive as a viable backup solution. It's fast and flexible and nicely scriptable =) However, every once in a while, trouble strikes on the receiving end with a message like: ERROR: rename nixpkgs/pkgs/applications/version-management/s

Re: how stable are snapshots at the block level?

On Sun, Oct 23, 2011 at 6:05 PM, Chris Mason wrote: > On Sun, Oct 23, 2011 at 09:45:10AM +0200, Mathijs Kwik wrote: >> Hi all, >> >> I'm currently doing backups by doing a btrfs snapshot, then rsync the >> snapshot to my backup location. >> As I have a lot

Re: how stable are snapshots at the block level?

On Sun, Oct 23, 2011 at 4:08 PM, Edward Ned Harvey wrote: >> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs- >> ow...@vger.kernel.org] On Behalf Of Mathijs Kwik >> >> I'm currently doing backups by doing a btrfs snapshot, then rsync the >> snapshot

how stable are snapshots at the block level?

Hi all, I'm currently doing backups by doing a btrfs snapshot, then rsync the snapshot to my backup location. As I have a lot of small files and quite some changes between snapshots, this process is taking more and more time. I looked at "btrfs find-new", which is promissing, but I need something

Re: raid modes, balancing, and order in which data gets written

but have some "scratch dirs" available with very high performance (raid0), without having to create a new filesystem and deciding how big it needs to be. On Fri, Jul 16, 2010 at 1:19 AM, Sean Bartell wrote: > On Thu, Jul 15, 2010 at 10:29:07AM +0200, Mathijs Kwik wrote: >> H

raid modes, balancing, and order in which data gets written

Hi all, I read that btrfs - in a raid mode - does not mimic the behavior of traditional (hw/sw) raid. After writing to a btrfs raid filesystem, data will only be distributed the way you expect after running a rebalance. Say I write a file to the a raid1 (or raid10) fs, and run the "sync" command

Re: snapshotting - what data gets shared?

thanks, sounds very promising On Thu, Jul 15, 2010 at 12:13 AM, Sean Bartell wrote: > On Wed, Jul 14, 2010 at 11:27:39PM +0200, Mathijs Kwik wrote: >> Hi all, >> >> I'm used to snapshots with LVM and I would like to compare them to btrfs. >> >> The case I w

snapshotting - what data gets shared?

Hi all, I'm used to snapshots with LVM and I would like to compare them to btrfs. The case I want to compare is the following: At the moment a snapshot is created, no extra space is needed (maybe some metadata overhead) and all data is shared between the original and the snapshot. In LVM, snapsho

the flushoncommit mount option

Hi all, Over the past few months, I've been trying out btrfs on separate mountpoints. I like it very much so I would like to try it on my home or root volumes and see if I can do something fun with the snapshots. As btrfs still isn't production-ready, I made sure everything is backed-up to an exte