> > Thanks to those who sent in suggestions. While talking to Eric about this, I > came up with the solution that appeals to me the most: > > We add new functionality between the FD and the SD. > > 1. FD asks SD to Open named Spool file (all subsequent data will go there) > 2. SD sends back spool name. > 3. FD can ask to stop spooling > 4. The FD can then start spooling with a new name (item 1) if it wants. > 5. The FD can ask the SD to commit a specified named spool file. > 6. The SD sends back the status. > 7. For the moment, only one spool can be open at a time. > > This resolves the problem since the FD can begin spooling into a named spool > file for the File data, when it is done, it stops spooling and simply writes > in non-spooled mode, then commits the file data. Result, they are in order, > and if anything goes wrong during spooling of the file data, the FD is > notified and the VSS backup is canceled properly. > > One minor variation would have the FD start spooling for the XML data, then > stop spooling when it is done, and despool the XML data, then despool the > file data -- resulting in the correct order for restore. > > Constraint: the SD must have sufficient spool space, which is generally never > a problem. > > I am going to think about this a day or two, wait for James' reaction, then > begin implementation of it. >
Ok so it works like this: 1. Start Job 2. Back up all normal C: D: E: etc files as normal 3. Back up Registry to spool #1 4. Save Registry metadata (keep in memory) 5. Back up Active Directory to spool #1 6. Save Active Directory metadata (keep in memory) 7. Back up System (dll's and exe's etc) to spool #1 8. Save System metadata (keep in memory) 9. Set job success 10. Save job metadata (keep in memory) 11. Close spool #1 12. Write all metadata to backup media (direct?) 13. Write spool #1 to tape As I was writing the above it occurred to me that it might be a bit fragile... a backup set like this should be fine File = c:/ File = d:/ File = e:/ Plugin = "systemstate:/@SYSTEMSTATE/" Plugin = "vssexchange:/@VSSEXCHANGE/" (doesn't exist yet) Plugin = "vssmssql:/@VSSMSSQL/" (also doesn't exist yet) Plugin = "vssoracle:/@VSSORACLE/" (I assume oracle uses VSS) because c: d: and e: can be written to tape as normal, and then the new spool opened at the start of the first plugin, but if the user did something like this File = c:/ Plugin = "systemstate:/@SYSTEMSTATE/" Plugin = "vssexchange:/@VSSEXCHANGE/" (doesn't exist yet) File = e:/ Plugin = "vssmssql:/@VSSMSSQL/" (also doesn't exist yet) File = d:/ Plugin = "vssoracle:/@VSSORACLE/" (I assume oracle uses VSS) Then we'd have to take care to write the normal backup stuff direct to the media (or spool it as per the config), but write the plugin data to the temporary spool. I assume that is possible. Otherwise we just tell the user not to do that, put the file backups first then the plugins. So no showstoppers so far... James ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
