> zfs send/receive over network would require a little more work to set > up (managing snapshots manually, netcat or ssh tunnel). In theory, > yes, it would be better for data integrity (though I am unclear as to > what it does if a transmission error does occur, since the > communication isn't 2-way, just aborts?), and probably would be faster > (though it would need to replicate almost from scratch to start, > luckily there are a few common snapshots due to how the backup pool > was originally populated).
there are configurable services for automatic snapshotting and zfs send/receive, so it should be quite doable. svc:/system/filesystem/zfs/auto-snapshot:daily svc:/system/filesystem/zfs/auto-snapshot:frequent svc:/system/filesystem/zfs/auto-snapshot:hourly svc:/system/filesystem/zfs/auto-snapshot:weekly svc:/system/filesystem/zfs/auto-snapshot:monthly svc:/application/time-slider/plugin:zfs-send The initial zfs send would be big, yes, but with somewhat frequent snapshotting, it shouldn't be that heavy to transfer the rest - probably far less heavy than rsyncing the lot. Yes, communication is simplex with zfs send/receive, so if a packet is dropped and not retransmitted correctly by tcp or whatever protocol used, the connection is broken, zfs send fails, and zfs receive falls back to where it started. Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 98013356 r...@karlsbakk.net http://blogg.karlsbakk.net/ GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med xenotyp etymologi. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
