On Thursday 15 September 2005 17:26, Phil Stracchino wrote:
> Kern Sibbald wrote:
> > On Thursday 15 September 2005 15:18, Jonte Norman wrote:
> >>Are there any plans to implement multiple storages devices for the
> >>same client in future Bacula versions?
> >
> > No immediate plans. Once the SD starts for a Job, it locks on to a single
> > device.
>
> You know, this brings up a potential issue. Is this true when restoring
> as well as when backing up? I have a tentative plan (based on an offer
> of an LTO1 drive) to start using LTO for my Full backups, for which my
> VXA1 is no longer big enough to be really practical, but keep using the
> VXA1 for incrementals, for which it's perfectly adequate. Backing up,
> this isn't a problem, because any given Job running at a specified level
> goes only to a single device. But does this mean that if I want to
> restore a set of files on which some files come from a Full backup, and
> some from Differential or Incremental, that I need to somehow split it
> into two distinct jobs, perhaps by editing the BSR file?
Yes,
>
> As a workaround, I think it wouldn't be too hard to come up with a tool
> to split the BSR file into two or more BSRs by device. Can't test the
> idea until I have a second drive, though.
The attached file should help, but it may be a bit out of date. For example,
there are MediaType records in the bsr file now -- however, they are not
used.
--
Best regards,
Kern
(">
/\
V_V
If you run a backup job with two different types of media, for
example, using a DLT for full saves and a DDS-4 for incremental,
you will have some difficulties doing restores because Bacula
doesn't yet know how to deal with multiple media types for a single
job name (multiple jobs run).
When you do a "restore" command, bacula will warn you that it
is not possible to do the restore:
Warning, the JobIds that you selected refer to more than one MediaType.
Restore is not possible. The MediaTypes used are:
File
Filea
The defined Storage resources are:
1: DDS-4
2: DLTDrive
3: File
4: Floppy
Select Storage resource (1-4): 3
where I have run the full save with MediaType File, then ran an
incremental backup with MediaType Filea.
If you select device 3, for example, Bacula will quite happily
continue mixing the two MediaTypes with less than satisfactory
results when the Storage daemon gets the job.
The solution is to continue and select the files to be restored.
In the example below, I simply restore everything (default):
You are now entering file selection mode where you add and
remove files to be restored. All files are initially added.
Enter "done" to leave this mode.
cwd is: /
$ done
Bootstrap records written to /home/kern/bacula/working/restore.bsr
The restore job will require the following Volumes:
test12
Test13
121 files selected to be restored.
Run Restore job
JobName: kernsrestore
Bootstrap: /home/kern/bacula/working/restore.bsr
Where: /tmp/bacula-restores
Replace: always
FileSet: Kerns Files
Client: Rufus
Storage: File
When: 2003-12-07 21:44:25
Priority: 10
OK to run? (yes/mod/no): no
then respond no to the request to run the job. At this point, you
must edit the bootstrap file (saved in /home/kern/bacula/working/restore.bsr
in the above example) into two or more distinct bootstrap files. Each should
have the records that pertain to a single MediaType. You generally should
know by looking at the Volume names.
In the above example, there were two volumes, and if I do a "list volumes",
one can see clearly that volume "test12" is MediaType "File" and "Test13" is
MediaType "Filea":
+---------+------------+-----------+----------+-----------+
| MediaId | VolumeName | VolStatus | VolBytes | MediaType |
+---------+------------+-----------+----------+-----------+
| 1 | test12 | Append | 1994210 | File |
| 2 | Test13 | Append | 53898 | Filea |
+---------+------------+-----------+----------+-----------+
where I have truncated a number of columns for display purposes.
In my example, the bootstrap file looks like:
restore.bsr
---------------
Volume="test12"
VolSessionId=1
VolSessionTime=1070829472
VolFile=0
VolBlock=197-1994406
FileIndex=1-58
FileIndex=61-106
FileIndex=109-110
FileIndex=112-116
FileIndex=119-120
Count=113
Volume="Test13"
VolSessionId=2
VolSessionTime=1070829596
VolFile=0
VolBlock=576-54095
FileIndex=1-8
Count=8
and it is quite easy to separate it into two files as:
restore1.bsr
--------------
Volume="test12"
VolSessionId=1
VolSessionTime=1070829472
VolFile=0
VolBlock=197-1994406
FileIndex=1-58
FileIndex=61-106
FileIndex=109-110
FileIndex=112-116
FileIndex=119-120
Count=113
restore2.bsr
----------------
Volume="Test13"
VolSessionId=2
VolSessionTime=1070829596
VolFile=0
VolBlock=576-54095
FileIndex=1-8
Count=8
Finally, start two jobs, one after the other and specify the appropriate
bsr filename and an appropriate storage resource that can read the
MediaType corresponding to the bootstrap file being restored.
