Mandi! Rados??aw Korzeniewski
In chel di` si favelave...
> Because of this. To make Virtual Full Bacula needs to read all backup jobs
> starting from Full, Diff and all Incrementals. Your Full (as volume
> suggests) is stored on Obito_Full_0001 which has an improper media type.
> Correct your configuration and backups and start again.
I'm really getting mad. This make sense for the behaviour (the first
VirtualFull worked because read full and incremental for the same pool) but
still the docs confuse me.
https://www.bacula.org/9.4.x-manuals/en/main/Migration_Copy.html
Say in 'Migration and Copy':
For migration to work properly, you should use Pools containing only Volumes
of the same Media Type for all migration jobs.
but in 'Important Migration Considerations':
* Each Pool into which you migrate Jobs or Volumes must contain Volumes of
only one Media Type.
[...]
* Bacula currently does only minimal Storage conflict resolution, so you must
take care to ensure that you don't try to read
and write to the same device or Bacula may block waiting to reserve a drive
that it will never find.
In general, ensure that all your migration pools contain only one Media
Type, and that you always migrate to pools with different Media Types.
and in 'Virtual Backup Consolidation':
In some respects the Virtual Backup feature works similar to a Migration job,
in that Bacula normally reads the data from the pool
specified in the Job resource, and writes it to the Next Pool specified in the
Job resource. Note, this means that usually the output
from the Virtual Backup is written into a different pool from where your prior
backups are saved. Doing it this way guarantees that you
will not get a deadlock situation attempting to read and write to the same
volume in the Storage daemon. If you then want to do
subsequent backups, you may need to move the Virtual Full Volume back to your
normal backup pool. Alternatively, you can set your
Next Pool to point to the current pool. This will cause Bacula to read and
write to Volumes in the current pool. In general, this will
work, because Bacula will not allow reading and writing on the same Volume. In
any case, once a VirtualFull has been created, and a
restore is done involving the most current Full, it will read the Volume or
Volumes by the VirtualFull regardless of in which Pool the
Volume is found.
So, after an aspirin, seems to me that:
1) for a virtual backup, the reading part need to READ jobs from volumes
with the same 'Media Type'; so i can use different pools/storage, but have
to use the same 'Media Type'.
2) i can use the same pool, but clearly i cannot guarantee that i'll have
only TWO full backup; error in rotation, ... could sooner or later lead to
a virtualfull job will write to an empty volume, making another copy of
data; surely i need TWO full copy (one for reading, one for writing).
3) i can use different pool, but with the same media type; in this way i can
somewhat limit the number of full backup to two (using two media in the
full pool). But still i think that there's no way to have ONE full copy...
clearly without 'scripting' something around (create a scratch pool/volume,
consolidate, migrate back to original pool/volume, delete scratch).
I'm missing something? Thanks.
--
La sorte di chi sa fare le cose è che poi gli tocca farle...
(Loris Tissino)
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
