cancel
Showing results for 
Search instead for 
Did you mean: 

I accidentally deleted shared folder in filer's configuration

AA11
Level 3

I accidentally deleted shared folder in filer's configuration.

When i add this share folder again, whole my base of information of last year is empty

Can i restore this information and apply old information to the share folder

4 REPLIES 4

Rod_p1
Level 6
Employee Accredited Certified

Is this something you yourself did or a consequence of the removal of a partially completed migration's database(s)?

Which folder are you speaking of?

 

Taking a guess at what you may have done. In the GUI you could have deleted a share. If you have the "Purge data for deleted shares/site collections automatically" setting in Data Retention enabled then the associated data would be removed from the index and you would no longer have the MSUID in the database. Restoring the data assuming a valid backup would not correct the issue since the share name removal from the configuration would also remove the ID association from the filer and MSU databases. You will need expert assistance to restore in this case and should go through Technical Support.

You may have deleted an index from the tree in the data directory rendering the application incapable of querying the index for any time scope. This would truly be a mistake, not require confirmation. A restore of the data removed would allow for resumption of the application features as designed although your time scope would be limited to the backed up data and may be days in the past. Any new audits that had been indexed between the backup window and the restore are lost forever. All metadata can be refreshed with the next scan performed.

If my guesses are off base please feel free to elaborate on the details so that we could dissect the problem and suggest likely scenarios for restoring your access to historical data.

 

Rod

hello, thank you for answer

I accidentally deleted shared folder by myself in the settings - filers - my server - <select ection> -delete, it was a miss click

i checked index in the SQL, and data is there

I add this shared folder again and share got a new "index number" is 6055

Then i changed this number in the SQL to my old share number "92", and then i saw my old data of scanning, i can take new repport until date of deleting share. But this share has an error is "this scan has one or more error", and it do not want to scan again, after full scan i got this error again

What can i to do now

I am afraid to apply a veritas support, cause it will be to much long, open a new case then wait few days or week for answer

also i have to add my log:

fileserver\C$\Program Files\DataInsight\log\scanner\ext19_msu92.rlog

2017-10-05 10:29:55 INFO: V-378-1310-5000: #{10664} [log_init: 86] log|Info|log_init|Logging initialized|scanner_revision=Aug 23 2017.

2017-10-05 10:29:55 INFO: V-378-1310-5005: #{10664} [eh_verbose: 44] veh|Success|AddVectoredExceptionHandler(1, veh_verbose)|eh_verbose.
2017-10-05 10:29:55 INFO: V-378-1310-5069: #{10664} [__db_select_str: 1210] db|Info|__db_select_str|col=root|colid=0|value=NULL|sqliterr=100.
2017-10-05 10:29:55 INFO: V-378-1310-5230: #{10664} [__traverse_filer_share_set: 569] traverse|Success|__traverse_filer_share_set|root=\\127.0.0.1\SHARE-FS_1-3|mx|sqliterr=0.
2017-10-05 10:29:55 INFO: V-378-1310-5553: #{10664} [__traverse_be_user: 5094] Scanning Local share
2017-10-05 10:29:55 INFO: V-378-1310-3764: #{10664} [__traverse_outdir_rights_check: 6602] traverse|Info|__traverse_outdir_rights_check|CreateFile(C:/DataInsight/data/outbox/)|h:0000000000000164
2017-10-05 10:29:55 INFO: V-378-1310-5436: #{10664} [__traverse_be_user: 5148] traverse|Success|__traverse_be_user|u=veritas|d=domain.local
2017-10-05 10:29:55 INFO: V-378-1310-5111: #{10664} [__traverse_backup_operator_enable: 1038] traverse|Success|__traverse_backup_operator_enable|ENABLED.
2017-10-05 10:29:56 ERROR: V-378-1310-5264: #{10664} [db_prep: 274] db|Failed|db_prep|sqlite3_prepare_v2|sql=SELECT id, pathname, type, timestamp FROM ipath WHERE id>:id LIMIT :max_rows|sqliterr=1.
2017-10-05 10:29:56 WARNING: V-378-1310-5026: #{10664} [__db_traverse_close: 193] db|Warning|db_traverse_close|prepare is null.
2017-10-05 10:29:56 INFO: V-378-1310-5029: #{10664} [__db_traverse_close: 230] db|Success|db_traverse_close.
2017-10-05 10:29:56 INFO: V-378-1310-5689: #{10664} [reh_verbose: 59] veh|Success|RemoveVectoredExceptionHandler|returncode=1.
2017-10-05 10:29:58 INFO: V-378-1310-5000: #{10520} [log_init: 86] log|Info|log_init|Logging initialized|scanner_revision=Aug 23 2017.

2017-10-05 10:29:58 INFO: V-378-1310-5005: #{10520} [eh_verbose: 44] veh|Success|AddVectoredExceptionHandler(1, veh_verbose)|eh_verbose.
2017-10-05 10:29:58 INFO: V-378-1310-5069: #{10520} [__db_select_str: 1210] db|Info|__db_select_str|col=root|colid=0|value=NULL|sqliterr=100.
2017-10-05 10:29:58 INFO: V-378-1310-5230: #{10520} [__traverse_filer_share_set: 569] traverse|Success|__traverse_filer_share_set|root=\\127.0.0.1\SHARE-FS_1-3|mx|sqliterr=0.
2017-10-05 10:29:58 INFO: V-378-1310-5553: #{10520} [__traverse_be_user: 5094] Scanning Local share
2017-10-05 10:29:58 INFO: V-378-1310-3764: #{10520} [__traverse_outdir_rights_check: 6602] traverse|Info|__traverse_outdir_rights_check|CreateFile(C:/DataInsight/data/outbox/)|h:0000000000000164
2017-10-05 10:29:58 INFO: V-378-1310-5436: #{10520} [__traverse_be_user: 5148] traverse|Success|__traverse_be_user|u=veritas|d=domain.local
2017-10-05 10:29:58 INFO: V-378-1310-5111: #{10520} [__traverse_backup_operator_enable: 1038] traverse|Success|__traverse_backup_operator_enable|ENABLED.
2017-10-05 10:29:58 ERROR: V-378-1310-5264: #{10520} [db_prep: 274] db|Failed|db_prep|sqlite3_prepare_v2|sql=SELECT id, pathname, type, timestamp FROM ipath WHERE id>:id LIMIT :max_rows|sqliterr=1.
2017-10-05 10:29:58 WARNING: V-378-1310-5026: #{10520} [__db_traverse_close: 193] db|Warning|db_traverse_close|prepare is null.
2017-10-05 10:29:58 INFO: V-378-1310-5029: #{10520} [__db_traverse_close: 230] db|Success|db_traverse_close.
2017-10-05 10:29:58 INFO: V-378-1310-5689: #{10520} [reh_verbose: 59] veh|Success|RemoveVectoredExceptionHandler|returncode=1.

Rod_p1
Level 6
Employee Accredited Certified

AA11, I am not sure which Geo you are in but if you call support and tell them the sequence of events they can assist you rather rapidly I suspect.

1) Your manual modification of the DB needs to be coordinated across the environment and not just on the indivual Winnas node.
2) You have the option to include both the historical share and new share in scoping your reporting so as to use both but combine the  results.

3) if the index remains behind then you have not enabled the removal of historical data but you should also have a new index with the MSUID related to the adding of the share back into the configuration. (I suspect you added the share back in manually and did not allow automatic discovery).

 

While you seem very comfortable in the application and underlying  architecture any manual intervention in the database needs to consider a lot of coordination. Had you made all the correct associations in the database to remedy the deletion  you still will likely end up in an unsupported configuration given the manual involvement in the databases and configuration. For the Winnas filer in question (device_ID not NodeID) you will need to check the logs for both the MSUIDs (92 and 6005) and confirm the updates are occurring in the scan .log, the auditing updates allowing the incremental scan .ilog to be occurring and not just the reconfirm process .rlog  which does not show the removal of all the previous data as no longer valid (expected since we check the index and compare the list to the existing data which is not deleted).

I am not sure how to help you further as we do not use the forum for troubleshooting support. Our Technicians would benefit greatly from an interactive discussion, current configuration and log data for debugging. The best advice I have for you is to start a support case with Veritas Technical Support and be very explicit with your issue (reference this conversation) and how you got there so they can immediately request the correct logging and configuration data (since time is of the essence) and seek advancement  to the appropriate resource.

 

Rod