Thanks again Jim. Very handy info. This is now my weekend project, so
hopefully things go well!
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...
> zfs-discuss mailing list
zfs-discuss mailing list