Bacula-users

Re: [Bacula-users] Advise for a bit complicated migration/consolidation

2010-09-03 03:39:51
Subject: Re: [Bacula-users] Advise for a bit complicated migration/consolidation
From: Bruno Friedmann <bruno AT ioda-net DOT ch>
To: bacula-users AT lists.sourceforge DOT net
Date: Fri, 03 Sep 2010 09:36:24 +0200
On 09/02/2010 10:20 PM, Phil Stracchino wrote:
> On 09/02/10 15:21, Bruno Friedmann wrote:
>> On 09/02/2010 08:33 PM, Phil Stracchino wrote:
>>> I meant to say, bscan will do part of what you want.  Depending on the
>>> media, you should be able to either copy the disk volumes to the new
>>> datacenter, or send tapes and install a drive that can read them if
>>> necessary; at that point you should be able to bscan their metadata into
>>> your new Catalog, at which point you should be set.
>>
>> I theory, I've think of it, but in reality, as it's not tape
>> it seems I have to rebuild all the devices and the file system where they 
>> have been + give bscan the old bacula-sd.conf
>> otherwise : nothing work ...
> 
> I don't see why that should be necessary.  A disk volume is just a file.
>  It's not tied to any specific filesystem.  You should be able to put it
> anywhere you want, and make the sd.conf file that you feed to bscan
> match that location and a valid disk Pool.  If you can't do that and
> have it work, something is wrong.
> 
> 

Dear Phil, nothing is wrong, but as I've said, the challenge here is not to get 
the old Pool, Device etc in the new server.
Bscan work nicely in this case, no doubt on that. Test prove that.

But we have to re-import them in new defined pool, perharps also new name.
Perharps with some details it would be better.

I've old data like this for entA
client was serverA-fd
Pool: Pool_FileWeekly
+---------+----------------+-----------+---------+----------+----------+--------------+---------+------+-----------+-------------+-------------+
| mediaid | volumename     | volstatus | enabled | volbytes | volfiles | 
volretention | recycle | slot | inchanger | mediatype
 | lastwritten |
+---------+----------------+-----------+---------+----------+----------+--------------+---------+------+-----------+-------------+-------------+
|       4 | FS_SAMEDI-0004 | Archive   |       1 |        0 |        0 |   
31,536,000 |       0 |    0 |         0 | File_FSWEEK
|             |
+---------+----------------+-----------+---------+----------+----------+--------------+---------+------+-----------+-------------+-------------+

and for entC exactly the same pool, same media name
client was serverB-fd

Pool: Pool_FileWeekly
+---------+----------------+-----------+---------+----------+----------+--------------+---------+------+-----------+-------------+-------------+
| mediaid | volumename     | volstatus | enabled | volbytes | volfiles | 
volretention | recycle | slot | inchanger | mediatype
 | lastwritten |
+---------+----------------+-----------+---------+----------+----------+--------------+---------+------+-----------+-------------+-------------+
|       4 | FS_SAMEDI-0004 | Archive   |       1 |        0 |        0 |   
8,644,000 |       0 |    0 |         0 | File_FSWEEK
|             |
+---------+----------------+-----------+---------+----------+----------+--------------+---------+------+-----------+-------------+-------------+


Now I have to consolidate those 2 medias in new structure, I'm pretty sure I 
can't have two media with same name in same pool Or
can I without difficulties to select the correct one during restore operation.

Pool_serverA_Week
WEEK-04

Pool_serverB_Week
WEEK-04

Same for months (total of 26), and years total 12 media for the last 5 years
Month 6 is always made twice, same for Month 12.

Now time will pass, and each time a week or a month is done in the new 
pool/media scheme, we can delete the old record.
So after a certain amount of time, all old media will be deleted and pools can 
be removed.


The trouble are located here :
If I didn't put all old config during a restore test
After having choose some files to restore

Unable to find Storage resource for
MediaType "File_FSWEEK", needed by the Jobs you selected.

I can force the new storage where I put the old media.
but

03-Sep 09:24 orville-dir JobId 7: Start Restore Job 
Restore_Dumbo-ACL.2010-09-03_09.24.53_08
*m
03-Sep 09:24 orville-dir JobId 7: Using Device "SDev_TRANSFERT"
03-Sep 09:24 orville-sd JobId 7: acquire.c:117 Changing read device. Want Media 
Type="File_FSWEEK" have="TRANSFERT"
  device="SDev_TRANSFERT" (/media/bacula.storage/TRANSFERT)
03-Sep 09:24 orville-fd JobId 7: Fatal error: job.c:2031 Bad response to Read 
Data command. Wanted 3000 OK data
, got 3000 error

03-Sep 09:24 orville-sd JobId 7: Fatal error: acquire.c:166 No suitable device 
found to read Volume "FS_SAMEDI-0004"
03-Sep 09:24 orville-dir JobId 7: Error: Bacula orville-dir 5.0.3 (04Aug10): 
03-Sep-2010 09:24:55

So this clearly explain, my first asking for advise.
I need not only reload content of media inside db, but need to drive it to 
specific Pool, and also change the Media type concerned.

Can I do that, in a pseudo automatic way, or will I finally have to trick 
manually the database ?

ps : why we have so many file device type is due to the concurrency jobs. (One 
store, One specific Device, One specific Device
Type )


-- 

Bruno Friedmann  bruno AT ioda-net DOT ch

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users