Hi Jason,
Thanks for your reply. Please see my comments below in the red color.
Thanks,
Srinivas Rao
Philips Software Centre,
Bangalore, INDIA.
Ph: +91 80 25579000 Extn: 1133
Cell: +91 99457 23423
----- Original Message -----
From: "Jason Koelker" <jkoelker AT RACKSPACE DOT COM>
To: <NETWORKER AT LISTSERV.TEMPLE DOT EDU>
Sent: Tuesday, March 21, 2006 12:31 PM
Subject: Re: [Networker] Queries regarding backup....
> On Tue, 2006-03-21 at 10:23 +0530, Srinivas Rao wrote:
> > 1. What is the logic behind incremental / differential backups?
> An incremental backup will backup all files since the last backup,
> regaurdless of the level of that last backup.
>
> A differential backup will backup all files since the last backup of a
> lower level. For example if you run a level 9 diff backup it will
> backup all the files that have changed since you ran a level full or
> level 1-8.
>
> > How does the Networker know whether or not the file has backedup earlier
> > and with what level?
>
> It looks at the change time of the file and compares that to the date of
> the last backup and the level. It is important to note that NetWorker
> does not honor the archive bit, although I believe it will reset it on
> filesystems that support it.
>
> > 2. Does it check each and every file to prepare the list of items to be
> > backedup with incremental or differential backup?
>
> Yes, run save with the '-vvv' option and you will see it build the file
> list. What it does is as it walks the tree, it compares the ctime to
> that of the last backup. Then based on the level of the current and
> previous backup, either selects the file to be saved or skips it.
>
> > 3. One of our backup engineer aborted inventory operation in progress and
> > because of this Networker did not pick up tapes for scheduled backups and
> > it did not allow us to do any other operation(labeling etc..due to message
> > "Inventory operation already in progress"). However I could see media
> > pending requests in the monitor window. Why did it happen?
>
> Aborted how? Did they make sure that the nsrjb command was killed, or
> just use NMC/'other retarded utility' to "stop" the inventory.
He aborted the inventory operation by clicking 'close' button(nwadmin GUI)
while the inventory operation is in progress.
>
> Most likely the nsrjb command that the GUI fired off was still running.
> Its important to note that NetWorker works through the firing off of
> many different commands. The GUI's just wrap this into a shiny point
> and click for the PHB's to look at.
>
> I would also assume you only have one tape drive, as others should have
> picked up the slack for the one doing the inventory if they were there,
> but that all depends on your config.
We are using SDLT autochangers with two drives and 25 slots in each. Why does
Networker need am empty drive to perform inventory operation although media
database was already updated with tape labels? (I have many times seen during
inventory operation if both the drives are filled with media, then Networker
ejects a tape and then performs inventory operation. According to me, if we use
a new media then NW has to update that information in the media database and
hence it needs an empty drive to read media label. But if we are using the old
media whose media label is already in the media database, Networker should do
the inventory operation without ejecting the tape...isn't it?).
>
> > 4. Why index is always being written with level 9?
>
> This is due to a incr or differential backup being run. Indexes of full
> backups will be written with level full.
As you said index is written with level9 for incremental and differential
backups and with level full with every full backup. What is the logic behind
this?
Why is the status of index saveset is always 'recov' instead of 'brows'?
>
> > 5. Why does Networker write indexes from the Networker server to tape
> > media after backing up the client?
>
> Because only then is the index complete and able to be written. You
> really don't want your indexes all fragmented on tape. So since it
> can't know what is coming down the pipe, it builds the index as the
> datastream is happening, once the backup is finished, only then can it
> write the full index to tape all in one shot.
I do not understand this. Could you please explain in detail. What is the use
of writing indexes to tapes when it is available in the Networker Server until
browse policy period?
>
> > Why is Networker slow with restorations??
>
> Use linux/solaris for your networker servers, period. ;)
>
> Assuming you are already using a Unix like NetWorker environment,
> restore time is highly dependant on the filesystem of your client, and
> its ability to open and close file descriptors rapidly.
>
> If your running linux on your clients, don't use ext3, its a decent
> filesystem for general use, but you'll get better performance out of an
> alternative filesystem like xfs, jfs, or reiser. If you must use ext3,
> then make sure you tune it accordingly to the type of data you are
> storing. If your running Windows/NTFS, run away. Its performance, is
> dreadful.
>
> The type of files you restore also have bering on the speed. A folder
> that contains 1G of 1k gif images will take around 1-3 hours to restore.
> A 1G file that is a solid file, will only take a matter of minutes. Its
> all about the data stream. With small files, the data stream starts,
> streams, stops, filesystem flushes, starts, streams, stop, flush, start,
> stream, stop, flush, etc. Large files start, stream, stream, stream,
> stream, stream, stop, flush. The filesystem and the OS have to deal
> with much less overhead.
>
> Another thing to consider is when/how you do your backups. Since
> writing to tape is a linear operation, data must be multiplexed into a
> single data stream. When many backups are happening all at once, your
> data stream becomes fragmented, therefore on the restore end, you will
> spend more time seeking on the tape as it demultiplexes the data, than
> if you had a single constant data stream.
>
> Just as a sugestion, I would spend a night, with a good strong cup of
> coffee, and a pack of cigarettes (you'll need them ;), and read all the
> NetWorker man pages starting with nsr(1) following through all the "See
> Also"'s. Contrary to popular belief NetWorker is extremly well
> documented, and the man pages provide valuable insight into the nitty
> gritty of NetWorker. Although some of them do need some updating and
> better documentation, aghem like the ebnf's scatter throughout being
> incomlete, they are thousands times better than the 'Admin Guide'.
>
> Have a good one!
>
> Jason
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and
> type "signoff networker" in the
> body of the email. Please write to networker-request AT listserv.temple DOT
> edu if you have any problems
> wit this list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
