On Tuesday 04 May 2010 10:45:16 Craig Ringer wrote:
> On 4/05/2010 11:45 AM, Morty Abzug wrote:
> > file dedup (rather than block dedup) could mostly be handled at the
> > catalog level with another level of indirection. I.e. instead of a
> > catalog entry containing file metadata and where the fi
On Sunday 09 May 2010 22:53:19 Morty Abzug wrote:
> On Wed, May 05, 2010 at 08:10:42AM +0200, Michael Stapelberg wrote:
> > Excerpts from Craig Ringer's message of 2010-05-05 01:19:02 +0200:
> > > To back up transient machines like laptops.
> >
> > You can back up laptops just fine using a VPN or I
On Wed, May 05, 2010 at 08:10:42AM +0200, Michael Stapelberg wrote:
> Excerpts from Craig Ringer's message of 2010-05-05 01:19:02 +0200:
> > To back up transient machines like laptops.
> You can back up laptops just fine using a VPN or IPv6 (if you either use
> Mobile IPv6 (I know nobody who does)
On Fri, May 07, 2010 at 10:13:56AM +1000, Gary R. Schmidt wrote:
> Does "status client" not give this?
Indeed, yes. Thanks!
- Morty
--
___
Bacula-devel mailing list
Bacula-d
On Wed, May 5, 2010 15:28, Morty Abzug wrote:
> On Tue, May 04, 2010 at 11:43:32PM +0200, Michael Stapelberg wrote:
>
>> > (1) no way to do a simple client check (AKA amcheck -c.)
>> > (2) no way to do a simple tape check (AKA amcheck -lt)
>> What exactly do you mean with "client check" and "tape c
Hi Craig,
Excerpts from Craig Ringer's message of 2010-05-05 01:19:02 +0200:
> To back up transient machines like laptops.
You can back up laptops just fine using a VPN or IPv6 (if you either use
Mobile IPv6 (I know nobody who does) or update your DNS (I do that)).
> "batch mode" refers to "non-b
On Tue, May 04, 2010 at 11:43:32PM +0200, Michael Stapelberg wrote:
> > (1) no way to do a simple client check (AKA amcheck -c.)
> > (2) no way to do a simple tape check (AKA amcheck -lt)
> What exactly do you mean with "client check" and "tape check"?
"client check" meaning that all clients are
On 5/05/2010 5:43 AM, Michael Stapelberg wrote:
>> (6) no proper client/server model. bacula "clients" need inbound ports
> Why would one want a "proper" client/server model? Not having the need to
> contact the director all the time is actually good, IMO (you would have to
> do that when not hav
Hi Morty,
Excerpts from Morty Abzug's message of 2010-05-04 19:33:12 +0200:
> (1) no way to do a simple client check (AKA amcheck -c.)
> (2) no way to do a simple tape check (AKA amcheck -lt)
What exactly do you mean with "client check" and "tape check"?
> (4) no way to logically group hosts into
On Tue, May 04, 2010 at 04:45:16PM +0800, Craig Ringer wrote:
> On 4/05/2010 11:45 AM, Morty Abzug wrote:
>
>> file dedup (rather than block dedup) could mostly be handled at the
>> catalog level with another level of indirection. I.e. instead of a
>> catalog entry containing file metadata and whe
On 4/05/2010 11:45 AM, Morty Abzug wrote:
> file dedup (rather than block dedup) could mostly be handled at the
> catalog level with another level of indirection. I.e. instead of a
> catalog entry containing file metadata and where the file lives on
> media, it would contain file metadata and a f
On Thu, Apr 08, 2010 at 08:39:04AM +0200, Kern Sibbald wrote:
> However, from what I see, this is basically similar to what BackuPC
> does. The big problem I have with it is that it does not scale well
> to thousands of machines.
file dedup (rather than block dedup) could mostly be handled at th
On 04/ 9/10 03:16 AM, Gary R. Schmidt wrote:
> On Fri, April 9, 2010 05:26, Henrik Johansen wrote:
>> On 04/ 8/10 07:36 PM, Phil Stracchino wrote:
>>> On 04/08/10 09:13, Craig Ringer wrote:
Phil Stracchino wrote:
> I'll be interested to see those results. Which filesystems are you
> t
On Fri, April 9, 2010 05:26, Henrik Johansen wrote:
> On 04/ 8/10 07:36 PM, Phil Stracchino wrote:
>> On 04/08/10 09:13, Craig Ringer wrote:
>>> Phil Stracchino wrote:
I'll be interested to see those results. Which filesystems are you
testing?
>>>
>>> I'm interested in ext3, ext4 and xfs
On Fri, April 9, 2010 05:09, Richard Scobie wrote:
[snip]
> You may find the XFS mount directive, "filestreams" of benefit here.
And using the 64-bit XFS will also better[1] than the standard 32-bit XFS.
Or the hybrid 32-bit XFS using 64-bit layout rules. (Damn, I only left
SGI at the end of 200
On 04/ 8/10 07:36 PM, Phil Stracchino wrote:
> On 04/08/10 09:13, Craig Ringer wrote:
>> Phil Stracchino wrote:
>>> I'll be interested to see those results. Which filesystems are you testing?
>>
>> I'm interested in ext3, ext4 and xfs. I should probably look at zfs too,
>> but don't have any hosts
On 04/08/10 09:13, Craig Ringer wrote:
> Phil Stracchino wrote:
>> I'll be interested to see those results. Which filesystems are you testing?
>
> I'm interested in ext3, ext4 and xfs. I should probably look at zfs too,
> but don't have any hosts that it runs on usefully and don't really have
> a
Phil Stracchino wrote:
> On 04/08/10 03:53, Craig Ringer wrote:
>> BTW, When I suggested that greater write concurrency would be desirable
>> and should be easier, Phil Stracchino raised some concerns about
>> concurrent writes to a file system increasing fragmentation and hurting
>> overall perfor
On 04/08/10 03:53, Craig Ringer wrote:
> BTW, When I suggested that greater write concurrency would be desirable
> and should be easier, Phil Stracchino raised some concerns about
> concurrent writes to a file system increasing fragmentation and hurting
> overall performance. Rather than just wave
Kern Sibbald wrote:
> Hello,
>
> I haven't seen the original messages, so I am not sure if I understand the
> full concept here so my remarks may not be pertinent.
Personally I wasn't suggesting a format change - I'm pretty happy with
the fake-tape volumes for on-disk storage (though I wish be
Hello,
I haven't seen the original messages, so I am not sure if I understand the
full concept here so my remarks may not be pertinent.
However, from what I see, this is basically similar to what BackuPC does. The
big problem I have with it is that it does not scale well to thousands of
mac
On 04/07/10 18:52, Robert LeBlanc wrote:
> I didn't think about the copy/migration jobs (I'm using them), and
> that would be a problem. It seems for this to take off, the
> copy/migration between SDs will have to be implemented. We would have
> to look at the stream as a copy/migration is happenin
On 04/07/10 16:15, Phil Stracchino wrote:
> On 04/07/10 12:06, Robert LeBlanc wrote (in bacula-users):
>> So still thinking about this, is there any reason to not have a
>> hierarchical file structure for disk based backup rather than a
>> serialized stream? Here are my thought, any comments welcom
On 04/07/10 12:06, Robert LeBlanc wrote (in bacula-users):
> So still thinking about this, is there any reason to not have a
> hierarchical file structure for disk based backup rather than a
> serialized stream? Here are my thought, any comments welcome to have a
> good discussion about this.
>
>
24 matches
Mail list logo
