On Mar 4, 2010, at 4:33 AM, Svein Skogen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04.03.2010 13:18, Erik Trimble wrote: >> Svein Skogen wrote: >>> And again ... >>> >>> Is there any work on an upgrade of zfs send/receive to handle resuming >>> on next media? >>> >>> I was thinking something along the lines of zfs send (when device goes >>> full) returning >>> >>> "send suspended. To resume insert new media and issue zfs resume >>> <IDNUMBER>" >>> >>> and receive handling: >>> "zfs receive stream ended before end of file system. Insert next media >>> and issue zfs resume <IDNUMBER>" >>> >>> >>> Both of these would give us the ability to do graceful backups (at >>> near wirespeed of modern SAS autoloaders) and restores with few >>> additional tools. >>> >>> With a little tweak, I suspect zstreamdump could handle verifies as >>> well... >>> >>> //Svein >>> >> What you are after is 'zfs send|receive' to act just like >> ufsdump|ufsrestore. Frankly, I don't think that's going to happen >> anytime soon. dump|receive are badly out-of-date (not just on Solaris, >> but on any OS). They suck as any sort of larger scale backup system, as >> they are missing any sort of indexing and browsing tools, no tape >> identification and cataloging, and are really only useful for fast >> restore of very limited, well-defined data sets (at this point, OS >> reinstalls, really). >> >> I can certainly see having 'zfs send|receive' being able to split their >> stream into chunks somehow - this would make integration with things >> like Amanda much simpler. But let's face it: it's /highly/ unlikely >> that you would have just 'zfs send|receive' without also being able to >> get at your add-on backup software, all of which is simple to install >> (and, even if you are using many commercial packages, they're even able >> to be run for a short time without license keys). >> The scenario of "my server burned to the ground, and all I've got is the >> OS CD and a single backup tape" is pretty much dust with the ancients >> nowdays - if you find yourself in such a scenario, you've either done >> some really poor planning, or civilization has collapsed. > > Actually, this sounds a lot like "if you're not a big enough corporation > to have multiple locations with servers on line, your data just isn't > important enough to store backups of in the first place". > > I'm a one-man photographer. I have the server solution at home. This > home is built from wood, but I have a real solid cellar with a safe > suitable for tapes, and I have a safe off-location place to store 20 > tapes (which will be used for rotation). > > But, I guess my data simply isn't important enough, since I cant afford > to have two locations with online servers to do real-time sync.
horsehockey. ZFS works fine with traditional backup solutions which also support tape. These include Zmanda, Networker, and NetBackup. For more information, see the ZFS Best Practices Guide section on Backup. http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#ZFS_Backup_.2F_Restore_Recommendations -- richard ZFS storage and performance consulting at http://www.RichardElling.com ZFS training on deduplication, NexentaStor, and NAS performance http://nexenta-atlanta.eventbrite.com (March 16-18, 2010) _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
