On Saturday 03 April 2010 01:47:12 James Harper wrote:
> > 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
I would see the above more like the following:
1. Start Job
2. Back up all normal C: D: E: etc files as normal
3. Back up Registry to spool #1
3a. Stop spooling #1
4. Save Registry metadata
No, here I would probaby simply write the data
to the volume with spooling turned off
4a. Despool #1 (i.e. write to Volume)
5. Back up Active Directory to spool #2
5a. Stop spooling #2
6. Save Active Directory metadata
Write directly to Volume
6a. Despool #2
7. Back up System (dll's and exe's etc) to spool #3
7a Stop spooling #3
8. Save System metadata
Write metadata directly to Volume
8a. Despool #3
9. Continue with any other backup
10. Possibly other plugins like above
11. Set job success
Now in the case that the metadata is not returned until "Set Job success" is
given, then I will need to rethink this -- it means that we may need to store
the metadata elsewhere.
Best regards,
Kern
>
> 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
------------------------------------------------------------------------------
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
