12-18-2017 11:40 PM
Hi,
I am trying to archive an NBU catalog.
I use the following link to do the actions:
https://www.veritas.com/support/en_US/article.TECH36433
only I have the error "exit status 227: no entity was found"
The netbackup job runs without errors but the return of the command outputs this error.
in the log bpdbm I have the following error:
"request complete: exit status 227 no entity was found"
if I run the following command: "bpcatlist -before 01 DEC 2007" I have backups that go back up.
i verify ths :"https://www.veritas.com/support/en_US/article.000020429" but the name of my master in bp.conf and this is not the ip adresse.
have you any idea ?
Thanks.
Solved! Go to Solution.
12-19-2017 11:27 PM
May I ask again - why do want to archive catalogs?
Have you had a look at and considered my suggestions in my post above?
There are better ways to deal with limited space on catalog filesystem:
1. Add more disk and move catalogs to new volume.
2. Try catalog compression.
3. Review retention levels - I have never heard of a legal requirement to keep information for more than 10 years.
Do you really want to take this chance knowing that something could go wrong? And knowing that you don't have any support from Veritas ?
If you want to know if anything has been archived previously, you can find the command in the Catalog Archive overview:
https://www.veritas.com/support/en_US/article.100016714.html
To determine what images have been previously archived and removed from disk, run the following command. # /usr/openv/netbackup/bin/admincmd/bpcatlist -offline
Note: This should return "no entity was found" if catalog archiving has not been previously run. For more information on what the fields in the bpcatlist
output indicate, refer to 000028580 in the Related Articles section.
12-18-2017 11:51 PM
I don't know how to assist without having insight into the full procedure that you followed - every single command and its output along with bpdbm log.
All I can say is that catalog archiving has the potential of causing major issues. If the archive tape is not taken care of and/or gets damage, you have no way of recovering catalogs. This can result in data loss.
(I have seen this where backup admins for some reason (despite proper media management procedures) could not locate the archive tape.)
You will also appreciate the fact that you have NO support from Veritas if anything goes wrong because of your EOSL 7.6 version.
There are better ways to deal with limited space on catalog filesystem:
1. Add more disk and move catalogs to new volume.
2. Try catalog compression.
3. Review retention levels - I have never heard of a legal requirement to keep information for more than 10 years.
12-19-2017 12:12 AM
when i do :
"bpcatlist -before 01 DEC 2007" i have no error in the log. :
09:21:13.838 [13522] <2> image_db: Q_IMAGE_LIST 09:21:13.843 [13522] <2> read_legacy_touch_file: Found /usr/openv/db/data/vxdbms.conf; requested from (vxdbms_conf.cpp.1529). 09:21:13.864 [13522] <2> DbmOdbcConnect::set_connection_id: -1 -> 355 09:21:16.934 [13522] <2> process_request: request complete: exit status 0 ; query type: 76 09:21:18.249 [2640] <2> vnet_pbxAcceptSocket: Accepted sock[9] from XXXXXXXXXXXX:35848 09:21:18.251 [13541] <2> logconnections: BPDBM ACCEPT FROM XXXXXXXXXX.35848 TO XXXXXXXXXXX.1556 fd = 9 09:21:18.251 [13541] <4> bpdbm: VERBOSE = 0 09:21:18.252 [13541] <2> get_user_identity: Using local Admin creds(user_identity.cpp:158) 09:21:18.312 [13541] <2> process_request: request complete: exit status 0 ; query type: 91 09:21:18.320 [2640] <2> vnet_pbxAcceptSocket: Accepted sock[9] from 132.169.100.61:60542 09:21:18.321 [13542] <2> logconnections: BPDBM ACCEPT FROM XXXXXXXXXXX.60542 TO XXXXXXXXX.1556 fd = 9 09:21:18.322 [13542] <4> bpdbm: VERBOSE = 0 09:21:18.322 [13542] <2> get_user_identity: Using local Admin creds(user_identity.cpp:158) 09:21:18.336 [13542] <2> process_request: request complete: exit status 0 ; query type: 91
but when i put verbose 5 and i run this commande agin, i have this :
"No data found when fetching from Join of DBM_Image, DbmImageCopy, DbmImageFragment"
Doyou know what this error mean ?
12-19-2017 12:13 AM
when i do :
"bpcatlist -before 01 DEC 2007" i have no error in the log. :
09:21:13.838 [13522] <2> image_db: Q_IMAGE_LIST 09:21:13.843 [13522] <2> read_legacy_touch_file: Found /usr/openv/db/data/vxdbms.conf; requested from (vxdbms_conf.cpp.1529). 09:21:13.864 [13522] <2> DbmOdbcConnect::set_connection_id: -1 -> 355 09:21:16.934 [13522] <2> process_request: request complete: exit status 0 ; query type: 76 09:21:18.249 [2640] <2> vnet_pbxAcceptSocket: Accepted sock[9] from XXXXXXXXXXXX:35848 09:21:18.251 [13541] <2> logconnections: BPDBM ACCEPT FROM XXXXXXXXXX.35848 TO XXXXXXXXXXX.1556 fd = 9 09:21:18.251 [13541] <4> bpdbm: VERBOSE = 0 09:21:18.252 [13541] <2> get_user_identity: Using local Admin creds(user_identity.cpp:158) 09:21:18.312 [13541] <2> process_request: request complete: exit status 0 ; query type: 91 09:21:18.320 [2640] <2> vnet_pbxAcceptSocket: Accepted sock[9] from 132.169.100.61:60542 09:21:18.321 [13542] <2> logconnections: BPDBM ACCEPT FROM XXXXXXXXXXX.60542 TO XXXXXXXXX.1556 fd = 9 09:21:18.322 [13542] <4> bpdbm: VERBOSE = 0 09:21:18.322 [13542] <2> get_user_identity: Using local Admin creds(user_identity.cpp:158) 09:21:18.336 [13542] <2> process_request: request complete: exit status 0 ; query type: 91
but when i put verbose 5 and i run this commande agin, i have this :
"No data found when fetching from Join of DBM_Image, DbmImageCopy, DbmImageFragment"
09:30:01.014 [16117] <2> DBEnumerator::move_next: SQL_SUCCESS 09:30:01.014 [16117] <2> fetch_DBM_AllImageCopyFrag: Entering 09:30:01.015 [16117] <2> fetch_DBM_AllImageCopyFrag: Success fetching (2) records from join of DBM_Image, DbmImageCopy, DbmImageFragment 09:30:01.015 [16117] <2> fetch_DBM_AllImageCopyFrag: Entering 09:30:01.015 [16117] <2> fetch_DBM_AllImageCopyFrag: No data found when fetching from Join of DBM_Image, DbmImageCopy, DbmImageFragment
Doyou know what this error mean ?
12-19-2017 12:45 AM
I don't see any error(s).
Everything is debug info <2>.
There are
no Warnings <8>
no Errors <16>
no Severe Errors <32>
Level 5 logs will show all the 'hidden' checks that are done. Whatever is searched for is clearly not perceived by NBU as a problem.
I cannot tell you what the entries in level 5 log mean.
That will be of interest to a Veritas backline support engineer should a problem be experienced.
12-19-2017 03:25 AM
Can you confirm exactly what you are doing.
Are you trying to run a new catalog archive, or trying to bring something back that was previously archived, or perhaps ....
just trying to run bpcatlist ???
Either way, I suspect the cararc image in the nbdb, is relating to an entry in the DB 'that does not exist'.
09:30:01.015 [16117] <2> fetch_DBM_AllImageCopyFrag: No data found when fetching from Join of DBM_Image, DbmImageCopy, DbmImageFragment
Suggests some issue/ corruption in NBDB.
Something likely happened in the past.
Eg.
NBU was upgraded to or above 7.5 with archived images (I think 7.5 was when the .catalog 'header' file was moved into the NBDB
Server has been renamed (even with catman / consulting, archived images need to be unarchived)
I suspect that when you trace an affected image through the nbdb_unload output, you will find inconsistancies.
Another very basic check:
If you search for 'Image not found during import' in the nbdb_unload output you will possibly find lines that match.
Either way, this sort of issue usually requires Engineering to fix.
12-19-2017 07:03 AM - edited 12-19-2017 07:30 AM
hello, I try to do new catalogue archive yes.
It is possible that the server is rename. How can you solve the problem if it is?
How can I do the search you are talking about (in the nbdb_unload)
How can i unarchived the archived images or list them ?
is it possible to know which images are problematic
12-19-2017 11:27 PM
May I ask again - why do want to archive catalogs?
Have you had a look at and considered my suggestions in my post above?
There are better ways to deal with limited space on catalog filesystem:
1. Add more disk and move catalogs to new volume.
2. Try catalog compression.
3. Review retention levels - I have never heard of a legal requirement to keep information for more than 10 years.
Do you really want to take this chance knowing that something could go wrong? And knowing that you don't have any support from Veritas ?
If you want to know if anything has been archived previously, you can find the command in the Catalog Archive overview:
https://www.veritas.com/support/en_US/article.100016714.html
To determine what images have been previously archived and removed from disk, run the following command. # /usr/openv/netbackup/bin/admincmd/bpcatlist -offline
Note: This should return "no entity was found" if catalog archiving has not been previously run. For more information on what the fields in the bpcatlist
output indicate, refer to 000028580 in the Related Articles section.
12-20-2017 01:07 AM
hello, I try to do new catalogue archive yes
>> OK, thanks
It is possible that the server is rename. How can you solve the problem if it is?
>> If it was renamed, was this done by consulting services ?
You say it is 'possible' can you confirm ?
How can I do the search you are talking about (in the nbdb_unload)
You run nbdb_unload /some/empty/directory
This unload nbdb into a load of xxx.dat files
You then goto /some/empty/directory and run grep -i "Image not found during import" *.dat
How can i unarchived the archived images or list them ?
bpcatlist shows archived images,
is it possible to know which images are problematic
Yes, bpcatlist command - if the image has a 'catarcID' it should be archived.
To unarchive images, you generaly use something like this:
bpcatlist -client all |bpcatres
As opposed to doing 'all' images, you can seect a date range, bpcatlit man page should show the options.
Generally, with these issues, we need SQL scripts to fix the NBDB. YOu can 'manually' unarchive an image by just browsing the catarc tapes an restore the .f files, this is ok as a workround, but leaves the NBDB in a bit of a mess.
12-20-2017 01:36 AM
Oh! If you look at the example in the doc that you are following, you will notice that your date format is wrong.
Example from KB article:
# bpcatlist -client <name> -before Jan 1 2000
Your command:
bpcatlist -before 01 DEC 2007
should therefore be:
bpcatlist -before Dec 01 2007
12-21-2017 12:11 AM
Hello, indeed for the date, but following test with the format indicated by the documentation, I have the same error.
Note that I recover this platform and I have great difficulty knowing what has been done.
Indeed in view of the error, I do not know if I will archive the data but rather try a compression.
But I would not want to leave mistakes "under the carpet" and using another method.
I have infinite retention and some backups date from the year 2000/2001. I would have wanted to archive this data in view of ancestry
I try "/usr/openv/netbackup/bin/admincmd/bpcatlist -offline " but i have : "no entity was found"
12-21-2017 12:18 AM
hello,
I tried the nbdb_unload command as shown.
Indeed, it generates a series of file "dat" but I can not find the chain "no entity was found" via the "grep".
I would have liked to be sure that I did not worry about the old archives. The data is quite sensitive and there is a real desire to keep infinite retention on these backups.
12-21-2017 05:52 AM
If you just run bpcatlist on it's own, then if you look to see if any image has a value other than 0 in the catarc column.
If 0, the image is not archived
If >0, then the image is archived
01-25-2018 01:43 AM
i finaly choose to compress
thanks all