Re: [zfs-discuss] (Fletcher+Verification) versus (Sha256+No Verification)
Hey there, >> ~= 5.1E-57 > > Bah. My math is wrong. I was never very good at P&S. I'll ask someone at > work tomorrow to look at it and show me the folly. Wikipedia has it right, > but I can't evaluate numbers to the few-hundredth power in any calculator > that I have handy. bc -l
Re: [zfs-discuss] Need a link on data corruption
Hi, > Someone posted about CERN having a bad network card which injected faulty > bits into the data stream. I've regularly heard people mention data corruption in network layer here - and other physics sites like FNAL and SLAC - but I don't have details of any specific incident. We do see our files get corrupted in transit every once in a while though. May be it was about this paper which details some of the findings? http://indico.cern.ch/getFile.py/access?contribId=3&sessionId=0&resId=1&materialId=paper&confId=13797 I can't really speak to where ZFS would be in use in CERN's many infrastructures. I believe the big experiment data pools are all linux disk servers. Regards, Lassi ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs send/receive as backup - reliability?
Hi, > .. it's hard to beat the convenience of a "backup file" format, for > all sorts of reasons, including media handling, integration with other > services, and network convenience. Yes. > Consider then, using a zpool-in-a-file as the file format, rather than > zfs send streams. This is an interesting suggestion :-) Did I understand you correctly that once a slice is written, zfs won't rewrite it? In other words, I can have an infinitely growing pile of these slices, and once zfs fills one file up (or one "raidz2" set of files), I flush it to tape/optical disk/whatever, and zfs won't change it "ever after"? When I need more space, I just add more slices, but old slices are effectively read-only? Or did I misunderstand how you meant it work? It sounded very interesting but my understanding on zfs is currently limited :-) And perhaps most importantly: has anyone actually done this for their back-ups and has success stories on restore after media failure? Regards, Lassi ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs send/receive as backup - reliability?
Hi, > Here is the big difference. For a professional backup people still typically > use tapes although tapes have become expensive. > > I still believe that a set of compressed incremental star archives give you > more features. Thanks for your comments! I think I roughly understand the feature trade-offs, and have some experience with back-up solutions ranging from simple to enterprise. I guess what I am after is, for data which really matters to its owners and which they actually had to recover, did people use tar/pax archives (~ file level standard archive format), dump/restore (~ semi-standard format based on files/inodes) or zfs send/receive (~ file system block level dump), or something else, and why? (Regardless of how these are implemented, hobby scripts or enterprise tools, how they dealt with possible media failure issues, etc.) Other than the file system vs. file restore, is there any concern in doing the block level thing? "Concerns" as in "mind being in the line of fire if it fails?" :-) Regards, Lassi ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs send/receive as backup - reliability?
Hi, >> I am considering building a modest sized storage system with zfs. Some >> of the data on this is quite valuable, some small subset to be backed >> up "forever", and I am evaluating back-up options with that in mind. > > You don't need to store the "zfs send" data stream on your backup media. > This would be annoying for the reasons mentioned - some risk of being able > to restore in future (although that's a pretty small risk) and inability to > restore with any granularity, i.e. you have to restore the whole FS if you > restore anything at all. > > A better approach would be "zfs send" and pipe directly to "zfs receive" on > the external media. This way, in the future, anything which can read ZFS > can read the backup media, and you have granularity to restore either the > whole FS, or individual things inside there. > > Plus, the only way to guarantee the integrity of a "zfs send" data stream is > to perform a "zfs receive" on that data stream. So by performing a > successful receive, you've guaranteed the datastream is not corrupt. Yet. Thanks for your feedback! My plan is to have near-line back-up on zfs on another physically independent media, much as you describe. Then another copy off-site on separate system (disk), and third copy on WORM-like media in "chunks" somewhere else. I am really looking to have the latter two sliced to fit non-disk media (tape, optical disks, ...), or external storage not really usable as a filesystem (S3, web hosting, ...). The off-site disk is not in zfs-capable system, unless I set up a virtual machine; but it won't have enough physical disks for raidz2 anyway. I am primarily looking for something I can store encrypted in dvd- or tape-sized slices on at least two physically separate media. This backup would be used when at least two other media have already been lost, so while convenience is a plus I really desire reliability and longevity. (Yes I know tapes and DVDs die too.) I appreciate the comments by others on zfs send not allowing individual file restore, but as I wrote before this is not very important to me, at least not as important than my other questions. Apropos, is anyone able to respond to those? (Is format documented, independent tools, bugs known to have affected send/restore, would you recommend over tar/pax in real life, etc.) I am very interested in what people have actually done and experienced in real life, including disaster recovery from multiple media failure. Regards, Lassi ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs send/receive as backup - reliability?
Hi, I am considering building a modest sized storage system with zfs. Some of the data on this is quite valuable, some small subset to be backed up "forever", and I am evaluating back-up options with that in mind. My understanding is that zfs send approximately captures the copy-on-write file system block-level dump, and zfs receive plays it back to rebuild the file system, and this can be used among other things for back-ups. I call the dump "stream" below. How reliable is this? I don't mind the fact I would have to replay entire file system instead of individual files. My concern is that for whatever reason I'd lose ability to play the stream back, and would not be able to restore possibly years from now. Is the format documented? Is it possible to interpret the data with independent tools, like it's possible with tar/pax/cpio archives? Even if no such tool exists now, could I for example write a user space tool using currently existing open source zfs user space library that was able to extract useful information from the data stream? I realise this could be somewhat complex, especially incremental dumps - but just how hard? How exactly does the stream have to match the file system to restore? My assumption zfs requires an exact match: you can only restore at exact point you backed up from. (Fine by me, just need to know.) Follow-up: does one corrupted incremental back-up set invalidate all incremental back-up sets until the next full back-up point (or higher-level incremental point)? Assuming the zfs send data stream hasn't been corrupted, have there been instances where it's not possible to restore file system by playing it back via zfs receive? Have there been cases where some bug has caused "zfs send" data become corrupted so that restoration is no longer possible? (Either zfs on-disk file system bug, or something in zfs send not doing the right thing.) Is it possible to make dry-run restoration attempt at back-up time to verify the restoration would succeed? Would you recommend zfs send/receive as a back-up strategy for highly valuable data at this point in time? Ignoring the individual file vs. whole file system aspect, how reliable you rank it compared to tar/pax? Regards, Lassi ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
