zfs discuss - Dec 2010 - Best choice - file system for system

Hi,
I wonder what is the better option to install the system on solaris ufs 
and zfs sensitive data on whether this is the best all on zfs?
What are the pros and cons of such a solution?

For at ll

On Wed, 8 Dec 2010, Albert wrote:
> I wonder what is the better option to install the system on solaris ufs and
> zfs sensitive data on whether this is the best all on zfs?
> What are the pros and cons of such a solution?
The best choice is usually to install with zfs root on a mirrored pair 
of disks.  UFS is going away as a boot option.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
> bounces at opensolaris.org] On Behalf Of Bob Friesenhahn
> 
> The best choice is usually to install with zfs root on a mirrored pair
> of disks.  UFS is going away as a boot option.
UFS is already unavailable as a boot option.  It''s only still available
if
you''re using something old, such as solaris 10u9.  (Which is the latest
solaris.)   ;-)

Seriously though.  UFS is dead.  It has no advantage over ZFS that I''m
aware
of.

The only situation I can think of where UFS would be advantageous over 
ZFS might be in a low memory situation.  ZFS loves memory.

But to answer the original question, ZFS is where you want to be.

Jerry


On 12/08/10 20:56, Edward Ned Harvey wrote:
>> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
>> bounces at opensolaris.org] On Behalf Of Bob Friesenhahn
>>
>> The best choice is usually to install with zfs root on a mirrored pair
>> of disks.  UFS is going away as a boot option.
>
> UFS is already unavailable as a boot option.  It''s only still
available if
> you''re using something old, such as solaris 10u9.  (Which is the
latest
> solaris.)   ;-)
>
> Seriously though.  UFS is dead.  It has no advantage over ZFS that
I''m aware
> of.
>

I don''t disagree that zfs is the better choice, but...
> Seriously though.  UFS is dead.  It has no advantage
> over ZFS that I''m aware
> of.
> 
When it comes to dumping and restoring filesystems, there is still no official
replacement for the ufsdump and ufsrestore.  The discussion has been had before,
but to my knowledge, there is no consensus on the best method for backing up zfs
filesystems.

Personally, I like to use variations on zfs send and zfs receive, but others
will tell a different story.

Still, don''t let this put you off using zfs as the root filesystem. 
Just be aware that you need to do some work and decide what method of backup is
best for you.
-- 
This message posted from opensolaris.org

> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
> bounces at opensolaris.org] On Behalf Of Tristram Scott
> 
> When it comes to dumping and restoring filesystems, there is still no
official
> replacement for the ufsdump and ufsrestore.  
Let''s go into that a little bit.  If you''re piping zfs send
directly into
zfs receive, then it is an ideal backup method.  But not everybody can
afford the disk necessary to do that, so people are tempted to "zfs
send" to
a file or tape.  There are precisely two reasons why that''s not
"officially"
recommended:
1- When you want to restore, it''s all or nothing.  You can''t
selectively
restore a single file.
2- When you want to restore, it''s all or nothing.  If a single bit is
corrupt in the data stream, the whole stream is lost.

Regarding point #2, I contend that zfs send is better than ufsdump.  I would
prefer to discover corruption in the backup, rather than blindly restoring
it undetected.  Also, since the invention of zstreamdump, you are able to
detect any corruption during stream generation...  And you are able to
verify integrity of a stream after it is written to its destination.  All of
this serves to minimize the importance of point #2.

Regarding point #1, I''ll agree ufsdump has an advantage, which is
ability to
do a selective restore.  Again, ZFS does have an answer to this, which is to
pipe the send directly into a receive.  Not always possible, but that''s
the
answer.

On 01/28/11 02:37 PM, Edward Ned Harvey wrote:
> Let''s go into that a little bit.  If you''re piping zfs
send directly into
> zfs receive, then it is an ideal backup method.  But not everybody can
> afford the disk necessary to do that, so people are tempted to "zfs
send"
> to
> a file or tape.  There are precisely two reasons why that''s not
> "officially"
> recommended:
> 1- When you want to restore, it''s all or nothing.  You
can''t selectively
> restore a single file.
> 2- When you want to restore, it''s all or nothing.  If a single bit
is
> corrupt in the data stream, the whole stream is lost.
>
> Regarding point #2, I contend that zfs send is better than ufsdump.  I
> would
> prefer to discover corruption in the backup, rather than blindly restoring
> it undetected.  Also, since the invention of zstreamdump, you are able to
> detect any corruption during stream generation...  And you are able to
> verify integrity of a stream after it is written to its destination.  All
Hi,

Be careful with zstreamdump, it has bug, at least in build 134, and I 
see the related CR is still open 
(http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6933259).

Regards,

On 28/01/2011 13:37, Edward Ned Harvey wrote:
>> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
>> bounces at opensolaris.org] On Behalf Of Tristram Scott
>>
>> When it comes to dumping and restoring filesystems, there is still no
> official
>> replacement for the ufsdump and ufsrestore.
>
> Let''s go into that a little bit.  If you''re piping zfs
send directly into
> zfs receive, then it is an ideal backup method.  But not everybody can
> afford the disk necessary to do that, so people are tempted to "zfs
send" to
> a file or tape.  There are precisely two reasons why that''s not
"officially"
> recommended:
"Officially" yes you have it in quotes but where is the official 
reference for this ?

In fact I''d say the opposite.  In Solaris 11 Express the NDMP daemon
can
backup using dump, tar or zfs send stream.

This is also what the ''Sun ZFS Storage Appliance'' does see
here:

http://www.oracle.com/technetwork/articles/systems-hardware-architecture/ndmp-whitepaper-192164.pdf

On page 8 of the PDF titled: "About ZFS-NDMP Backup Support"

It does point out though that it is full ZFS dataset only, but 
incremental backup and incremental restore is supported.

This has been tested and is known to work with at least the following 
backup applications:

? Oracle Secure Backup 10.3.0.2 and above
? Enterprise Backup Software (EBS) / Legato Networker 7.5 and above
? Symantec NetBackup 6.5.3 and above


-- 
Darren J Moffat

On Jan 27, 2011, at 4:34 AM, Tristram Scott wrote:
> I don''t disagree that zfs is the better choice, but...
> 
>> Seriously though.  UFS is dead.  It has no advantage
>> over ZFS that I''m aware
>> of.
>> 
> 
> When it comes to dumping and restoring filesystems, there is still no
official
> replacement for the ufsdump and ufsrestore.  The discussion has been had
> before, but to my knowledge, there is no consensus on the best method for
> backing up zfs filesystems.
ufsrestore works fine on ZFS :-)

But seriously, this is why we wrote the section in the ZFS Best Practices Guide
talking about traditional backup/restore.
http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Using_ZFS_With_Enterprise_Backup_Solutions
Updates are graciously appreciated.
 -- richard

On 2011-Jan-28 21:37:50 +0800, Edward Ned Harvey
<opensolarisisdeadlongliveopensolaris at nedharvey.com>
wrote:
>2- When you want to restore, it''s all or nothing.  If a single bit
is
>corrupt in the data stream, the whole stream is lost.
>
>Regarding point #2, I contend that zfs send is better than ufsdump.  I would
>prefer to discover corruption in the backup, rather than blindly restoring
>it undetected.
OTOH, it renders ZFS send useless for backup or archival purposes.

With ufsdump, I can probably recover most of the data off a backup
even if it has some errors.  Since I''m aware of that problem, I can
separately store a file of expected checksums etc to verify what I
restore.  If I lose a file from one backup, I can hopefully retrieve
it from another backup.

With ZFS send, a 1-bit error renders my multi-GB backup useless.  I
can''t get ZFS to restore the rest of the backup and tell me what is
missing - which might let me recover it in other ways.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110131/33b6ae6b/attachment.bin>

On Mon, Jan 31, 2011 at 3:47 AM, Peter Jeremy
<peter.jeremy at alcatel-lucent.com> wrote:
> On 2011-Jan-28 21:37:50 +0800, Edward Ned Harvey
<opensolarisisdeadlongliveopensolaris at nedharvey.com> wrote:
>>2- When you want to restore, it''s all or nothing. ?If a single
bit is
>>corrupt in the data stream, the whole stream is lost.
>>
>>Regarding point #2, I contend that zfs send is better than ufsdump. ?I
would
>>prefer to discover corruption in the backup, rather than blindly
restoring
>>it undetected.
>
> OTOH, it renders ZFS send useless for backup or archival purposes.
... unless the backup/archive is also on zfs with enough redundancy
(e.g. raidz).

-- 
Fajar

On Jan 30, 2011, at 12:47 PM, Peter Jeremy wrote:
> On 2011-Jan-28 21:37:50 +0800, Edward Ned Harvey
<opensolarisisdeadlongliveopensolaris at nedharvey.com> wrote:
>> 2- When you want to restore, it''s all or nothing.  If a single
bit is
>> corrupt in the data stream, the whole stream is lost.
>> 
>> Regarding point #2, I contend that zfs send is better than ufsdump.  I
would
>> prefer to discover corruption in the backup, rather than blindly
restoring
>> it undetected.
> 
> OTOH, it renders ZFS send useless for backup or archival purposes.
> 
> With ufsdump, I can probably recover most of the data off a backup
> even if it has some errors.  Since I''m aware of that problem, I
can
> separately store a file of expected checksums etc to verify what I
> restore.  If I lose a file from one backup, I can hopefully retrieve
> it from another backup.
ufsdump is the problem, not ufsrestore. If you ufsdump an active
file system, there is no guarantee you can ufsrestore it. The only way
to guarantee this is to keep the file system quiesced during the entire
ufsdump.  Needless to say, this renders ufsdump useless for backup
when the file system also needs to accommodate writes.
> 
> With ZFS send, a 1-bit error renders my multi-GB backup useless.  I
> can''t get ZFS to restore the rest of the backup and tell me what
is
> missing - which might let me recover it in other ways.
Yes, these issues are discussed in the ZFS Best Practices Guide.
If you need an Enterprise Backup Solution, then use an Enterprise
Backup Solution.
 -- richard

Richard Elling <richard.elling at gmail.com> wrote:
> ufsdump is the problem, not ufsrestore. If you ufsdump an active
> file system, there is no guarantee you can ufsrestore it. The only way
> to guarantee this is to keep the file system quiesced during the entire
> ufsdump.  Needless to say, this renders ufsdump useless for backup
> when the file system also needs to accommodate writes.
This is why there is a ufs snapshot utility.

BTW: If it no already known, star does not yet support ZFS ACLs but it 
otherwise implements the ufsdump features in a file-system independent way.

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

On 1/30/2011 5:26 PM, Joerg Schilling wrote:
> Richard Elling<richard.elling at gmail.com>  wrote:
>
>> ufsdump is the problem, not ufsrestore. If you ufsdump an active
>> file system, there is no guarantee you can ufsrestore it. The only way
>> to guarantee this is to keep the file system quiesced during the entire
>> ufsdump.  Needless to say, this renders ufsdump useless for backup
>> when the file system also needs to accommodate writes.
> This is why there is a ufs snapshot utility.
You''ll have the same problem. fssnap_ufs(1M) write locks the file
system
when you run the lock command. See the notes section of the man page.

http://download.oracle.com/docs/cd/E19253-01/816-5166/6mbb1kq1p/index.html#Notes

> From: Peter Jeremy [mailto:peter.jeremy at alcatel-lucent.com]
> Sent: Sunday, January 30, 2011 3:48 PM
> 
> >2- When you want to restore, it''s all or nothing.  If a single
bit is
> >corrupt in the data stream, the whole stream is lost.
> >
> OTOH, it renders ZFS send useless for backup or archival purposes.
Not useless for backup purposes.  ZFS send is ideal for backup, as long as
you''re doing the zfs receive on-the-fly.  Naturally that cannot be done
while writing to tape.

Also not useless for archival purposes.  If you do a full ZFS send to tape
every week, then it means you never have any backup that depends on any
other backup, and you might estimate 1% probability of any one week''s
archive being corrupt.  If you need to restore a 3yr old backup, you might
be able to accept a tolerance of +/- 1 week with a probability of success
being 99.9999%.

Point is:  It''s all a calculation of risk, and every admin will choose
differently based on their localized constraints.  Don''t generalize and
use
absolute terms like "useless."

Personally, regarding backup reliability, I am more comfortable using "zfs
send" to tape instead of other tools like bacula, tar, star, cpio, etc...
Because I don''t have to tweak any parameters in order to know with
certainty
I''ve preserved all file and object characteristics and ACL''s
and so forth
which might not be clearly or well supported by those other tools.  To me,
the fear of unknown backup tools is higher than the fear of media
corruption.

To me, inability to do selective restore is a more important factor.
Selective restore is my reason for not streaming zfs send to tape.

Torrey McMahon <tmcmahon2 at yahoo.com> wrote:
> On 1/30/2011 5:26 PM, Joerg Schilling wrote:
> > Richard Elling<richard.elling at gmail.com>  wrote:
> >
> >> ufsdump is the problem, not ufsrestore. If you ufsdump an active
> >> file system, there is no guarantee you can ufsrestore it. The only
way
> >> to guarantee this is to keep the file system quiesced during the
entire
> >> ufsdump.  Needless to say, this renders ufsdump useless for backup
> >> when the file system also needs to accommodate writes.
> > This is why there is a ufs snapshot utility.
>
> You''ll have the same problem. fssnap_ufs(1M) write locks the file
system
> when you run the lock command. See the notes section of the man page.
>
>
http://download.oracle.com/docs/cd/E19253-01/816-5166/6mbb1kq1p/index.html#Notes
The time the write lock is active is from a few seconds to a few minutes.
If you like do backup the system root filesystem, you may need to stop 
logging/auditing for that time or split the mirror.

Once the snapshot is established, you may take as much time as your storage for 
the snapshot will last.

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Why do you say fssnap has the same problem?

If it write locks the file system, it is only for a matter of seconds, as I
recall.

Years ago, I used it on a daily basis to do ufsdumps of large fs''es.

Mark

On Jan 30, 2011, at 5:41 PM, Torrey McMahon wrote:
> On 1/30/2011 5:26 PM, Joerg Schilling wrote:
>> Richard Elling<richard.elling at gmail.com>  wrote:
>> 
>>> ufsdump is the problem, not ufsrestore. If you ufsdump an active
>>> file system, there is no guarantee you can ufsrestore it. The only
way
>>> to guarantee this is to keep the file system quiesced during the
entire
>>> ufsdump.  Needless to say, this renders ufsdump useless for backup
>>> when the file system also needs to accommodate writes.
>> This is why there is a ufs snapshot utility.
> 
> You''ll have the same problem. fssnap_ufs(1M) write locks the file
system when you run the lock command. See the notes section of the man page.
> 
>
http://download.oracle.com/docs/cd/E19253-01/816-5166/6mbb1kq1p/index.html#Notes
> 
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

A matter of seconds is a long time for a running Oracle database. The 
point is that if you have to keep writing to a UFS filesystem - "when 
the file system also needs to accommodate writes" - you''re still
out of
luck. If you can quiesce the apps, great, but if you can''t then
you''re
still stuck.  In other words, fssnap_ufs doesn''t solve the quiesce
problem.

On 1/31/2011 10:24 AM, Mark Sandrock wrote:
> Why do you say fssnap has the same problem?
>
> If it write locks the file system, it is only for a matter of seconds, as I
recall.
>
> Years ago, I used it on a daily basis to do ufsdumps of large
fs''es.
>
> Mark
>
> On Jan 30, 2011, at 5:41 PM, Torrey McMahon wrote:
>
>> On 1/30/2011 5:26 PM, Joerg Schilling wrote:
>>> Richard Elling<richard.elling at gmail.com>   wrote:
>>>
>>>> ufsdump is the problem, not ufsrestore. If you ufsdump an
active
>>>> file system, there is no guarantee you can ufsrestore it. The
only way
>>>> to guarantee this is to keep the file system quiesced during
the entire
>>>> ufsdump.  Needless to say, this renders ufsdump useless for
backup
>>>> when the file system also needs to accommodate writes.
>>> This is why there is a ufs snapshot utility.
>> You''ll have the same problem. fssnap_ufs(1M) write locks the
file system when you run the lock command. See the notes section of the man
page.
>>
>>
http://download.oracle.com/docs/cd/E19253-01/816-5166/6mbb1kq1p/index.html#Notes

iirc, we would notify the user community that the FS''es were going to
hang briefly.

Locking the FS''es is the best way to quiesce it, when users are
worldwide, imo.

Mark

On Jan 31, 2011, at 9:45 AM, Torrey McMahon wrote:
> A matter of seconds is a long time for a running Oracle database. The point
is that if you have to keep writing to a UFS filesystem - "when the file
system also needs to accommodate writes" - you''re still out of
luck. If you can quiesce the apps, great, but if you can''t then
you''re still stuck.  In other words, fssnap_ufs doesn''t solve
the quiesce problem.
> 
> On 1/31/2011 10:24 AM, Mark Sandrock wrote:
>> Why do you say fssnap has the same problem?
>> 
>> If it write locks the file system, it is only for a matter of seconds,
as I recall.
>> 
>> Years ago, I used it on a daily basis to do ufsdumps of large
fs''es.
>> 
>> Mark
>> 
>> On Jan 30, 2011, at 5:41 PM, Torrey McMahon wrote:
>> 
>>> On 1/30/2011 5:26 PM, Joerg Schilling wrote:
>>>> Richard Elling<richard.elling at gmail.com>   wrote:
>>>> 
>>>>> ufsdump is the problem, not ufsrestore. If you ufsdump an
active
>>>>> file system, there is no guarantee you can ufsrestore it.
The only way
>>>>> to guarantee this is to keep the file system quiesced
during the entire
>>>>> ufsdump.  Needless to say, this renders ufsdump useless for
backup
>>>>> when the file system also needs to accommodate writes.
>>>> This is why there is a ufs snapshot utility.
>>> You''ll have the same problem. fssnap_ufs(1M) write locks
the file system when you run the lock command. See the notes section of the man
page.
>>> 
>>>
http://download.oracle.com/docs/cd/E19253-01/816-5166/6mbb1kq1p/index.html#Notes