I'm sure that's true. My point was that, given the choice between a
zfs send/recv from one set of devices to another, where the target is
another pool, and sending a zfs stream to a tarball, I'd sooner choose
a solution that's all live filesystems.
If backups are *really* important, then it's cer
on Mon Feb 23 2009, Robert Milkowski wrote:
> Hello David,
>
> Saturday, February 21, 2009, 10:33:05 PM, you wrote:
>
> DA> on Sat Feb 21 2009, Miles Nordin wrote:
>
>>> Many new ZFS users are convinced to try ZFS because they want to back
>>> up non-ZFS filesystems onto zpool's because it's be
Hello David,
Saturday, February 21, 2009, 10:33:05 PM, you wrote:
DA> on Sat Feb 21 2009, Miles Nordin wrote:
>> Many new ZFS users are convinced to try ZFS because they want to back
>> up non-ZFS filesystems onto zpool's because it's better than tape, so
>> that's not a crazy idea.
DA> Not cr
> "b" == Blake writes:
c> There are other problems besides the versioning.
b> Agreed - I don't think that archiving simply the send stream
b> is a smart idea (yet, until the stream format is stabilized
*there* *are* *other* *problems* *besides* *the* *versioning*!
pgpVqjLh
Agreed - I don't think that archiving simply the send stream is a
smart idea (yet, until the stream format is stabilized in some way).
I'd much rather archive to a normal ZFS filesystem. With ZFS's
enormous pool capacities, it's probably the closest thing we have
right now to a future-proof filesy
> "da" == David Abrahams writes:
> "b" == Blake writes:
da> Has anyone here noticed that
da> http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
da> suggests in several places that zfs send streams be stored for
da> backup?
Yup. I requested a wiki a
On Mon, Feb 23, 2009 at 11:33 AM, Blake wrote:
> I thinks that's legitimate so long as you don't change ZFS versions.
>
> Personally, I'm more comfortable doing a 'zfs send | zfs recv' than I
> am storing the send stream itself. The problem I have with the stream
> is that I may not be able to r
I thinks that's legitimate so long as you don't change ZFS versions.
Personally, I'm more comfortable doing a 'zfs send | zfs recv' than I
am storing the send stream itself. The problem I have with the stream
is that I may not be able to receive it in a future version of ZFS,
while I'm pretty sur
on Wed Feb 18 2009, Frank Cusack wrote:
> On February 17, 2009 3:57:34 PM -0800 Joe S wrote:
>> On Tue, Feb 17, 2009 at 3:35 PM, David Magda wrote:
>>> If you want to do back ups of your file system use a documented utility
>>> (tar, cpio, pax, zip, etc.).
>>
>> I'm going to try to use Amanda
on Sat Feb 21 2009, Miles Nordin wrote:
>> "da" == David Abrahams writes:
>> "ic" == Ian Collins writes:
>
> da> disadvantage of the recommended approaches shows up when you
> da> start taking advantage of ZFS to clone filesystems without
> da> replicating storage. Using "
Miles Nordin wrote:
ic> I wouldn't have any serious concerns about backing up
ic> snapshots provided the stream version was on the tape label
ic> and I had a backup of the Solaris release (or a virtual
ic> machine) that produced them.
I would have serious concerns doing that beca
> "da" == David Abrahams writes:
> "ic" == Ian Collins writes:
da> disadvantage of the recommended approaches shows up when you
da> start taking advantage of ZFS to clone filesystems without
da> replicating storage. Using "zfs send" will avoid representing
da> the data t
On Sat, 21 Feb 2009, Tim wrote:
Well given that I *KNOW* Sun isn't making shit up as they go along, and I
have *SEEN* some of their plans under NDA, I'll just outright call bullshit.
I was trying to be nice about it. If you're making stuff up as you go
along that's likely why you're struggling.
David Abrahams wrote:
David Magda ee.ryerson.ca> writes:
The format of the [zfs send] stream is evolving. No backwards
compatibility is guaranteed. You may not be able to receive your
streams on future versions of ZFS.
http://docs.sun.com/app/docs/doc/819-2240/zfs-1m
If you wa
On Feb 21, 2009, at 13:27, Tim wrote:
Well given that I *KNOW* Sun isn't making shit up as they go along,
and I
have *SEEN* some of their plans under NDA, I'll just outright call
bullshit.
I was trying to be nice about it. If you're making stuff up as you go
along that's likely why you're s
On Sat, Feb 21, 2009 at 12:18 PM, Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
>
> ZFS is principally already developed. It is now undergoing feature
> improvement, performance, and stability updates. Perhaps entries in the
> OpenSolaris bug tracking system may reveal what is requested
On Sat, 21 Feb 2009, Tim wrote:
No, he's not asking them to predict the future. Don't be a dick. He's
asking if they can share some of their intentions based on their current
internal roadmap. If you're telling me Sun doesn't have a 1yr/2yr/3yr
roadmap for ZFS I'd say we're all in some seriou
On Sat, Feb 21, 2009 at 11:26 AM, Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
> On Sat, 21 Feb 2009, David Abrahams wrote:
>
>>
>>> If you want to do back ups of your file system use a documented
>>> utility (tar, cpio, pax, zip, etc.).
>>>
>>
>> Well understood. But does anyone know t
On Sat, 21 Feb 2009, David Abrahams wrote:
If you want to do back ups of your file system use a documented
utility (tar, cpio, pax, zip, etc.).
Well understood. But does anyone know the long-term intentions of
the ZFS developers in this area? The one big disadvantage of the
It would be nice
David Magda ee.ryerson.ca> writes:
> > The format of the [zfs send] stream is evolving. No backwards
> > compatibility is guaranteed. You may not be able to receive your
> > streams on future versions of ZFS.
>
> http://docs.sun.com/app/docs/doc/819-2240/zfs-1m
>
> If you want to do back
On Wed, 18 Feb 2009 11:27:38 -0800, Joe S wrote:
> I appreciate the feedback.
>
> I've decided to:
>
> * create daily ZFS snapshots and zfs send these to separate external
> disks (via esata).
I'll be interested in hearing anything you learn about eSata on Solaris. I
haven't used eSata anywhe
I appreciate the feedback.
I've decided to:
* create daily ZFS snapshots and zfs send these to separate external
disks (via esata).
* create monthly full backups via rsync, tar, or amanda on separate
external disks.
I'm not going to store everything on S3, it is too expensive. However,
I will ke
> "fc" == Frank Cusack writes:
> "dd" == David Dyer-Bennet writes:
fc> If you go to a future version of zfs, simply replace all your
fc> "full" filesystem streams with new ones,
I still think you should not be storing these streams at all, for
reasons you describe later.
fc
On Tue, February 17, 2009 16:56, Joe S wrote:
> I have an OpenSolaris snv_105 server at home that holds my photos,
> docs, music, etc, in a zfs pool. I backup my laptops with rsync to the
> OpenSolaris server. All of my important data is in one place, on the
> OpenSolaris server. I want to backup
Once again, I find I have to correct myself:
If you go to a future version of zfs, simply replace all your "full"
filesystem streams with new ones, and then of course start new
incrementals. Any reasonable backup procedure probably involves starting
new full backups at regular intervals anyway,
On February 17, 2009 3:57:34 PM -0800 Joe S wrote:
On Tue, Feb 17, 2009 at 3:35 PM, David Magda wrote:
If you want to do back ups of your file system use a documented utility
(tar, cpio, pax, zip, etc.).
I'm going to try to use Amanda and backup my data (not snapshots).
You missed the poin
On February 17, 2009 6:35:12 PM -0500 David Magda
wrote:
On Feb 17, 2009, at 17:56, Joe S wrote:
Does that sound like a viable backup solution?
It has been explicitly stated numerous times that the output of 'zfs
send' has no guarantees and it is undocumented. From zfs(1M):
The format of t
On Tue, Feb 17, 2009 at 3:35 PM, David Magda wrote:
> On Feb 17, 2009, at 17:56, Joe S wrote:
>
>> Does that sound like a viable backup solution?
>
> It has been explicitly stated numerous times that the output of 'zfs send'
> has no guarantees and it is undocumented. From zfs(1M):
>
>> The format
On Feb 17, 2009, at 17:56, Joe S wrote:
Does that sound like a viable backup solution?
It has been explicitly stated numerous times that the output of 'zfs
send' has no guarantees and it is undocumented. From zfs(1M):
The format of the [zfs send] stream is evolving. No backwards
compatib
29 matches
Mail list logo
