Bacula-users

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

2010-09-04 05:02:54
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: Sat, 04 Sep 2010 10:59:05 +0200
On 09/03/2010 06:30 PM, Phil Stracchino wrote:
> On 09/03/10 03:36, Bruno Friedmann wrote:
>> 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.
> 
> 
> OK, now I have a better understanding of the problem.  I really don't
> grasp the details of your configuration, but it appears to me that what
> you need to do is to TEMPORARILY create Storage devices on the new
> system with the same names and media types as those on the old server,
> controlled the same Storage daemon that controls the new system's
> devices, then bscan the volumes in, THEN you can set up a migration job
> to move all the jobs from the old media onto volumes in your new
> server's pools.  Once you've done that, you should be able to remove the
> temporary device and pool.
> 
> 

Yes that's a way to do it.

I also made another test yesterday and finally found something that could do it.

Prepare (by label) the new medium in the new pools, and after that use bcopy 
from old medium to new one.
(So I don't need to recreate all old stuff config).

And do a bscan on the new medium to get record in database.

In this case everything goes at the right place, with the right name. and 
operators can work normally.


-- 

Bruno Friedmann  bruno AT ioda-net DOT ch
Ioda-Net Sàrl www.ioda-net.ch

  openSUSE Member
    User www.ioda.net/r/osu
    Blog www.ioda.net/r/blog

GPG KEY : D5C9B751C4653227

------------------------------------------------------------------------------
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