On 22/8/2014 6:40 πμ, Shriramana Sharma wrote:
Hello people. Thank you for your detailed replies, esp Duncan.
In essence, I plan on using BTRFS for my production data -- mainly
programs/documents I write in connection with my academic research.
I'm not a professional sysadmin and I'm not running a business server.
I'm just managing my own data, and as I have mentioned, my chief
reason for looking at BTRFS is the ease of snapshots and backups using
send/receive.
It is clear now that snapshots are by and large stable but
send/receive is not. But, IIUC, even if send/receive fails I still
have the older data which is not overwritten due to COW and atomic
operations, and I can always retry send/receive again. Is this
correct?
If yes, then I guess I can take the plunge but ensure I have daily
backups (which BTRFS itself should help me do easily).
I would stay with rsync for a while, because there is always the
possibility of a bug that corrupts both your primary filesystem and your
backup one, or send propagating corruption from one filesystem to
another (Or maybe I am too paranoid, it would be good if we could have
the opinion of a btrfs developer on this)
I would also suggest lsyncd if rsync runs become slow due to too many
files and directories, or you have something like my use case, where i
have filesystems with millions of files and my backup servers are a few
km away and reachable over relatively slow wireless links.
Finaly, be sure to use the --inplace option of rsync.
--
Konstantinos Skarlatos
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
