Change "When to Backup" to (my preference) "After each successful Backup
Schedule." Set an appropriate media for Media 1 and Media 2.
Hope this helps. --Jim
> ----------
> From: Norm Szcyrek[SMTP:nszcyrek AT iocenter DOT net]
>
> When reviewing my "All Log Entries" report, I'm getting the following
> message:
>
> WARNING: NetBackup database backup is currently disabled
>
> How do I reset the configuration to allow the automatic NB database
> backups again? I am able to perform manual backups without any
> complaints.
>
From the second sentence of the white paper:
"With an archive life of 30 years"
-----Original Message-----
From: Dayne Medlyn [mailto:dayne_medlyn AT agilent DOT com]
Sent: Wednesday, April 19, 2000 3:38 PM
To: Roy Vosberg
Cc: 'Barry Ard'; veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Expiration Dates
Does this really say anything?? It suggests that tape life is 10 years,
but they never fully qualify this. If the tapes are exercised, they
have a fairly long life. But sitting on the shelf is a bit different.
Numbers I have seen suggest 7 year shelf life. Perhaps someone knows
something else more concrete.
Roy Vosberg wrote:
>
> The Quantum website is a good source for DLT and storage info:
>
> http://www.quantum.com/src/whitepapers/wp_tapedurability.htm
>
> -----Original Message-----
> From: Barry Ard [mailto:Barry.Ard AT ualberta DOT ca]
> Sent: Tuesday, April 18, 2000 5:00 PM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] Expiration Dates
>
> With all this talk about 7 year expiration dates got me wondering
> about how long is the data on the tape good for when just sitting
> on the shelf. In our shop we are using DLT7000 tapes. (fujis I think)
> --
> Barry Ard Barry.Ard AT UAlberta DOT CA
> Administrative Information Systems
> University of Alberta
> Edmonton, Alberta Canada
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
From my understanding NBU does system level permissions, the daemon runs as
root when a backup is done as a scheduled backup, and runs as the user when
the backup is executed on the client by a user.
I believe that the files will be backed up, but the user will not be able to
restore the file back to it's original place due to the fact that the user
may not have write permissions on the file.
The file also may not be backed up rather the name may just be backed up due
to the fact that the user does not have read permissions on the file.
I would look through the log to find out what files are complaining, and
then look at the ownership of the files and the permissions set to the file
compared to the writes of the user.
I don't normally work with the user directed backup portion of NBU I spend
more of my time on the Scheduled backups, so I may be wrong, but this is my
gut feel.
Bob
-----Original Message-----
From: Andrew Steingruebl [mailto:steingra AT pprd.abbott DOT com]
Sent: Monday, February 14, 2000 10:25 AM
To: Robert Bakh
Cc: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Problems with IRIX-6.5.3 clients and user
direct ed backups
How then can the users view, delete, etc. the files and the directories? I
went through this with tech-support on my previous case I opened. I su'd to
the user, and even logged in directly as them. I was able to create files,
delete files, etc. I do understand Unix permissions afterall.
How can I figure out exactly what the problem is, that is, what permission
the
backup software doesn't like, etc.
- Andy Steingruebl
Robert Bakh said:
>Try running the backup as root.
>
>It seems to be a simple permissions issue
>
>Bob
>
>-----Original Message-----
>From: Andrew Steingruebl [mailto:steingra AT pprd.abbott DOT com]
>Sent: Monday, February 14, 2000 9:37 AM
>To: veritas-bu AT mailman.eng.auburn DOT edu
>Subject: [Veritas-bu] Problems with IRIX-6.5.3 clients and user directed
>backups
>
>
>I'm getting the following in client side logs when backing up an IRIX-6.5.3
>client to a Solaris server, both running NB-3.2.
>
>11:34:29 WRN - attr_list (0x3) failed on /exp/olympia.1/FILENAME. Errno =
1:
>
>Operation not permitted
>
>replace FILENAME with a real filename. I'm getting it for a whole slew of
>files being backed up. The files appear to actually get backed up, but the
>errors concern me because the users doing the backups then wonder whether
>their backup was successful.
>
>I've submitted this one as an issue to Veritas, but if anyone knows the
>answer
>and could share/fix, I'd be very happy.
>
>Thanks.
>
>--
>Andy Steingruebl | e-mail: steingra AT pprd.abbott DOT com
>
>Unix Systems Admin/Programmer | phone: (847) 935-4728
>Unix/Network Security | fax: (847) 935-0142
>Abbott Laboratories, PPDR&D | post: 100 Abbott Park Road, D472 - AP9A
> | Abbott Park, IL 60064-6115
>
>
>
>_______________________________________________
>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>_______________________________________________
>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
From the netbackup perspective all hard links are not equal. I think
what happens is that when netbackup traverses the filesystem, it
writes the file to tape when it encounters the first hard link to it.
When it encounters additional hard links to the same file, netbackup
records them as pointers to the first copy on tape.
Handling hard links in this way can lead to at least two types of
problems. If you try to restore a single file, and the name you ask
for was not the hard link that netbackup encountered first when doing
the backup, then netbackup will not restore the file. This happens
because at that point on the tape netbackup has found a pointer
instead of your data.
There is also some way to do a restore where you end up with two
separate files even though the originals were hardlinks to each other.
I cannot remember the mechanism for causing this problem at the
moment.
Going back to your original email, I was suprised at the work around
you mentioned which was to restore to an alternate path. I would not
have thought that would help. What I think should solve the problem
would be to restore all of the names which were links to the file you
want. I would do the restore to an alternate location, and I think if
you try all the names for the file, you should get your data.
One other note, I believe these behaviors for handling links are
behaviors inherited from GNU tar, which netbackup uses to write its
data.
--------------------------------------------------
Jonathan Meyer
(781)398-6594
UNIX Systems Administrator
Paramtric Technology Corporation
--------------------------------------------------
From a DR specialty, I tend to take a tape out and rotate now and again.
You never know whats around the corner...... !!
Good Luck ! and remember.... NBU is a long term investment - plan for
your future backups now, rather than wait until disk capacity is full
:-)
Regards
Simon Weaver
3rd Line Technical Support
Windows Domain Administrator
EADS Astrium Limited, B23AA IM (DCS)
Anchorage Road, Portsmouth, PO3 5PU
Email: Simon.Weaver at Astrium-eads.net
<mailto:Simon.Weaver at Astrium-eads.net>
-----Original Message-----
From: Anas Kayal [mailto:anas at up.org.qa]
Sent: 11 December 2006 09:46
To: Veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] FW: Running out of disk space
That's was great help guys. Thanks a lot. I'll be adding 2 new
disks at the end of the day just to be on the safe side and I plan on
backing up to a second tape. Is there any need to be removing any one of
these tapes to my remote site or should I just keep these 2 tapes in the
library at all times?
Thanks again guys.
Anas Kayal
IT Department
Urban Planning and Development Authority
________________________________
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of WEAVER,
Simon
Sent: Monday, December 11, 2006 12:17 PM
To: 'Veritas-bu at mailman.eng.auburn.edu'
Subject: [Veritas-bu] FW: Running out of disk space
Ok that is the reason you are low on space :-)
what I recommend, is alternating your catalog backups to 2
tapes, and make sure both tapes are in the NetBackup volume pool.
Once this is in place, you can safely delete the contents in
c:\crts\catlg backup. In fact, if you look in here, find a file called
HEADER.
Regards
Simon Weaver
3rd Line Technical Support
Windows Domain Administrator
EADS Astrium Limited, B23AA IM (DCS)
Anchorage Road, Portsmouth, PO3 5PU
Email: Simon.Weaver at Astrium-eads.net
<mailto:Simon.Weaver at Astrium-eads.net>
-----Original Message-----
From: Anas Kayal [mailto:anas at up.org.qa]
Sent: 11 December 2006 09:06
To: WEAVER, Simon; Veritas-bu at mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Running out of disk space
It has 2 options. The first media type is disk and that
goes to c:\vrts\catlg backup. The second one goes to removable media
which is located in the netbackup volume pool.
Anas Kayal
IT Department
Urban Planning and Development Authority
________________________________
This email (including any attachments) may contain confidential and/or
privileged information or information otherwise protected from
disclosure.
If you are not the intended recipient, please notify the sender
immediately, do not copy this message or any attachments and do not use
it for any purpose or disclose its content to any person, but delete
this message and any attachments from your system.
Astrium disclaims any and all liability if this email transmission was
virus corrupted, altered or falsified.
---------------------------------------------------------------------
Astrium Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS,
England
This mail has been scanned by Symantec Mail Security for SMTP at
UP.ORG.QA
This email (including any attachments) may contain confidential and/or
privileged information or information otherwise protected from
disclosure.
If you are not the intended recipient, please notify the sender
immediately, do not copy this message or any attachments and do not use
it for any purpose or disclose its content to any person, but delete
this message and any attachments from your system.
Astrium disclaims any and all liability if this email transmission was
virus corrupted, altered or falsified.
---------------------------------------------------------------------
Astrium Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS,
England
This mail has been scanned by Symantec Mail Security for SMTP at UP.ORG.QA
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20061211/e345bcad/attachment-0001.html
From what I understand, when you hit a checkpoint, the current fragment
is completed, then a marker "checkpoint" is written, then another
fragment begins.
In other words, I don't believe checkpoints will work unless you have a
fragment size specified. Even then, if your fragment size is large
compared to the amount of data on the client you're backing up, then it
may not be worthwhile.
I don't know a whole lot of detail about them, other than that.
Paul
--
-----Original Message-----
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Clooney,
David
Sent: December 11, 2006 6:59 AM
To: Veritas-bu at mailman.eng.auburn.edu
Subject: [Veritas-bu] Checkpoint on backups.
Hi,
Can anyone give a brief explanation of exactly what goes on when
checkpoint's are implemented on normal backup schedules. Understand what
they do but need to know what is going on in the background.
Cheers
Dave
====================================================================================
La version fran?aise suit le texte anglais.
------------------------------------------------------------------------------------
This email may contain privileged and/or confidential information, and the Bank
of
Canada does not waive any related rights. Any distribution, use, or copying of
this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately
from
your system and notify the sender promptly by email that you have done so.
------------------------------------------------------------------------------------
Le pr?sent courriel peut contenir de l'information privil?gi?e ou
confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute
diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires d?sign?s est interdite. Si vous
recevez
ce courriel par erreur, veuillez le supprimer imm?diatement et envoyer sans
d?lai ?
l'exp?diteur un message ?lectronique pour l'aviser que vous avez ?limin? de
votre
ordinateur toute copie du courriel re?u.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20061211/036e199c/attachment.html
|
