Re: [zfs-discuss] Best choice - file system for system
Torrey McMahon tmcmah...@yahoo.com wrote: On 1/30/2011 5:26 PM, Joerg Schilling wrote: Richard Ellingrichard.ell...@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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
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 Ellingrichard.ell...@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@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
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 Ellingrichard.ell...@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@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
On 2011-Jan-28 21:37:50 +0800, Edward Ned Harvey opensolarisisdeadlongliveopensola...@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 pgppzMAxBmwjV.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
On Mon, Jan 31, 2011 at 3:47 AM, Peter Jeremy peter.jer...@alcatel-lucent.com wrote: On 2011-Jan-28 21:37:50 +0800, Edward Ned Harvey opensolarisisdeadlongliveopensola...@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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
On 1/30/2011 5:26 PM, Joerg Schilling wrote: Richard Ellingrichard.ell...@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@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
From: Peter Jeremy [mailto:peter.jer...@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.%. 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. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@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. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
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, ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
On 28/01/2011 13:37, Edward Ned Harvey wrote: From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] 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? f...@ll ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
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 bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@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. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best choice - file system for system
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-boun...@opensolaris.org [mailto:zfs-discuss- boun...@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. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
