My last-night's posted question on mirroring suggested ZFS as easiest way.

So, how to get ZFS.

Right now, I have 9. (Have been negligent not going to 10.)

Questions:

1: should I go to 10, or straight to "11"?

2: the suggested ZFS, suggested not quite ready yet, what about that?

3: with ZFS, is letting someone login to one of its padded-cells

100% (99.99%) safe, in that he can't access anything

you don't want him to?

4: If ZFS isn't fully out yet, when might it be?

David

PS: any decent s10 books yet coming out? (I will

periodically be asking this same question.)

My last-night's posted question on mirroring suggested ZFS as easiest way.

So, how to get ZFS.

Right now, I have 9. (Have been negligent not going to 10.)

Questions:

1: should I go to 10, or straight to "11"?

2: the suggested ZFS, suggested not quite ready yet, what about that?

3: with ZFS, is letting someone login to one of its padded-cells

100% (99.99%) safe, in that he can't access anything

you don't want him to?

4: If ZFS isn't fully out yet, when might it be?

The only caveat to ZFS is that the root file system must still be on

UFS.

On Fri, 4 Apr 2008, David Combs wrote:

Time to mothball that ancient stuff! ­

Get the latest version of Nevada (build 85 as I type). I've used

nothing but various builds of Nevada on my desktop for about 2 years.

Ditto for my (non-technical) wife.

ZFS is very much ready for production use!

I think you might be confusing ZFS the file system with Zones the

virtulaisiation/com­partmentalisation technology. Something running

in a zone is indeed 100% safe in the sense you mention.

ITguy wrote:

Oh? Last I heard, Sun had not yet released a means of backing up a ZFS

file sytem to tape. There is ufsbackup but no zfsbackup! You can make

a "snapshot" to a direct access device (disk) but not, AFAIK to tape.

That seems like a pretty big caveat to me!

What do people using ZFS do in lieu of sending tapes off site for

disaster recovery purposes? Ufsbackup of the snapshot?

Oh? Last I heard, Sun had not yet released a means of backing up a

ZFS file sytem to tape. There is ufsbackup but no zfsbackup! You can

make a "snapshot" to a direct access device (disk) but not, AFAIK to

tape.

That seems like a pretty big caveat to me!

What do people using ZFS do in lieu of sending tapes off site for

disaster recovery purposes? Ufsbackup of the snapshot?

"Richard B. Gilbert" <rgilber...@comcast­.net> writes:

There are commercial options (Legato Networker), but there are also

simple solutions as well.

First of all, the "zfs send" and "zfs receive" commands are similar in

functionality to ufsbackup/ufsrestor­e, but without an incremental

mode.

On my own systems, I use:

- Frequent cron-driven snapshots. They're cheap and easy.

- Mirrored pools, because I don't like losing things.

- A simple script that does zfs send into a file, compresses, then

writes out to tape.

Richard B. Gilbert schrieb:

zfs send/receive

unfortunaly it seems not 100% save:

http://www.zdnet.de­/security/analysen/0­,39029458,39186609,0­0.htm

Tobias Klein seems to have found a kernel exploit to gain access to the global

zone from non-global zone.

On Sat, 5 Apr 2008, Wolfgang wrote:

Interesting. Alas, I don't speak Deutch, so I can't read it...

Yes but as I read it you have to have zfs (the program) "on the end"

to receive the send. I sent a snapshot earlier to a remote machine

and captured it with "dd" instead. Trying to pipe that 'image' back

went nowhere.

I get part of that but not exactly how you extract off tape the "file"

or how you create the file in the first place.... : >

O Im talking SPARC here if that makes a difference

Also the man pages say:

"The format of the stream is evolving. No backwards compati-

bility is guaranteed. You may not be able to receive your

streams on future versions of ZFS." So if something changes in 6

months your

ZFS backups to tape are useless?? Say it aint so!

On 2008-04-06 19:38:21 +0100, Rich Teer <rich.teer@rite-gro­up.com> said:

The (google translated) article doesn't go into any detail. Perhaps you

had to be at the IT Defense (sic) conference...

Cheers,

Chris

On Sat, 5 Apr 2008, Wolfgang wrote:

Interesting. Alas, I don't speak Deutch, so I can't read it...

usenetpersonger...@­gmail.com writes:

It's just a byte stream. Write it anywhere that's convenient.

If you've had trouble with it, I suggest contacting Sun's support

group. There's no magic here; the commands are supposed to work. (I

haven't had trouble with it, but that doesn't mean you haven't found a

problem.)

I don't quite understand the question. It's roughly like this:

zfs send -i last-snapshot z/myfs@backup-snaps­hot | bzip2 > \

incremental-myfs.bz­2

tar -c5 .

Pulling it back in is just as easy; "tar r" to pull the file in, and

bunzip2 -c | zfs receive to recover the snapshot.

No ... it has nothing to do with SPARC versus x86. It works the same

on both.

That's (unfortunately) correct, which is why I said I do this:

- Occasional backups of whole file systems to DVD.

... in the part that you snipped. It's particularly important to do a

full backup before an upgrade.

For what it's worth, I've recovered things from backup, but I haven't

run into any versioning problems.

--

James Carlson, Solaris Networking <james.d.carl...@su­n.com>

Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084

MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

On Apr 7, 8:14 am, James Carlson <james.d.carl...@su­n.com> wrote:

Which I did. Now what to do with it.

Someone says - Hey we need a file from last week could you get it off

tape for us?? send/receive seems to only work on whole snapshots or

increments of whole snapshots...

Have to skip using bzip2 as it takes hours? to compress a 4 GB file..?

Not terribly backup friendly (although making the snap certainly is)

Again what if you dont want the entire thing - just a list of file or

directories

which is a more typical request.. Retreive fu/bar from dweezles data

dir

dated 2 days ago please

is accomplished how from a full or incremental zfs snap direct to pool/

fu?

Even a Blu-Ray wont be big enough. Not by a long shot.

Imagine how long that would take to write : <

As always : >

Anyway it was snipped because Im not talking about teeny weenie

workstation files here.

And JUST when you thought you were safe... : >

In the meantime I see that one can simply tar off to tape any ZFS

volume

just like you can UFS - gee wouda thunk it.. But the snaps are

not the same. zfs snap should emulate fssnap ideally - and it does not

does it?

usenetpersonger...@­gmail.com writes:

Just pull in the whole snapshot, use "zfs promote" to turn it into a

file system, and then copy out the files you want.

I suspect that there's an underlying problem here, and that's

incorrect (or just incomplete) use of ZFS. The design of ZFS strongly

encourages the use of lots of *small* file systems, rather than a few

huge ones.

If you're having trouble manipulating huge snapshots, it could be

because you haven't factored out the file systems well enough yet.

At least for me, I don't care how long that bzip2 runs. It's running

off of a snapshot, which is effectively instantaneous. All that it

needs to do is complete before the next backup run.

Pull in the snapshot. Mount it up. Make the files available.

There's no support for getting just a couple of files ... but I

haven't seen that as a serious limitation in any of my use.

In any event, it sounds like we're at least talking about different

administrative environments. Perhaps you'd be more comfortable with

something like Legato.

It's not too hard to break things up. Yes, it does take a long time

to write 100GB or more, and I wish I had fancier backup equipment than

DVD+DDS2. ;-}

If you've got huge *files*, you're in trouble no matter what you do.

ufsdump backs up things by inode -- which means it backs up on a

per-file basis. Even incrementals are going to be huge.

I've used both, and I think it's far easier to understand and use ZFS

snapshots than fssnap. The ZFS ones are more like what you'd find on

an external NFS storage device.

usenetpersongerryt@­gmail.com writes:

Just pull in the whole snapshot, use "zfs promote" to turn it into

a file system, and then copy out the files you want.

Chris Ridd schrieb:

unfortunaly i have also not found more information about that in the

net, but this link. But in the mentioned conference, he talked about

kernel exploits. And it is mentioned that the exploit is from 2007 and

seems still not be fixed .... no good news.

James Carlson <james.d.carl...@su­n.com> wrote innews:xoavabk4bejp­.fsf@sun.com:

Who has enough spare disk space laying around to do that? When my

Oracle dba wants a single 10MB file from a 1.5TB filesystem, you can

see how silly that strategy is.

It's like Sun just doesn't get how their customers use their

systems. All they need to do is give me something with the same

functionality that ufsdump/ufsrestore have (table of contents at the

start of a dump, ability to restore only parts of a dump, etc) and I

can use zfs in production systems.

On Apr 9, 5:32 am, Steve van der Burg <steve.vanderb...@l­hsc.on.ca>

wrote:

I think James has conceded that Enterprise environments have

different requirements than his workstation : >

Yes it seems insane to me as well that a zeta filesystem prefers

things small..

And that there is no zfsbackup/zfsretore­ with snap capabilities.

Or a read-only mode during backup or something - kinda like Oracles

RMAN..

File an RFE? But really its an obvious need.

How could something so basic be missed?

usenetpersonger...@­gmail.com writes:

I'm not using Oracle, but several of the machines I manage are much

bigger than just a workstation. Not that you asked ...

I still don't understand how UFS has any real advantage in the

particular situation you've described.

If you have huge files -- which you've already said is the issue at

hand -- then ufsdump is going to create *HUGE* incrementals. Just

touching the big file will cause it to appear in your incremental

backups and will force you to extract the whole thing.

There's no "win" that I can see there. You'll need just as much

storage to recover an incremental backup of a huge file as you will

to do "zfs receive" on a snapshot with a huge file in it.

Actually, it's slightly worse with UFS, because you cannot pool your

storage, and need separate slices for each mount point. ZFS does pool

storage, and doesn't need (or want) separate slices.

If the issue is that you've got a directory with a mix of huge files

that never change (?!) and tiny ones that do, then perhaps the

application is intelligent enough to relocate these to separate

directories. If so, then you can use separate ZFS file systems to

optimize the backup/restore requirements.

In any event, this all sounds like an overconstrained problem to me.

Talk to your local support folks. Really. If you discover that

there's something missing, then you *NEED* to talk to them.

If you don't want to do that, then perhaps you could talk to the ZFS

developers directly -- zfs-disc...@opensol­aris.org. I'm sure they'd

be keenly interested in learning what they missed in development.

With ufsdump/restore I feel its easier to deal with single files

directories etc.

No need to promote.

My concern was with backups and how snaps behave with ZFS.

With UFS, how would you do the backup? Would you store the huge

file that ufsdump creates on tape? How would you do single file

restores in that case?