To be sure, Ed, I'm not asking: Why bother trying to backup with "zfs send" when there are fully supportable and working options available right NOW?
Rather, I am asking: Why do we want to adapt "zfs send" to do something it was never intended to do, and probably won't be adapted to do (well, if at all) anytime soon instead of optimizing existing technologies for this use case? But I got it. "zfs send" is fast. Let me ask you this, Ed...where do you "zfs send" your data to? Another pool? Does it go to tape eventually? If so, what is the setup such that it goes to tape? I apologize for asking here, as I'm sure you described it in one of the other threads I mentioned, but I'm not able to go digging in those threads at the moment. I ask this because I see an opportunity to kill 2 birds with one stone. With proper NDMP support and "zfs send" performance, why can't you get the advantages of "zfs send" without trying to shoehorn "zfs send" into a use it's not designed for? Maybe NDMP support needs to be a higher focus of the ZFS team? I noticed not many people even seem to be asking for it, never mind screaming for it. However, I did say this in my original e-mail - that I see NDMP support as being a way to handle the calls for "zfs send" to tape. Maybe we can broaden the conversation at this point. For all of those who use NDMP today to backup Filers, be they NetApp, EMC, or other vendors' devices...how is your experience with NDMP? *IS* anyone using NDMP? If you have the option of using NDMP and you don't, why don't you? Backing up file servers directly to tape seems to be an obvious WIN, so if people aren't doing it, I'm curious why they aren't. That's any kind of file server, because (Open)Solaris will increasingly be applied in this role. That was pretty much the goal of the Fishworks team, IIRC. So this looks like an opportunity by Sun (Oracle) to take a neglected backup technology and make it a must-have backup technology, by making it integrate smoothly with ZFS and high performance. On Wed, Mar 17, 2010 at 09:37, Edward Ned Harvey <solar...@nedharvey.com>wrote: > > The one thing that I keep thinking, and which I have yet to see > > discredited, is that > > ZFS file systems use POSIX semantics. So, unless you are using > > specific features > > (notably ACLs, as Paul Henson is), you should be able to backup those > > file systems > > using well known tools. > > This is correct. Many people do backup using tar, star, rsync, etc. > > > > The Best Practices Guide is also very clear about send and receive NOT > > being > > designed explicitly for backup purposes. I find it odd that so many > > people seem to > > want to force this point. ZFS appears to have been designed to allow > > the use of > > well known tools that are available today to perform backups and > > restores. I'm not > > sure how many people are actually using NFS v4 style ACLs, but those > > people have > > the most to worry about when it comes to using tar or NetBackup or > > Networker or > > Amanda or Bacula or star to backup ZFS file systems. Everyone else, > > which appears > > to be the majority of people, have many tools to choose from, tools > > they've used > > for a long time in various environments on various platforms. The > > learning curve > > doesn't appear to be as steep as most people seem to make it out to > > be. I honestly > > think many people may be making this issue more complex than it needs > > to be. > > I think what you're saying is: Why bother trying to backup with "zfs send" > when the recommended practice, fully supportable, is to use other tools for > backup, such as tar, star, Amanda, bacula, etc. Right? > > The answer to this is very simple. > #1 "zfs send" is much faster. Particularly for incrementals on large > numbers of files. > #2 "zfs send" will support every feature of the filesystem, including > things like filesystem properties, hard links, symlinks, and objects which > are not files, such as character special objects, fifo pipes, and so on. > Not to mention ACL's. If you're considering some other tool (rsync, star, > etc), you have to read the man pages very carefully to formulate the exact > backup command, and there's no guarantee you'll find a perfect backup > command. There is a certain amount of comfort knowing that the people who > wrote "zfs send" are the same people who wrote the filesystem. It's > simple, > and with no arguments, and no messing around with man page research, it's > guaranteed to make a perfect copy of the whole filesystem. > > Did I mention fast? ;-) Prior to zfs, I backed up my file server via > rsync. It's 1TB of mostly tiny files, and it ran for 10 hours every night, > plus 30 hours every weekend. Now, I use zfs send, and it runs for an > average 7 minutes every night, depending on how much data changed that day, > and I don't know - 20 hours I guess - every month. > > -- "You can choose your friends, you can choose the deals." - Equity Private "If Linux is faster, it's a Solaris bug." - Phil Harman Blog - http://whatderass.blogspot.com/ Twitter - @khyron4eva
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
