On 5/9/19 5:41 PM, David Brodbeck wrote:
> On Wed, May 1, 2019 at 3:14 PM Phil Stracchino wrote:
>> Surely you could have just bscanned the media you had?
>>
... Obviously now that
> the SQLite rug is going to be pulled out from under me I may have to
> revisit the bscan idea.
I haven't tried t
Apparently so.
I've been digging for recipes to do that. Is the old advice to use vchanger
still best, or does Bacula's native autochanger support make that obsolete?
I'm running v9.4.
On Fri, May 10, 2019 at 1:52 AM Kern Sibbald wrote:
> Hello,
>
> If you are doing any kind of "copy" of data (
You can get "Connection reset by peer" on Linux even within a single process
as follows:
0. Suppose A and B are two file descriptors connected by a socket.
1. Write a byte to A.
2. Close B.
3. Read a byte from A. This fails with "Connection reset by peer" rather than
getting EOF. You do get E
Hello Martin,
This is an interesting reflection. Do you think it is a timeout, or an
out and out bug where Bacula gets confused with additional
communications? A bug would be a bit hard to understand, because the
SD often waits for a Volume to be mounted -- of course, there can
certainly be bug
I'm pretty sure the "Connection reset by peer" error is a Bacula bug,
triggered when a Copy job waits in the middle for a new tape to write.
This is causing the Copying Error status.
__Martin
> On Fri, 10 May 2019 00:19:54 +0200, Andras Horvai said:
>
> hi,
>
> anybody, any idea regardin
Hello,
If you are doing any kind of "copy" of data (Migration, Copy,
VirtualFull, ...), it seems to me to be obvious, but perhaps I am
mistaken, you need two different Storage daemon device definitions
-- one to read a Volume, and one to write to a different Volume.
