Please see the attached file for an explanation and possible work around.
This file may be somewhat out of date as it was written over a year ago.
On Thursday 13 October 2005 09:40, Thorsten Engel wrote:
> Dear group,
>
> I regarded myself as very clever when trying to setup the backup strategy
> to
>
> "Monthly Full->Tape"
> "Weekly Differential->Tape"
> "Daily Incremental->Disk"
>
> It works nice until it comes to restore. Ok, manual restore of the separate
> jobs does work, but restore of "recent client backup" does not because
> bacula claims "the jobids you selected refer to more than one mediatype".
> Well, I think the problem ist not the MediaType (SDLT -> DISK) but more the
> Storage Device (NEO Lib -> RAID)
>
> >From my understanding the main problem for bacula is that it only allows
> > (and needs!) 1 storage resource for the restore job. With a little help I
> > would be able to code that in myself, or do you see any "larger" problems
> > doing so? From my understanding the main problem for bacula is that it
> > only allows (and needs!) 1 storage resource for the restore job. With a
> > little help I would be able to code that in myself, or do you see any
> > "larger" problems doing so?
>
> I think it would be _very nice_ to have this. Distributing backup jobs over
> different storage devices is no bad idea in my eyes.
>
> Best regards
>
> Thorsten Engel
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Bacula-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/bacula-devel
--
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.
