View Issue Details

IDProjectCategoryView StatusLast Update
0001311bareos-coredirectorpublic2024-03-27 15:10
ReporterRuth Ivimey-Cook Assigned Tobruno-at-bareos  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionwon't fix 
Platformamd64OSLinuxOS VersionUbuntu 20.04
Product Version19.2.9 
Summary0001311: Continue spooling from client while previous spool being written
DescriptionI need to use the spool feature, because the tape is faster than the clients, and that is fine. However, the backups take much longer because the client data is not pulled while the spool file is being written.

Permitting two spool files (or N files) for a single client would enable the client to be backed up independently of the speed of the tape, at the cost, obviously, of spool file space.

In general, there could be N files per client and M clients being backed up; whether it is worth supporting this general case I don't know, but there would be benefits to many sites with just a two file option. If done, I would expect settings to control both N and M both as numbers of spool files, and as total size of spooled data. Once the spool partition or setting size limit is reached, the client is just paused, as is true now.
Steps To ReproduceA setup with a client spooling to bareos at a speed slower than tape.
A spool file on an SSD.
A backup larger than the spool file.
The client is read, then waits, then is read, then waits, ...

If double buffered spool is permitted, the client is read, tape write starts, is read again (during which tape completes), is read again .... and no client waiting.
Additional InformationThere could be a case for starting to write to tape as soon as the spool file exists, but I think that would not help; it merely ties up the drive sooner.
TagsNo tags attached.

Activities

bruno-at-bareos

bruno-at-bareos

2021-11-08 09:21

manager   ~0004318

Related to https://github.com/bareos/bareos/pull/886
bruno-at-bareos

bruno-at-bareos

2024-03-27 15:10

manager   ~0005876

We will closing as won't fix here. It will not be developed without some kind of community support or sponsoring.
It is still an interesting idea, which may become a feature request in the soon opened github issues tracking.

Issue History

Date Modified Username Field Change
2021-01-19 03:02 Ruth Ivimey-Cook New Issue
2021-01-19 03:18 Ruth Ivimey-Cook Issue cloned: 0001312
2021-11-08 09:21 bruno-at-bareos Note Added: 0004318
2024-03-27 15:10 bruno-at-bareos Assigned To => bruno-at-bareos
2024-03-27 15:10 bruno-at-bareos Status new => closed
2024-03-27 15:10 bruno-at-bareos Resolution open => won't fix
2024-03-27 15:10 bruno-at-bareos Note Added: 0005876