> "Dennis Clarke" <[EMAIL PROTECTED]> wrote: > >> >> As near as I can tell the ZFS filesystem has no way to backup easily to a >> tape in the same way that ufsdump has served for years and years. > ... >> # mt -f /dev/rmt/0cbn status >> HP DAT-72 tape drive: >> sense key(0x0)= No Additional Sense residual= 0 retries= 0 >> file no= 0 block no= 0 >> # zfs send zfs0/[EMAIL PROTECTED] > /dev/rmt/0cbn >> cannot write stream: I/O error >> # > > This looks like a tape problem.... >
no .. the status was EOT strangely the Sun mt reports EOT but schily mt did not. >> Of course it took a number of hours for that I/O error to appear because >> the >> tape hit its capacity. There were no reports of 10% or 20% and no prompt >> for "end of media" and "please insert a blank tape and hit enter when >> ready" >> sort of thing. > > Are you sure that this is caused by a EOT situation? yes .. absolutely positive. > > If this was EOT, then I would not expect EIO. > >> (1) perhaps I can break my ZFS filesystem area into chunks that fit on >> a HP DAT-72 tape drive without compression. I think this is just >> not reasonable. > > Is the ZFS backup unable to write multi-volume backups? > If this is true, then it is not yet ready for production. I don't think that the stream of data from zfs send was ever intended to go directly to tape media. > >> (2) perhaps I can use find and tar or cpio to backup small "tape drive >> capacity" sized chunks of the ZFS filesystem. Then dump these with >> some hand written notes or post-it notes to indicate what directory >> bits I have and what tape is needed to get the other bits. Let me >> expound on this a tad : > > I can neither recommend Sun tar not cpio for backups. > I use star but star reports all the files on ZFS as being sparse. > >> >> However I will quickly end up with a pile of tapes to dump >> one ZFS filesystem and no easy way to get incrementals >> other than to 'touch timestamp' and then use find to build >> a list of new or modified files based on the -newer switch. > > star supports true incremental bsckups for POSIC compliant filesystems. > The way star works is very similar to what ufsdump does except that star > accesses the FS in a clean official way. > I will need to check the latest sources for star and do a fresh smake and then test this weekend. Dennis Clarke _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss