Thanks again Jim. Very handy info. This is now my weekend project, so hopefully things go well!
--Tiernan On Fri, Oct 5, 2012 at 10:40 AM, Jim Klimov <jimkli...@cos.ru> wrote: > 2012-10-05 13:13, Tiernan OToole wrote: > >> Thanks for that Jim! >> >> Sounds like a plan there... One question about the storing ZFS dumps in >> a file... So, the idea of storing the data in a SFTP server which has an >> unknown underlying file system... Is that defiantly off limits, or can >> it be done? >> > > Mileages do vary. Maybe you should pack the stream files into > archives with error-correction codes (or at least verification > CRCs) like ZIP, RAR, likely p7zip, maybe others; and also keep > checksum files. At least this can help detect or even fix small > nasty surprises. > > The general concern is that zfs send streams have no built-in > redundancy, I'm not sure about error-checking - likely it is > there. And it is widely assumed that this being a stream, a small > error can redirect the flow widely differently from expectations > and cause the whole dataset state to be invalid (likely this > snapshot receiving will be aborted, and then you can't receive > any newer ones over it). > > That said, some people do keep the streams on tape; the NDMP > tools and protocol from Sun IIRC do the same for backups. > So it's not off-limits, but precautions may be due (keep 2+ > copies, do CRC/ECC and so on). > > > > and should i be doing a full dump or just an incremental > > one? maybe incremental daily, and then a full dump weekly? > > A full dump of a large filesystem can be unbearably large for > storage and transfers. Still, the idea of storing occasional > full snapshots and a full history of incrementals (so that you > can try to recover starting from any of the full snapshots you > have) sounds sane. This way you have a sort of second copy by > virtue of a full snapshot incorporating some state of the dataset > and if the most recent one is broken - you can try to recover > with the one(s) before it and applying more incremental snapshots. > Likewise, errors in very old snapshots become irrelevant when a > newer full snapshot is intact. But sometimes two or more things > can break - or be detected to break - at once ;) > > In particular, regular drills should be done (and provisioned > for) to test that you can in fact recover from your backups, > and that they do contain all the data you need. Older configs > can become obsolete as live systems evolve... > > HTH, > //Jim > > > ______________________________**_________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/**mailman/listinfo/zfs-discuss<http://mail.opensolaris.org/mailman/listinfo/zfs-discuss> > -- Tiernan O'Toole blog.lotas-smartman.net www.geekphotographer.com www.tiernanotoole.ie
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
