On 9/26/23 12:48, Marco Gaiarin wrote:
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
No. Not because they were in the same pool, but rather because the
volumes were all loadable and readable by the same device.
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.
While true, I find that misleading. It is true only because a Device
resource can specify only a single Media Type. What is really going on
is that Bacula makes a one-time decision when the job starts as to which
device it will read from and which device it will write to. Once that
read device is established, all volumes that need to be read must be
readable by that particular device. Hence, all volumes must have the
same Media Type, because they must all be read by the same read device.
[...]
* 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.
In a nutshell, you must have multiple devices and you must ensure that
one device reads all of the existing volumes and another different
device writes the new virtual full volumes. This is why it is not
possible to do virtual fulls or migration with only a single tape drive.
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'.
Yes. Also, if you have multiple devices with the same Media Type, you
must make certain that any volume with that Media Type can be loaded
into any of those devices.
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).
A new full backup is made each time the virtual full job runs. You can
purge volumes in a RunAfter script or you limit the number of volumes in
the pool, but I guess the only way to guarantee there are only two
copies is to manually purge old volumes.
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 don't understand the goal, I think, but MaximumVolumeJobs in the Pool
resource might work.
I'm missing something? Thanks.
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
