Re: [Bacula-users] Re: [Bacula-devel] Combined Tape Disk Storage Solution
Kern Sibbald wrote: On Wednesday 26 October 2005 20:31, Attila Fülöp wrote: Kern Sibbald wrote: For example, with a trivial amount of work, I could modify Bacula to handle an autochanger with several Media Types, but each drive would have only one Media Type that it would read/write. This would be great anyhow, since it would allow me to connect an additional (DDS) drive and write the fulls to the LTO and the diffs to the DDS drive. (Using the dummy changer script posted to this list) This in turn would allow me to distribute the fulls over the week while still mantaining the advantages of multiple pools, reducing size and duration of the full dump. Yes, I will probably implement this for 1.38.1 Fine, thanks. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
RE: [Bacula-users] Re: [Bacula-devel] Combined Tape Disk Storage Solution
Hmm. I don't think that would pass our auditors. If there's a significant chance that the copies are not identical (and it sounds like this approach pretty much guarantees that the copies will not be identical), I don't think it would be sufficient or useful for this purpose. It does however make implementation easier, as you said. Well, it may not pass your auditors, I cannot argue with that, but I can say that if it doesn't pass, they would probably be horrified to learn that the copies that they are currently getting are not true instantaneous snapshots of the system (except the Win32 VSS backups), and so the minor differences produced by this procedure are probably insignificant compared to the inconsistencies within a single backup. I think you've answered a slightly different question. Right now, what goes on the tape is block-for-block identical to what is reported by the FD during the scope of that run, however flawed. If I want do parallel copies of those tapes at the same time for redundancy or offsiting, etc, then the data that goes on the copies of the primary tape needs to be the same blocks as what went on the primary tape for each job. Unless I'm missing something, the description you gave would not produce that result -- it's effectively N separate backup runs -- so the tape copies wouldn't really be the same data, and thus the backups would not be interchangable. I need to think about it a lot more before I can answer. The current mechanism that I have defined is a copy field in the JobMedia record so that Bacula can write as many copies of a file as it wants, and it can then choose what copy should be used for the restore. All the details are not yet worked out. Sounds like that would be workable. I think that once Python scripting has matured a bit, a DR manager as you want and describe will be rather easy or perhaps I should say straight forward. All the hooks you need will be there ... It does look that way. -- db --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Re: [Bacula-devel] Combined Tape Disk Storage Solution
On Wednesday 26 October 2005 19:01, David Boyes wrote: Hmm. I don't think that would pass our auditors. If there's a significant chance that the copies are not identical (and it sounds like this approach pretty much guarantees that the copies will not be identical), I don't think it would be sufficient or useful for this purpose. It does however make implementation easier, as you said. Well, it may not pass your auditors, I cannot argue with that, but I can say that if it doesn't pass, they would probably be horrified to learn that the copies that they are currently getting are not true instantaneous snapshots of the system (except the Win32 VSS backups), and so the minor differences produced by this procedure are probably insignificant compared to the inconsistencies within a single backup. I think you've answered a slightly different question. Right now, what goes on the tape is block-for-block identical to what is reported by the FD during the scope of that run, however flawed. If I want do parallel copies of those tapes at the same time for redundancy or offsiting, etc, then the data that goes on the copies of the primary tape needs to be the same blocks as what went on the primary tape for each job. Making an exact copy of a tape is not always possible, because each tape has a slightly different length and may also have a different number of bad spots that are automatically handled by the drive. As a consequence, the end of every tape, will be different (and hence all of the next tape), unless you force Bacula to stop writing the tape before the end of the tape. So, in all cases, I would program for two identical copies being different. Unless I'm missing something, the description you gave would not produce that result -- it's effectively N separate backup runs -- so the tape copies wouldn't really be the same data, and thus the backups would not be interchangable. You are correct that the tapes would not be identical, so you could not blindly substitute one tape for another. However, since Bacula writes two jobs, you could use the set of tape from one job or from the other one. This has the disadvantage that if one tape in each job is bad, there will be a problem, while if you really had two identical copies of the same tape, you could use the second identical tape. I need to think about it a lot more before I can answer. The current mechanism that I have defined is a copy field in the JobMedia record so that Bacula can write as many copies of a file as it wants, and it can then choose what copy should be used for the restore. All the details are not yet worked out. Sounds like that would be workable. I think that once Python scripting has matured a bit, a DR manager as you want and describe will be rather easy or perhaps I should say straight forward. All the hooks you need will be there ... It does look that way. By the way, I am really unhappy that Bacula cannot at least to some extent handle autochangers with two drives with different Media Types. Could you identify for me what the most important combinations are: i.e. a drive that reads/writes two media types; a drive that reads two media types but writes only one; a drive that writes two media types but reads only one; or two drives in a changer that have different media types, but read/write only one or the other? For example, with a trivial amount of work, I could modify Bacula to handle an autochanger with several Media Types, but each drive would have only one Media Type that it would read/write. Any of the other combinations would be more work. -- Best regards, Kern ( /\ V_V --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Re: [Bacula-devel] Combined Tape Disk Storage Solution
Kern Sibbald wrote: For example, with a trivial amount of work, I could modify Bacula to handle an autochanger with several Media Types, but each drive would have only one Media Type that it would read/write. This would be great anyhow, since it would allow me to connect an additional (DDS) drive and write the fulls to the LTO and the diffs to the DDS drive. (Using the dummy changer script posted to this list) This in turn would allow me to distribute the fulls over the week while still mantaining the advantages of multiple pools, reducing size and duration of the full dump. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Re: [Bacula-devel] Combined Tape Disk Storage Solution
On Wednesday 26 October 2005 20:31, Attila Fülöp wrote: Kern Sibbald wrote: For example, with a trivial amount of work, I could modify Bacula to handle an autochanger with several Media Types, but each drive would have only one Media Type that it would read/write. This would be great anyhow, since it would allow me to connect an additional (DDS) drive and write the fulls to the LTO and the diffs to the DDS drive. (Using the dummy changer script posted to this list) This in turn would allow me to distribute the fulls over the week while still mantaining the advantages of multiple pools, reducing size and duration of the full dump. Yes, I will probably implement this for 1.38.1 -- Best regards, Kern ( /\ V_V --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Re: [Bacula-devel] Combined Tape Disk Storage Solution
On Wednesday 05 October 2005 17:59, David Boyes wrote: Hmm. Does the second job transfer the data from the FD again? If so, then that doesn't (IMHO) quite do what I want to do here. I really want to transfer the data only once (the only guarantee we have of getting the same data on all the copies) and create the replicas on the server side. Yes, it starts a second job. The disadvantage of this is that the data is not 100% identical if anything is changing on the FD. The advantage is that it avoids a whole bunch of complications that I have not logically resolved concerning having two backups of the same thing in the same job. Hmm. I don't think that would pass our auditors. If there's a significant chance that the copies are not identical (and it sounds like this approach pretty much guarantees that the copies will not be identical), I don't think it would be sufficient or useful for this purpose. It does however make implementation easier, as you said. Well, it may not pass your auditors, I cannot argue with that, but I can say that if it doesn't pass, they would probably be horrified to learn that the copies that they are currently getting are not true instantaneous snapshots of the system (except the Win32 VSS backups), and so the minor differences produced by this procedure are probably insignificant compared to the inconsistencies within a single backup. (As a side issue, I'm beginning to wonder if overall we need a more generalized job manager. This is sort of sounding like we need something like JCL, and then this could all be handled in a more systematic way. That's a much bigger project, though.) Perhaps if I were starting to design Bacula with the knowledge I have today, I would have a different structure. However, I have to live with the current code, and at the current time, I am, unfortunately, the only one who understands it and who is continuously working on the project. Don't you feel lucky and needed? 8-) No, I would feel better knowing there was already someone ready to take my place. Making any major design changes is not something I can handle without a team of programmers. By myself, I can continue the same path I have taken over the years -- slowly evolve it to provide all the functionality we want. As I said, it's a MUCH bigger project. Not on the radar for today or tomorrow, just musing a bit on something I was thinking about. What we've got works; it's more thinking about where future simplifications might go. OK, that's fair. This could be a way to do it, but it doesn't fit in with the current Bacula scheme. Any restore can have Volumes from multiple pools (typically not from a single job). Many users separate their Volumes into Full, Diff, Inc pools. So, IMO, unless I am missing something you are saying, a Pool is not a good way to separate multiple copies. I do have a database column designed to indicate what copy a particular Volume record is from (I also have a stripe database column). Since they are not yet fully implemented, they are not yet stored in the DB to conserve space, but this info is passed from the SD to the DIR. I probably didn't explain it well. I don't think the approach conflicts at all with current usage -- the primary pools can still be anything the user designates. Copy pools are horizontal in nature, in *addition* to the existing primary pool structure -- basically they provide a way of grouping volumes so that copies of volumes in the primary pool are selected from a designated set of volumes. So, example: Pool A (primary Full) -- Pool B (copypool 1 for pool A) -- Pool C (copypool 2 for Pool A) -- etc. Pool D (primary Diff) -- Pool E (copypool 1 for pool D) -- Pool F (copypool 2 for Pool D) -- etc. Let's say that Pool A is a pool containing volumes A1, A2, and A3. Pool B is a different pool, containing volumes B1, B2, and B3. Pool C contains volumes C1, C2 and C3, and so forth. In a backup job, data is written to a volume selected from the primary pool, say A2. If copypools are defined for the primary pool, the same data is written to volumes selected from the designated copypool(s), say B1 and C3. The idea of a SD-mux would allow this to be implemented w/o changing a lot of the SD code -- jobs talk to the SD-mux, and the SD-mux would look at the definition of the primary pool, and then establish N sessions with the SDs manageing the primary and copypools, 1 per pool. The SD-mux accepts the write from the FD, and returns a write complete when all the end SDs acknowledge the write complete. The end SDs use the same volume selection method they do now, selecting a volume from the appropriate pool using the same logic used today. If multiple jobs are active, that's fine -- the SD-mux doesn't care, and the end SD will not try to select the same volume in use for another job, eg. Job 2 will get
RE: [Bacula-users] Re: [Bacula-devel] Combined Tape Disk Storage Solution
I scoped the problem as two major projects: 1) implementation of copy pools -- where files written to a pool were automatically also written to up to 3 additional pools using the same volume selection criteria as exist now (essentially getting the SD to act as a FD to more than one FDs to ensure synchronous updates, or creating a SD-mux function to split the FD data stream to N SDs). In a certain sense this is already implemented in 1.37. 1.37 permits a job to start a second job in a way that makes the second job duplicate the since date/time. This effectively allows making identical copies (except for files that change during the backup). Hmm. Does the second job transfer the data from the FD again? If so, then that doesn't (IMHO) quite do what I want to do here. I really want to transfer the data only once (the only guarantee we have of getting the same data on all the copies) and create the replicas on the server side. 2) implementation of pool to pool migration as discussed on the list previously. Pool to Pool, or direct writing by the SD to several devices within one Job both require a few more changes to the SD. All the basic data structures exist so that the SD can have multiple I/O packets open, but as of 1.37, the SD only has a single I/O packet per job. In older versions of Bacula, there were only DEVICE stuructures, one per physical device. Now, there are DCR (device control records) that sit above the DEVICE structure. There can be multiple DCRs that use the same DEVICE in 1.37 -- this is no problem. However, the next generalization, and most of the code is in, is to allow a job to have multiple DCRs. The job must be taught to open multiple devices (and thus create multiple DCRs), and then either read from one DCR and write to another (copy), and/or write to multiple DCRs. (As a side issue, I'm beginning to wonder if overall we need a more generalized job manager. This is sort of sounding like we need something like JCL, and then this could all be handled in a more systematic way. That's a much bigger project, though.) OK, I can see how that could work. The only part of this implementation that I have not worked out in my head is how to deal with the catalog. If there are two identical backups of a Job on two different Volumes, the Director is not currently aware of it. There needs to be some way of flagging two copies as being identical, then using only one of those copies for any given restore. What I was thinking with the copypool idea was to have multiple volume records for a file, and sorting by copypool order, eg pool A has copypools B and C. During backup, the file is stored on a volume in pool A, and also stored on volumes selected from pool B and C (finite number of these, to avoid impacting performance significantly). The database would reflect 1 file record with multiple volume records pointing to the volumes selected from pool A, B, and C, with an indication of a pool priority (based on the sequence of the copypools) to indicate which version to try first. When traversing the file table for a restore, you can retrieve the list of volume records containing that file, and iterate through them either in copypool priority sequence or try them at random, prioritizing for volumes currently mounted and available. If the volume you try is in the changer and available, use it, else try the next one. Also, there needs to be a bit more work in implementing some better user interface for archiving i.e. taking Volumes (possible identical copies) out of the Volume pool, and then later re-introducing them. With the approach above, just taking the volumes in and out of the changers does the job for you. No new wheels needed. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
RE: [Bacula-users] Re: [Bacula-devel] Combined Tape Disk Storage Solution
Hmm. Does the second job transfer the data from the FD again? If so, then that doesn't (IMHO) quite do what I want to do here. I really want to transfer the data only once (the only guarantee we have of getting the same data on all the copies) and create the replicas on the server side. Yes, it starts a second job. The disadvantage of this is that the data is not 100% identical if anything is changing on the FD. The advantage is that it avoids a whole bunch of complications that I have not logically resolved concerning having two backups of the same thing in the same job. Hmm. I don't think that would pass our auditors. If there's a significant chance that the copies are not identical (and it sounds like this approach pretty much guarantees that the copies will not be identical), I don't think it would be sufficient or useful for this purpose. It does however make implementation easier, as you said. (As a side issue, I'm beginning to wonder if overall we need a more generalized job manager. This is sort of sounding like we need something like JCL, and then this could all be handled in a more systematic way. That's a much bigger project, though.) Perhaps if I were starting to design Bacula with the knowledge I have today, I would have a different structure. However, I have to live with the current code, and at the current time, I am, unfortunately, the only one who understands it and who is continuously working on the project. Don't you feel lucky and needed? 8-) Making any major design changes is not something I can handle without a team of programmers. By myself, I can continue the same path I have taken over the years -- slowly evolve it to provide all the functionality we want. As I said, it's a MUCH bigger project. Not on the radar for today or tomorrow, just musing a bit on something I was thinking about. What we've got works; it's more thinking about where future simplifications might go. This could be a way to do it, but it doesn't fit in with the current Bacula scheme. Any restore can have Volumes from multiple pools (typically not from a single job). Many users separate their Volumes into Full, Diff, Inc pools. So, IMO, unless I am missing something you are saying, a Pool is not a good way to separate multiple copies. I do have a database column designed to indicate what copy a particular Volume record is from (I also have a stripe database column). Since they are not yet fully implemented, they are not yet stored in the DB to conserve space, but this info is passed from the SD to the DIR. I probably didn't explain it well. I don't think the approach conflicts at all with current usage -- the primary pools can still be anything the user designates. Copy pools are horizontal in nature, in *addition* to the existing primary pool structure -- basically they provide a way of grouping volumes so that copies of volumes in the primary pool are selected from a designated set of volumes. So, example: Pool A (primary Full) -- Pool B (copypool 1 for pool A) -- Pool C (copypool 2 for Pool A) -- etc. Pool D (primary Diff) -- Pool E (copypool 1 for pool D) -- Pool F (copypool 2 for Pool D) -- etc. Let's say that Pool A is a pool containing volumes A1, A2, and A3. Pool B is a different pool, containing volumes B1, B2, and B3. Pool C contains volumes C1, C2 and C3, and so forth. In a backup job, data is written to a volume selected from the primary pool, say A2. If copypools are defined for the primary pool, the same data is written to volumes selected from the designated copypool(s), say B1 and C3. The idea of a SD-mux would allow this to be implemented w/o changing a lot of the SD code -- jobs talk to the SD-mux, and the SD-mux would look at the definition of the primary pool, and then establish N sessions with the SDs manageing the primary and copypools, 1 per pool. The SD-mux accepts the write from the FD, and returns a write complete when all the end SDs acknowledge the write complete. The end SDs use the same volume selection method they do now, selecting a volume from the appropriate pool using the same logic used today. If multiple jobs are active, that's fine -- the SD-mux doesn't care, and the end SD will not try to select the same volume in use for another job, eg. Job 2 will get either A1 or A3 from Pool A, since A2 is already in use for another job and the SD for Pool A already knows that. Same logic occurs for the copypools. The above should handle the consistency issue for the volumes neatly. As you say, the problem is associating multiple volume residence records with a file record in the database. What I was trying to suggest was that the volume residence field (probably not the right name, but I'm talking about the entry in the file record that indicates what volume the file is on) could become a list of (1...n) volume records instead. Same data, just that there can be more than 1 volume
Re: [Bacula-users] Re: [Bacula-devel] Combined Tape Disk Storage Solution
On Tuesday 04 October 2005 15:15, David Boyes wrote: I scoped the problem as two major projects: 1) implementation of copy pools -- where files written to a pool were automatically also written to up to 3 additional pools using the same volume selection criteria as exist now (essentially getting the SD to act as a FD to more than one FDs to ensure synchronous updates, or creating a SD-mux function to split the FD data stream to N SDs). In a certain sense this is already implemented in 1.37. 1.37 permits a job to start a second job in a way that makes the second job duplicate the since date/time. This effectively allows making identical copies (except for files that change during the backup). Hmm. Does the second job transfer the data from the FD again? If so, then that doesn't (IMHO) quite do what I want to do here. I really want to transfer the data only once (the only guarantee we have of getting the same data on all the copies) and create the replicas on the server side. Yes, it starts a second job. The disadvantage of this is that the data is not 100% identical if anything is changing on the FD. The advantage is that it avoids a whole bunch of complications that I have not logically resolved concerning having two backups of the same thing in the same job. 2) implementation of pool to pool migration as discussed on the list previously. Pool to Pool, or direct writing by the SD to several devices within one Job both require a few more changes to the SD. All the basic data structures exist so that the SD can have multiple I/O packets open, but as of 1.37, the SD only has a single I/O packet per job. In older versions of Bacula, there were only DEVICE stuructures, one per physical device. Now, there are DCR (device control records) that sit above the DEVICE structure. There can be multiple DCRs that use the same DEVICE in 1.37 -- this is no problem. However, the next generalization, and most of the code is in, is to allow a job to have multiple DCRs. The job must be taught to open multiple devices (and thus create multiple DCRs), and then either read from one DCR and write to another (copy), and/or write to multiple DCRs. (As a side issue, I'm beginning to wonder if overall we need a more generalized job manager. This is sort of sounding like we need something like JCL, and then this could all be handled in a more systematic way. That's a much bigger project, though.) Perhaps if I were starting to design Bacula with the knowledge I have today, I would have a different structure. However, I have to live with the current code, and at the current time, I am, unfortunately, the only one who understands it and who is continuously working on the project. Making any major design changes is not something I can handle without a team of programmers. By myself, I can continue the same path I have taken over the years -- slowly evolve it to provide all the functionality we want. My next email on Project management will discuss the above point a bit more in detail. OK, I can see how that could work. The only part of this implementation that I have not worked out in my head is how to deal with the catalog. If there are two identical backups of a Job on two different Volumes, the Director is not currently aware of it. There needs to be some way of flagging two copies as being identical, then using only one of those copies for any given restore. What I was thinking with the copypool idea was to have multiple volume records for a file, and sorting by copypool order, eg pool A has copypools B and C. During backup, the file is stored on a volume in pool A, and also stored on volumes selected from pool B and C (finite number of these, to avoid impacting performance significantly). The database would reflect 1 file record with multiple volume records pointing to the volumes selected from pool A, B, and C, with an indication of a pool priority (based on the sequence of the copypools) to indicate which version to try first. This could be a way to do it, but it doesn't fit in with the current Bacula scheme. Any restore can have Volumes from multiple pools (typically not from a single job). Many users separate their Volumes into Full, Diff, Inc pools. So, IMO, unless I am missing something you are saying, a Pool is not a good way to separate multiple copies. I do have a database column designed to indicate what copy a particular Volume record is from (I also have a stripe database column). Since they are not yet fully implemented, they are not yet stored in the DB to conserve space, but this info is passed from the SD to the DIR. When traversing the file table for a restore, you can retrieve the list of volume records containing that file, and iterate through them either in copypool priority sequence or try them at random, prioritizing for volumes
Re: [Bacula-users] Re: [Bacula-devel] Combined Tape Disk Storage Solution
Hello David, On Monday 03 October 2005 21:20, David Boyes wrote: I scoped the problem as two major projects: 1) implementation of copy pools -- where files written to a pool were automatically also written to up to 3 additional pools using the same volume selection criteria as exist now (essentially getting the SD to act as a FD to more than one FDs to ensure synchronous updates, or creating a SD-mux function to split the FD data stream to N SDs). In a certain sense this is already implemented in 1.37. 1.37 permits a job to start a second job in a way that makes the second job duplicate the since date/time. This effectively allows making identical copies (except for files that change during the backup). 2) implementation of pool to pool migration as discussed on the list previously. Pool to Pool, or direct writing by the SD to several devices within one Job both require a few more changes to the SD. All the basic data structures exist so that the SD can have multiple I/O packets open, but as of 1.37, the SD only has a single I/O packet per job. In older versions of Bacula, there were only DEVICE stuructures, one per physical device. Now, there are DCR (device control records) that sit above the DEVICE structure. There can be multiple DCRs that use the same DEVICE in 1.37 -- this is no problem. However, the next generalization, and most of the code is in, is to allow a job to have multiple DCRs. The job must be taught to open multiple devices (and thus create multiple DCRs), and then either read from one DCR and write to another (copy), and/or write to multiple DCRs. I think there is approximately 1-2 solid months of coding involved in each project -- neither are trivial to do. To get that coded is going to take a few contributions. The only part of this implementation that I have not worked out in my head is how to deal with the catalog. If there are two identical backups of a Job on two different Volumes, the Director is not currently aware of it. There needs to be some way of flagging two copies as being identical, then using only one of those copies for any given restore. Also, there needs to be a bit more work in implementing some better user interface for archiving i.e. taking Volumes (possible identical copies) out of the Volume pool, and then later re-introducing them. By the end of the week, I will send an email that specifies how I believe we should deal with the wishlist and projects for the next release. That will permit us during November to come up with a list of project, give them a priority, and hopefully find contributors ... -- Best regards, Kern ( /\ V_V --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
RE: [Bacula-users] Re: [Bacula-devel] Combined Tape Disk Storage Solution
I scoped the problem as two major projects: 1) implementation of copy pools -- where files written to a pool were automatically also written to up to 3 additional pools using the same volume selection criteria as exist now (essentially getting the SD to act as a FD to more than one FDs to ensure synchronous updates, or creating a SD-mux function to split the FD data stream to N SDs). 2) implementation of pool to pool migration as discussed on the list previously. I think there is approximately 1-2 solid months of coding involved in each project -- neither are trivial to do. To get that coded is going to take a few contributions. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Re: [Bacula-devel] Combined Tape Disk Storage Solution
Hi, On 03.10.2005 20:06, Kern Sibbald wrote: Hello, Did you ever get an answer to this? If not it is a real pity. In any case, beginning in November, I will be making a new Wish List, and this item will probably be on in, if not, please submit it. Then maybe we can make some progress toward what you want ... Ok, I'll answer :-) On Thursday 01 September 2005 14:25, Daniel Holtkamp wrote: Hello ! I already contacted Kern about this and he suggested that i ask the lists about this. We want to backup all our clients to disk and then mirror these backups to tape. We want the ability to do quick restores from the disk (last 2-4 weeks depending on backup size) but also create a tape archive spanning several months if we need anything that is not on the disk-storage anymore (because the volume got recycled). At the moment this is not implemented. If anyone knows a workaround i`m open for suggestions. I think we discussed the possible workarounds, but that might have been someone else. Anyway, in the list archives, there should be some discussions concerning this. I'll just call it job migration and multiplication or, to save typing, JMM ;-) Are there any developers out there that would like to implement this? Is someone else even interested in this feature ? Would you support the development of this feature ? I would be interested, I can't implement it, and I would continue my support in terms of time - discussing and testing. No money unless I find someone who pays me for it first. My company would like to support the development of this feature financially if there is a programmer that is willing to do it. So what are your thoughts ? Well, on the developers list much of it was already discussed, I think. David Boyes, Kern Sibbald and others expressed their ideas. Tho one thing that was not expressly stated, but which would be required for your schema, is that, instead of moving a job from one media / pool / storage to another, it should be possible to copy it, too. So, to implement it, several other things have to be solved first: - having jobs more than once on media. The catalog would need a modification, I guess. - restoring from different media / SD needs to be possible. If not, IMO this is not fit for daily use. - job migration as planned needs to be iplemented and must support job copying, too. Just what I think needs to be done before this can go into production. I surely didn't mentio the thousands of small tweaks necessary :-) Arno Best regards, -- IT-Service Lehmann[EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
