Veritas-bu

[Veritas-bu] interesting behaviour with NDMP and NFS backups

2006-02-14 12:05:58
Subject: [Veritas-bu] interesting behaviour with NDMP and NFS backups
From: Mark.Donaldson AT cexp DOT com (Mark.Donaldson AT cexp DOT com)
Date: Tue, 14 Feb 2006 10:05:58 -0700
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C63188.8C9314E0
Content-Type: text/plain;
        charset="iso-8859-1"

I can blame my keyboard today for the mistakes below, it's a loaner:
 
s/ tries to reverse / tries to reverse that change  /
s/ untouched, but / untouched, by /
 
I now return you to your regularly scheduled list.

-----Original Message-----
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On Behalf Of Donaldson, 
Mark
- Broomfield, CO
Sent: Tuesday, February 14, 2006 9:28 AM
To: pkeating AT bank-banque-canada DOT ca; veritas-bu AT mailman.eng.auburn DOT 
edu
Subject: RE: [Veritas-bu] interesting behaviour with NDMP and NFS backups


The touch that netbackup does during backups is to reset the atime (last
access time) value of the file backed up.  When you read a file for any
reason, including backups, the OS sets the atime to the current time.  NB
tries to reverse, so your filesystem appears to be untouched, but reading
the atime, backing up the file, and then setting the atime back to initial
value.
 
If you've got a read-only filesystem, the third step fails (which is OK,
since the atime was read-only in the first place and wasn't altered by the
backup).  The message is annoying, though.
 
The constant writes to modify atime is a performance problem, though, on an
NFS r/w mounted filesystem.
 
-M

-----Original Message-----
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On Behalf Of Paul Keating
Sent: Tuesday, February 14, 2006 6:20 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] interesting behaviour with NDMP and NFS backups


Discovered something in the lab that I found interesting...
if I back up a NAS via NDMP (level 0), then do a FULL backup of the same
unix style QTree, via NFS, a few hours later.
subsequent level 1 NDMP backups backup *almost* the entire QTree.
 
It seems as if the NFS backup tweaks each file enough that the Level 1 NDMP
dump sees it as new/modified.
 
Not really interesting I suppose, in that it's pretty obvious that NBU is
touching files (try doing an NFS backup of a RO FS.).
 
Just something I noticed and thought I'd throw out there for anyone who
happens to be doing both (for whatever reason) and theought there would be
no interdependancy.
 
Paul


------_=_NextPart_001_01C63188.8C9314E0
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1515" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=830160317-14022006><FONT face=Arial color=#0000ff size=2>I can 
blame my keyboard today for the mistakes below, it's a 
loaner:</FONT></SPAN></DIV>
<DIV><SPAN class=830160317-14022006><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=830160317-14022006><FONT face=Arial color=#0000ff size=2>s/ 
tries to reverse / tries to reverse that change&nbsp; /</FONT></SPAN></DIV>
<DIV><SPAN class=830160317-14022006><FONT face=Arial color=#0000ff size=2>s/ 
untouched, but / untouched, by /</FONT></SPAN></DIV>
<DIV><SPAN class=830160317-14022006><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=830160317-14022006><FONT face=Arial color=#0000ff size=2>I now 
return you to your regularly scheduled list.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> 
  veritas-bu-admin AT mailman.eng.auburn DOT edu 
  [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]<B>On Behalf Of 
</B>Donaldson, 
  Mark - Broomfield, CO<BR><B>Sent:</B> Tuesday, February 14, 2006 9:28 
  AM<BR><B>To:</B> pkeating AT bank-banque-canada DOT ca; 
  veritas-bu AT mailman.eng.auburn DOT edu<BR><B>Subject:</B> RE: [Veritas-bu] 
  interesting behaviour with NDMP and NFS backups<BR><BR></FONT></DIV>
  <DIV><SPAN class=453130716-14022006><FONT face=Arial color=#0000ff size=2>The 
  touch that netbackup does during backups is to reset the atime (last access 
  time) value of the file backed up.&nbsp; When you read a file for any reason, 
  including backups, the OS sets the atime to the current time.&nbsp; NB tries 
  to reverse, so your filesystem appears to be untouched, but reading the 
atime, 
  backing up the file, and then setting the atime back to initial 
  value.</FONT></SPAN></DIV>
  <DIV><SPAN class=453130716-14022006><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=453130716-14022006><FONT face=Arial color=#0000ff size=2>If 
  you've got a read-only filesystem, the third step fails (which is OK, since 
  the atime was read-only in the first place and wasn't altered by the 
  backup).&nbsp; The message is annoying, though.</FONT></SPAN></DIV>
  <DIV><SPAN class=453130716-14022006><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=453130716-14022006><FONT face=Arial color=#0000ff size=2>The 
  constant writes to modify atime is a performance problem, though, on an NFS 
  r/w mounted filesystem.</FONT></SPAN></DIV>
  <DIV><SPAN class=453130716-14022006><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=453130716-14022006><FONT face=Arial color=#0000ff 
  size=2>-M</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> 
    veritas-bu-admin AT mailman.eng.auburn DOT edu 
    [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]<B>On Behalf Of 
</B>Paul 
    Keating<BR><B>Sent:</B> Tuesday, February 14, 2006 6:20 AM<BR><B>To:</B> 
    veritas-bu AT mailman.eng.auburn DOT edu<BR><B>Subject:</B> [Veritas-bu] 
    interesting behaviour with NDMP and NFS backups<BR><BR></FONT></DIV>
    <DIV><SPAN class=969261413-14022006><FONT face=Arial size=2>Discovered 
    something in the lab that I found interesting...</FONT></SPAN></DIV>
    <DIV><SPAN class=969261413-14022006><FONT face=Arial size=2>if I back 
    up&nbsp;a NAS via NDMP (level 0), then do a FULL backup of the same unix 
    style QTree, via NFS, a few hours later.</FONT></SPAN></DIV>
    <DIV><SPAN class=969261413-14022006><FONT face=Arial size=2>subsequent 
level 
    1 NDMP backups backup *almost* the entire QTree.</FONT></SPAN></DIV>
    <DIV><SPAN class=969261413-14022006><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=969261413-14022006><FONT face=Arial size=2>It seems as if 
    the NFS backup tweaks each file enough that the Level 1 NDMP dump sees it 
    as&nbsp;new/modified.</FONT></SPAN></DIV>
    <DIV><SPAN class=969261413-14022006><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=969261413-14022006><FONT face=Arial size=2>Not really 
    interesting I suppose, in that it's pretty obvious that NBU is touching 
    files (try doing an NFS backup of a RO FS.).</FONT></SPAN></DIV>
    <DIV><SPAN class=969261413-14022006><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=969261413-14022006><FONT face=Arial size=2>Just something 
I 
    noticed and thought I'd throw out there for anyone who happens to be doing 
    both (for whatever reason) and theought there would be no 
    interdependancy.</FONT></SPAN></DIV>
    <DIV><SPAN class=969261413-14022006><FONT face=Arial 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=969261413-14022006><FONT face=Arial 
    size=2>Paul</FONT></SPAN></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C63188.8C9314E0--

<Prev in Thread] Current Thread [Next in Thread>