Hi Jean- François,
From: "Jean-Francois Malouin" <[email protected]> To: "amanda-users" <[email protected]> Cc: "Chris Miller" <[email protected]> Sent: Monday, November 19, 2018 12:18:16 PM Subject: Re: Taper scan algorithm did not find an acceptable volume. BQ_BEGIN Read 'man amanda-taperscan' for the details. BQ_END This was very helpful. BQ_BEGIN You can check which 'tapes' amanda expects for the next run with the command 'amadmin <CONFIG> tape', running it as the amanda user. BQ_END I am told "The next Amanda should go onto 1 new tape.", so I assume that this is an estimate of tape demands for immediate planning purposes. In my case, I am configured for vtapes of 2TB, so this is not telling me anything I don't already know. But... BQ_BEGIN Also, 'amtape <CONFIG> inventory' will tell you what amanda is aware of. This info is based on the cached meta-info for the changers, and might not be accurate (stale). 'amtape <CONFIG> update' will force a rescan of the (virtual) changer. BQ_END "amtape <CONFIG> update" tells me:"ERROR: 'chg-disk' does not support update", which I guess does not surprise me. "amtape <CONFIG> inventory" tells me: slot 0: label <CONFIG>.0 (current) [other config] slot 1: label <CONFIG>.1 [other config] : slot 21: label <CONFIG>.21 [other config] So, my problem is that AMANDA does not want to advance. Let me explain. Last week I did a first backup for three clients, and AMANDA interpreted that as three level 0 dumps, two of which were written to vtape. The third is still "stuck" on the holding disk. So that is my first mystery. Why did this not complete and what can I do about it? Subsequently, I requested a second backup of all three clients, which AMANDA interpreted as three level 1 dumps. To nobody's surprise, none of these has been written to vtape and they all remain on the holding disk. And that is my second mystery. Why is "slot1" not a valid tape for any of these and what can I do about it? Thanks for the help, Jean- François. -- Chris. V:916.974.0424 F:916.974.0428
