|
|
| Reporter | Ruth Ivimey-Cook | Assigned To | bruno-at-bareos | |
|---|
| Priority | normal | Severity | feature | Reproducibility | always |
|---|
| Status | closed | Resolution | won't fix | |
|---|
| Platform | amd64 | OS | Linux | OS Version | Ubuntu 20.04 |
|---|
| Product Version | 19.2.9 | |
|---|
|
|
| Summary | 0001311: Continue spooling from client while previous spool being written |
|---|
| Description | I 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 Reproduce | A 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 Information | There 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. |
|---|
| Tags | No tags attached. |
|---|
|
|
