On 11/03/08 13:18, Philip Brown wrote:
Ok, I think I understand. You're going to be told
that ZFS send isn't a backup (and for these purposes
I definately agree), ...
Hmph. well, even for 'replication' type purposes, what I'm talking about is
quite useful.
Picture two remote systems, wh
> Ok, I think I understand. You're going to be told
> that ZFS send isn't a backup (and for these purposes
> I definately agree), ...
Hmph. well, even for 'replication' type purposes, what I'm talking about is
quite useful.
Picture two remote systems, which happen to have "mostly identical" dat
Ok, I think I understand. You're going to be told that ZFS send isn't a backup
(and for these purposes I definately agree), but if we ignore that this sounds
like you're talking about restoring a snapshot from an external media, and then
running a clone off that.
Clone's are already supported,
> If
> I'm interpreting correctly, you're talking about a
> couple of features, neither of which is in ZFS yet,
...
> 1. The ability to restore individual files from a
> snapshot, in the same way an entire snapshot is
> restored - simply using the blocks that are already
> stored.
>
> 2. The a
>> If the file still existed, would this be a case of redirecting the
>> file's top level block (dnode?) to the one from the snapshot? If the
>> file had been deleted, could you just copy that one block?
>>
>> Is it that simple, or is there a level of interaction between files
>> and snapshots tha
Ross Smith wrote:
>> Snapshots are not replacements for traditional backup/restore features.
>> If you need the latter, use what is currently available on the market.
>> -- richard
>>
>
> I'd actually say snapshots do a better job in some circumstances.
> Certainly they're being used that way
> Snapshots are not replacements for traditional backup/restore features.
> If you need the latter, use what is currently available on the market.
> -- richard
I'd actually say snapshots do a better job in some circumstances.
Certainly they're being used that way by the desktop team:
http://blogs.
Ross Smith wrote:
> Hi Darren,
>
> That's storing a dump of a snapshot on external media, but files
> within it are not directly accessible. The work Tim et all are doing
> is actually putting a live ZFS filesystem on external media and
> sending snapshots to it.
>
Cognitive disconnect, again.
Hi Darren,
That's storing a dump of a snapshot on external media, but files
within it are not directly accessible. The work Tim et all are doing
is actually putting a live ZFS filesystem on external media and
sending snapshots to it.
A live ZFS filesystem is far more useful (and reliable) than a
Ross wrote:
> Ok, I see where you're coming from now, but what you're talking about isn't
> zfs send / receive. If I'm interpreting correctly, you're talking about a
> couple of features, neither of which is in ZFS yet, and I'd need the input of
> more technical people to know if they are possi
Ok, I see where you're coming from now, but what you're talking about isn't zfs
send / receive. If I'm interpreting correctly, you're talking about a couple
of features, neither of which is in ZFS yet, and I'd need the input of more
technical people to know if they are possible.
1. The abilit
> Ah, there is a cognitive disconnect... more below.
>
> The cognitive disconnect is that snapshots are
> blocks, not files.
> Therefore, the snapshot may contain only changed
> portions of
> files and blocks from a single file may be spread
> across many
> different snapshots.
I was referring
Ah, there is a cognitive disconnect... more below.
Philip Brown wrote:
>> relling wrote:
>> This question makes no sense to me. Perhaps you can
>> rephrase?
>>
>>
>
> To take a really obnoxious case:
> lets say I have a 1 gigabyte filesystem. It has 1.5 gigabytes of physical
> disk allocate
> So, when I do a zfs receive, it would be "really
> nice", if there were some way for zfs to figure out,
> lets say, "recieve to a snapshot of the filesystem;
> then take advantage of the fact that it is a
> snapshot, to NOT write on disk, the 9 unaltered files
> that are in the snapshot; just all
> relling wrote:
> This question makes no sense to me. Perhaps you can
> rephrase?
>
To take a really obnoxious case:
lets say I have a 1 gigabyte filesystem. It has 1.5 gigabytes of physical disk
allocated to it (so it is 66% full).
It has 10x100meg files in it.
"Something bad happens", and I
> > 2.2 do a receive of an earlier zfs send, to
> either a snapshot or a "child" filesystem, and be
> efficient about disk space used. ie: have the recieve
> understand, "hey, I have that file already,
> completely intact, so I'm not going to waste space by
> storing it again".
> >
ZFS alread
Philip Brown wrote:
> I've recently started down the road of production use for zfs, and am hitting
> my head on some paradigm shifts. I'd like to clarify whether my understanding
> is correct, and/or whether there are better ways of doing things.
> I have one question for replication, and one qu
I've recently started down the road of production use for zfs, and am hitting
my head on some paradigm shifts. I'd like to clarify whether my understanding
is correct, and/or whether there are better ways of doing things.
I have one question for replication, and one question for backups.
These qu
18 matches
Mail list logo
