 |
enabling NDMP debugging fatal error: NDMP protocol error, FHDB add_node request for unknown node |
|
|
Hi Marco, thanks for you answer. I have enabled debugging and snooping directive. In attachment the log. Can you take a look on this and check where is the problem ? you told me "NDMP library which seems to have some problem resolving the hostname" did you mean that the NDMP Datamover has some trouble to resolve its hostname or the Bareos Director/Storage Daemon ? Thanks and Regards |
|
|
Hello Marco, the problem seems to be related to the number of objects.... I have tried to backup a little sub folder ( 13MB) and backup is running fine. the folder size that previously I have tried to backup is 4 GB and have > 100.000 files my goal is to backup one fs of 2,5 TB and more than 4 milions of files..... are there some improvements/configurations that i need to change in order to be able to backup this filesystem via ndmp ? Build OS: x86_64-redhat-linux-gnu redhat CentOS Linux release 7.0.1406 (Core) JobId: 61 Job: VNXNDMPBackup.2015-04-17_12.24.14_04 Backup Level: Full (upgraded from Incremental) Client: "server_2" FileSet: "NDMP Fileset" 2015-04-17 12:24:14 Pool: "NDMPStoragePool" (From Job resource) Catalog: "MyCatalog" (From Client resource) Storage: "NDMPStorage-1" (From Pool resource) Scheduled time: 17-Apr-2015 12:24:13 Start time: 17-Apr-2015 12:24:16 End time: 17-Apr-2015 12:24:22 Elapsed time: 6 secs Priority: 10 NDMP Files Written: 539 SD Files Written: 1 NDMP Bytes Written: 0 (0 B) SD Bytes Written: 10,644,619 (10.64 MB) Rate: 0.0 KB/s Volume name(s): ndmp-0007 Volume Session Id: 2 Volume Session Time: 1429264970 Last Volume Bytes: 12,475,661,851 (12.47 GB) Termination: Backup OK |
|
|
Add: every time the job finish in status erred ( es. 62 Full VNXNDMPBackup.2015-04-17_12.32.48_04 has erred) I need to restart the SD because cancel job doesn't work. Regards Michele |
|
|
I closed this bug as its the same a bug 330. It also has little to do with the amount of data saved more with the fact that some NDMP implementations when sending the NDMP FH DATA records send things out of order e.g. the elements of a directory before the actual directory. The way thing are currently are implemented this means that it will try aborting the backup as it cannot handle this. For bug 330 there is a patch in 14.2 and master that allows you to set the "savefilehistory" to "false" in the job definition which should work around this problem. This only means that single file restore won't work but with the mentioned amount of files that is questionable if that will work well anyway. |
|
|
Hi Marco, when I wrote you last time, i already had tested the savefilehistory option without good result. I found that the problem was caused by a file level replication process from one emc array to another emc array ( where i'm reading the data via ndmp). I have now succesfully backed up the data. I have a couple of question : 1) is it possible to restore the ndmp backup to the file daemon as a normal file backup ? I have tried to save in native format, dump, tar etc but when i have restored the data on the FD I saw that is not possible browsing files or directory 2) I have succesfully backed up 71 GB in 22 minutes that is not bad but is there some fine tuning that can improve the backup speed ? ndmp I/O size or anything else ? |
|
|
Hi Marco, you can close the ticket. Thanks and Regards |
|
|
NDMP data is saved as opaque data so it can only be restored by a NDMP data agent. As such the content cannot be restore in any by a native backup filedaemon. The only real thing you can do is bextract the actual NDMP stream and use that as input on the NDMP box. People have done that restoring their NetAPP SM_TAPE NDMP backups. As to speed it may help if you spool data but that is mostly for writing directly to tape. Other then that is kind of depends on the network, filesystem you write your backup to or tape speed and of course the speed in which the source system provides the data. As to recordsize that is something you have to test it kind of depends as always. |
- Anonymous
