> 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.1
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 wi
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 writes:
>> well, I think most backups are archival.
re> Disagree. Archives tend to not be overwritten, ever. Backups
re> have all sorts of management schemes to allow the backup media
re> to be reused.
The problem with storing 'zfs send' arises w
> "re" == Richard Elling writes:
>>
http://mail.opensolaris.org/pipermail/zfs-discuss/2008-December/053894.html
re> Bzzt. Thanks for playing. That is: CR 6764193 was fixed in
re> b105 http://bugs.opensolaris.org/view_bug.do?bug_id=6764193 Is
re> there another?
I don't und
my last contribution to this thread (and there was much rejoicing!)
Miles Nordin wrote:
>> "re" == Richard Elling 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>
> "re" == Richard Elling 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 method which is a
Miles Nordin wrote:
>> "re" == Richard Elling 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,
> "mm" == Michael McKnight 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 there was a thread
in
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 cap
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 attribu
> "re" == Richard Elling 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 archival characterist
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:
>>
>> 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 sho
> 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
Miles Nordin wrote:
> > "tt" == Toby Thain 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 ba
Miles Nordin wrote:
>> "mm" == Michael McKnight 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
> "tt" == Toby Thain 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 just tested it,
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
On 4-Feb-09, at 1:01 PM, Miles Nordin wrote:
... Here are the
> problems, again, with archiving 'zfs send' output:
> ...
>EXTREMELY corruption-sensitive. 'tar' and zpool images both
>detect, report, work around, flipped bits.
I know this was discussed a while back, but in what sense does
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
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
> "mm" == Michael McKnight 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 different result
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
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, fixe
25 matches
Mail list logo
