On Oct 7, 2012, at 3:50 PM, Johannes Totz <johan...@jo-t.de> wrote:

> On 05/10/2012 15:01, Edward Ned Harvey
> (opensolarisisdeadlongliveopensolaris) wrote:
>>> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- 
>>> boun...@opensolaris.org] On Behalf Of Tiernan OToole
>>> I am in the process of planning a system which will have 2 ZFS 
>>> servers, one on site, one off site. The on site server will be
>>> used by workstations and servers in house, and most of that will
>>> stay in house. There will, however, be data i want backed up
>>> somewhere else, which is where the offsite server comes in... This
>>> server will be sitting in a Data Center and will have some storage 
>>> available to it (the whole server currently has 2 3Tb drives, 
>>> though they are not dedicated to the ZFS box, they are on VMware 
>>> ESXi). There is then some storage (currently 100Gb, but more can
>>> be requested) of SFTP enabled backup which i plan to use for some 
>>> snapshots, but more on that later.
>>> Anyway, i want to confirm my plan and make sure i am not missing 
>>> anything here...
>>> * build server in house with storage, pools, etc... * have a
>>> server in data center with enough storage for its reason, plus the
>>> extra for offsite backup * have one pool set as my "offsite"
>>> pool... anything in here should be backed up off site also... *
>>> possibly have another set as "very offsite" which will also be
>>> pushed to the SFTP server, but not sure... * give these pools out
>>> via SMB/NFS/iSCSI * every 6 or so hours take a snapshot of the 2 
>>> offsite pools. * do a ZFS send to the data center box * nightly,
>>> on the very offsite pool, do a ZFS send to the SFTP server * if 
>>> anything goes wrong (my server dies, DC server dies, etc), Panic, 
>>> download, pray... the usual... :)
>>> Anyway, I want to make sure i am doing this correctly... Is there 
>>> anything on that list that sounds stupid or am i doing anything 
>>> wrong? am i missing anything?
>>> Also, as a follow up question, but slightly unrelated, when it 
>>> comes to the ZFS Send, i could use SSH to do the send, directly to 
>>> the machine... Or i could upload the compressed, and possibly 
>>> encrypted dump to the server... Which, for resume-ability and 
>>> speed, would be suggested? And if i where to go with an upload 
>>> option, any suggestions on what i should use?
>> It is recommended, whenever possible, you should pipe the "zfs send" 
>> directly into a "zfs receive" on the receiving system.  For two
>> solid reasons:
>> If a single bit is corrupted, the whole stream checksum is wrong and 
>> therefore the whole stream is rejected.  So if this occurs, you want 
>> to detect it (in the form of one incremental failed) and then
>> correct it (in the form of the next incremental succeeding).
>> Whereas, if you store your streams on storage, it will go undetected,
>> and everything after that point will be broken.
>> If you need to do a restore, from a stream stored on storage, then 
>> your only choice is to restore the whole stream.  You cannot look 
>> inside and just get one file.  But if you had been doing send | 
>> receive, then you obviously can look inside the receiving filesystem 
>> and extract some individual specifics.
>> If the recipient system doesn't support "zfs receive," [...]
> On that note, is there a minimal user-mode zfs thing that would allow
> receiving a stream into an image file? No need for file/directory access
> etc.

cat :-)

> I was thinking maybe the zfs-fuse-on-linux project may have suitable bits?

I'm sure most Linux distros have cat
 -- richard

zfs-discuss mailing list
  • Re: [zfs-discuss]... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
    • Re: [zfs-dis... Johannes Totz
      • Re: [zfs... Richard Elling
        • Re: ... Tiernan OToole
          • ... Ian Collins
            • ... Tiernan OToole
        • Re: ... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
          • ... Richard Elling
            • ... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
              • ... Richard Elling
              • ... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
              • ... Jim Klimov
              • ... Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)

Reply via email to