The problem was with the shell. For whatever reason,
/usr/bin/ksh can't rejoin the files correctly. When
I switched to /sbin/sh, the rejoin worked fine, the
cksum's matched, ...
The ksh I was using is:
# what /usr/bin/ksh
/usr/bin/ksh:
Version M-11/16/88i
SunOS 5.10 Generic
Thanks to John K. and Richard E. for an answer that would have never, ever
occurred to me...
The problem was with the shell. For whatever reason, /usr/bin/ksh can't rejoin
the files correctly. When I switched to /sbin/sh, the rejoin worked fine, the
cksum's matched, and the zfs recv worked
Hi again everyone,
OK... I'm even more confused at what is happening here when I try to rejoin the
split zfs send file...
When I cat the split files and pipe through cksum, I get the same cksum as the
original (unsplit) zfs send snapshot:
#cat mypictures.zfssnap.split.a[a-d] |cksum
re == Richard Elling richard.ell...@gmail.com writes:
re The reason is that zfs send/recv has very good application,
re even in the backup space. There are, in fact, many people
re using it.
[...]
re ZFS send is not an archival solution. You should use an
re archival
my last contribution to this thread (and there was much rejoicing!)
Miles Nordin wrote:
re == Richard Elling richard.ell...@gmail.com writes:
re The reason is that zfs send/recv has very good application,
re even in the backup space. There are, in fact, many people
Miles Nordin car...@ivy.net wrote:
tt == Toby Thain t...@telegraphics.com.au writes:
tt I know this was discussed a while back, but in what sense does
tt tar do any of those things? I understand that it is unlikely
tt to barf completely on bitflips, but won't tar simply silently
I use the following command to convert them back into a single file:
#cat mypictures.zfssnap.split.a[a-g] testjoin
Maybe I'm missing the point, but this command won't give you what you're
after - in bash you want:
# cat mypictures.zfssnap.split.a{a..g} testjoin
Chris
I use the following command to convert them back into a single file:
#cat mypictures.zfssnap.split.a[a-g] testjoin
Maybe I'm missing the point, but this command won't give you what you're
after - in bash you want:
# cat mypictures.zfssnap.split.a{a..g} testjoin
The first should work
On Thu, February 5, 2009 06:39, casper@sun.com wrote:
I use the following command to convert them back into a single file:
#cat mypictures.zfssnap.split.a[a-g] testjoin
Maybe I'm missing the point, but this command won't give you what you're
after - in bash you want:
# cat
re == Richard Elling richard.ell...@gmail.com writes:
re Indeed, but perhaps you'll find the grace to file an
re appropriate RFE?
for what? The main problem I saw was with the wiki not warning people
away from archiving 'zfs send' emphatically enough, for example by
comparing its
Hi everyone,
I appreciate the discussion on the practicality of archiving ZFS sends, but
right now I don't know of any other options. I'm a home user, so
Enterprise-level solutions aren't available and as far as I know, tar, cpio,
etc. don't capture ACL's and other low-level filesystem
On Thu, February 5, 2009 14:15, Michael McKnight wrote:
I appreciate the discussion on the practicality of archiving ZFS sends,
but right now I don't know of any other options. I'm a home user, so
Enterprise-level solutions aren't available and as far as I know, tar,
cpio, etc. don't
mm == Michael McKnight michael_mcknigh...@yahoo.com writes:
mm as far as I know, tar, cpio, etc. don't capture ACL's and
mm other low-level filesystem attributes.
Take another look with whatever specific ACL's you're using. Some of
the cpio formats will probably work because I think
Hello everyone,
I am trying to take ZFS snapshots (ie. zfs send) and burn them to DVD's for
offsite storage. In many cases, the snapshots greatly exceed the 8GB I can
stuff onto a single DVD-DL.
In order to make this work, I have used the split utility to break the images
into smaller,
On 4-Feb-09, at 6:19 AM, Michael McKnight wrote:
Hello everyone,
I am trying to take ZFS snapshots (ie. zfs send) and burn them to
DVD's for offsite storage. In many cases, the snapshots greatly
exceed the 8GB I can stuff onto a single DVD-DL.
In order to make this work, I have used
mm == Michael McKnight michael_mcknigh...@yahoo.com writes:
mm #split -b8100m ./mypictures.zfssnap mypictures.zfssnap.split.
mm #cat mypictures.zfssnap.split.a[a-g] testjoin
mm But when I compare the checksum of the original snapshot to
mm that of the rejoined snapshot, I get a
On Wed, February 4, 2009 12:01, Miles Nordin wrote:
* stream format is not guaranteed to be forward compatible with new
kernels. and versioning may be pickier than zfs/zpool versions.
Useful points, all of them. This particular one also points out something
I hadn't previously thought
On Wed, 4 Feb 2009, Toby Thain wrote:
In order to make this work, I have used the split utility ...
I use the following command to convert them back into a single file:
#cat mypictures.zfssnap.split.a[a-g] testjoin
But when I compare the checksum of the original snapshot to that of
the
On 4-Feb-09, at 2:29 PM, Bob Friesenhahn wrote:
On Wed, 4 Feb 2009, Toby Thain wrote:
In order to make this work, I have used the split utility ...
I use the following command to convert them back into a single file:
#cat mypictures.zfssnap.split.a[a-g] testjoin
But when I compare the
tt == Toby Thain t...@telegraphics.com.au writes:
tt I know this was discussed a while back, but in what sense does
tt tar do any of those things? I understand that it is unlikely
tt to barf completely on bitflips, but won't tar simply silently
tt de-archive bad data?
yeah, I
Miles Nordin wrote:
mm == Michael McKnight michael_mcknigh...@yahoo.com writes:
mm #split -b8100m ./mypictures.zfssnap mypictures.zfssnap.split.
mm #cat mypictures.zfssnap.split.a[a-g] testjoin
mm But when I compare the checksum of the original snapshot to
mm
21 matches
Mail list logo
