View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000622||bareos-core||[All Projects] director||public||2016-02-19 15:01||2019-01-16 13:30|
|Status||resolved||Resolution||no change required|
|Platform||vmware||OS||2.6.32-504.8.1.el6.x86_64||OS Version||Springdale 6.6|
|Target Version||Fixed in Version|
|Summary||0000622: Long period of no "activity" during large (10 TB) backup|
We have a Netapp that has a 10TB volume.
I am able to backup and restore using smaller volumes using NDMP (That's pretty awesome; the docs were great).
The "problem" is that for an amount of time, 0000008:0000014 hours, bareos-dir goes to 100% cpu, and nothing is put into the logs.
If there is a way of figuring out if bareos-dir is still "working" on something that would be great to know.
I chose a priority of "high" for this because it's important to me. I don't know if this would fall under a "support / documentation issue" or a "feature request issue."
|Steps To Reproduce||Back up a 10TB volume with lots of files / directories.|
|Additional Information||I am very pleased by how well bareos works and how easy it was to set up.|
|Tags||No tags attached.|
I would like to inform you that we have done quite some enhancements for ndmp backups with a large number of files.
The current nightly builds contain already that code:
It would be nice if you could test the new code in your environment and give feedback.
Thank you very much,
I'm closing this issue, as there has not been any new information for a long time and there is nothing we can do right now.
If you can provide additional information concerning this issue, please feel free to reopen the bug.
|2016-02-19 15:firstname.lastname@example.org||New Issue|
|2016-02-25 17:18||maik||Status||new => acknowledged|
|2016-05-18 11:02||pstorz||Note Added: 0002276|
|2016-05-18 11:02||pstorz||Assigned To||=> pstorz|
|2016-05-18 11:02||pstorz||Status||acknowledged => feedback|
|2019-01-16 13:30||arogge||Note Added: 0003190|
|2019-01-16 13:30||arogge||Status||feedback => resolved|
|2019-01-16 13:30||arogge||Resolution||open => no change required|