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.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
