"Kern Sibbald" wrote:
>On Wednesday 07 April 2010 10:07:25 Jeroen van Meeuwen wrote:
>> "Eric Bollengier" wrote:
>> >> In PostgreSQL, toast objects (like blob) larger than 1024bytes are
>> >> compressed by the engine in toast area. (MySQL should do the same thing)
>> >
>> >MySQL can compress fi
On Wednesday 07 April 2010 10:07:25 Jeroen van Meeuwen wrote:
> "Eric Bollengier" wrote:
> >> In PostgreSQL, toast objects (like blob) larger than 1024bytes are
> >> compressed by the engine in toast area. (MySQL should do the same thing)
> >
> >MySQL can compress fields, but you need to modify sq
"Eric Bollengier" wrote:
>> In PostgreSQL, toast objects (like blob) larger than 1024bytes are compressed
>> by the engine in toast area. (MySQL should do the same thing)
>
>MySQL can compress fields, but you need to modify sql queries to add COMPRESS()
>and UNCOMPRESS() calls. Not so nice.
>
J
On Wed, 7 Apr 2010 09:16:59 +0200
Eric Bollengier wrote:
> Hello,
>
> On Wed, 7 Apr 2010 08:20:46 +1000
> "James
> > > Won't that make for a really huge catalog?
> >
> > While each backup might have up to 500KB of XML metadata, it is just
> > plain text and XML text at that so it compresses rema
Hello,
On Wed, 7 Apr 2010 08:20:46 +1000
"James Harper" wrote:
>
> > > I've decide to put the metadata in the catalog, which really
> disgusts me,
> > > but
> > > I see no other choice to have a general solution that will work with
> both
> > > disk and tape Volumes (as well as future devices
> > I've decide to put the metadata in the catalog, which really
disgusts me,
> > but
> > I see no other choice to have a general solution that will work with
both
> > disk and tape Volumes (as well as future devices such as the cloud).
> >
>
> Won't that make for a really huge catalog?
While e
On 4/6/2010 11:26 AM, Kern Sibbald wrote:
> Hello,
>
> The problem is that there can be anywhere from 1 to 20 or so different
> writers, so there can be up to 20 (maybe even more) different backups
> followed by metadata, and then when the whole backup is done, there is yet
> more metadata for the
Hello,
The problem is that there can be anywhere from 1 to 20 or so different
writers, so there can be up to 20 (maybe even more) different backups
followed by metadata, and then when the whole backup is done, there is yet
more metadata for the "backup" rather than just for a writer, and that b
On 4/2/2010 10:36 AM, Kern Sibbald wrote:
> Hello,
>
> 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 subs
Hello,
03.04.2010 22:27, Kern Sibbald wrote:
> On Saturday 03 April 2010 21:26:46 Carsten Menke wrote:
>> Avi Rozen wrote:
>>> Perhaps do restores in several passes? in this case two passes are
>>> required: restore xml and then files. This may be less disruptive in
>>> terms of modifying existing
On Saturday 03 April 2010 21:26:46 Carsten Menke wrote:
> Avi Rozen wrote:
> > Perhaps do restores in several passes? in this case two passes are
> > required: restore xml and then files. This may be less disruptive in
> > terms of modifying existing code, since each restore phase would be
> > simi
Avi Rozen wrote:
>
>
> Perhaps do restores in several passes? in this case two passes are
> required: restore xml and then files. This may be less disruptive in
> terms of modifying existing code, since each restore phase would be
> similar to a regular restore that's done today...
>
Seems logical
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 f
On Saturday 03 April 2010 01:49:04 James Harper wrote:
> > 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:/@VSSORACL
>
> 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
>
> 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 spo
On Friday 02 April 2010 16:38:09 Henrik Johansen wrote:
> On 04/ 2/10 01:13 PM, Kern Sibbald wrote:
> > Hello,
> >
> > Over the past several weeks James and I have been discussing a rather
> > sticky point with doing System State backup and restores via a Bacula
> > plugin.
> >
> > The basic proble
On 04/ 2/10 01:13 PM, Kern Sibbald wrote:
> Hello,
>
> Over the past several weeks James and I have been discussing a rather sticky
> point with doing System State backup and restores via a Bacula plugin.
>
> The basic problem works down to the fact that we do the backup, we first have
> the names
Hello,
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.
Kern Sibbald wrote:
> Does anyone have any ideas or suggestions preferences?
>
>
Perhaps do restores in several passes? in this case two passes are
required: restore xml and then files. This may be less disruptive in
terms of modifying existing code, since each restore phase would be
similar to
Hello,
Over the past several weeks James and I have been discussing a rather sticky
point with doing System State backup and restores via a Bacula plugin.
The basic problem works down to the fact that we do the backup, we first have
the names of the files to backup, which we do, then we get som
21 matches
Mail list logo
