Meh it's okay. I'd still like a feature like this, but I've never gotten a DNS
server to apply multiple IPs to a hostname sadly, only the other way around. Oh
well.
+--
|This was sent by saturn2...@gmail.com via Backup Central.
Saturn2888 wrote:
>
> The DHCP stuff I was saying is an issue with DNS itself. You can only have
> one IP per DNS entry, but you can have multiple DNS entries for that same IP.
DNS permits multiple IPs per name. However there is no standard for which one
a
client should use. Typically, DNS
Les Mikesell wrote:
> Saturn2888 wrote:
>
> >
> > I actually do have DDNS setup, but it's based on my DHCP server and that
> > doesn't tell it, if the machine connected on Wi-Fi, to prioritize the DNS
> > name hostname.local to 192.168.0.12 instead of 192.168.0.13. The easiest
> > way to do
Saturn2888 wrote:
>
> I actually do have DDNS setup, but it's based on my DHCP server and that
> doesn't tell it, if the machine connected on Wi-Fi, to prioritize the DNS
> name hostname.local to 192.168.0.12 instead of 192.168.0.13. The easiest way
> to do any of this, especially with a machin
I went way off-topic in asking about the pool and would like a moderator to
move the last few posts since mine into another topic if possible please.
Thanks Les for answering those questions. I guess it makes more sense, but it's
not completely apparently what all is going on from what you said
Saturn2888 wrote:
> I'm still confused on what you meant about the migration system and the
> different digests available. I'd suggest some kind of converter if you are
> allowing us to change the digest as that could cause a lot of issues and some
> people might do it the md5 way and then get a
I'm still confused on what you meant about the migration system and the
different digests available. I'd suggest some kind of converter if you are
allowing us to change the digest as that could cause a lot of issues and some
people might do it the md5 way and then get a hardware-based SHA proce
Jeffrey writes:
> Sounds like a lot of work though and kudos to you to committing to
> such an extensive upgrade -- are you going to have the time and
> resources to get this done in 2010 (or 2011 or 2012 ;)?
Not sure - hopefully this year.
> One more question if you don't mind...
> Can you give
Les writes:
> I think this will need some sort of atomic-operation reference count
> manager at the heart of things so you don't do those lookups except as a
> repair step.
Yes.
> Will there be a way to disable the de-dup operations completely in the
> case where the underlying filesystem doe
On 3/2/2010 2:12 AM, Jeffrey J. Kosowsky wrote:
>
> One more question if you don't mind...
> Can you give an outline of how expiry works in the absence of
> hard-links? Specifically, without walking through the whole pc tree
> each night and tabulating all the md5sum references, how do you know
> w
Craig Barratt wrote at about 23:24:41 -0800 on Monday, March 1, 2010:
> Jeffrey,
>
> Craig
ALL SOUNDS AWESOME and thanks for the helpful and patient responses to
my questions and suggestions.
Sounds like a lot of work though and kudos to you to committing to
such an extensive upgrade -- ar
Jeffrey,
Yes, read-only FUSE is a good idea.
I previously prototyped a read/write FUSE on top of BackupPC pooling
to support native rsync and tar, but the performance was quite poor
so I abandoned that approach for 4.x.
The BackupPC::View API hasn't changed a whole lot (and it supports both
4.x
Jeffrey,
> Hopefully, it will also broaden the usability of BackupPC to
> filesystems and OS's that don't support hard links since it seems like
> you will be eliminating just about all the filesystem-specific
> requirements.
The file system will still need hardlink support, but as I said
only fo
Craig Barratt wrote at about 15:01:04 -0800 on Monday, March 1, 2010:
> Backups will be stored as reverse deltas, so only the most recent is
> complete, and all the prior backups are just the deltas to re-create
> the prior backups. The prior backups will no longer need to have
> complete dire
All-in-all sounds AWESOME - can't wait to see it!
My inline comments below...
Craig Barratt wrote at about 15:01:04 -0800 on Monday, March 1, 2010:
> Jeffrey,
>
> Thanks for the suggestions. I've since decided to eliminate
> hardlinks altogether in 4.x. This is an aggressive design step,
>
Jeffrey,
Thanks for the suggestions. I've since decided to eliminate
hardlinks altogether in 4.x. This is an aggressive design step,
but if successful it will resolve many of the annoying issues
with the current architecture. (To be clear, hardlinks are
still needed in certain cases, since they
If I understand right (sorry for my english ;-)) this proposal will support
a backup of backuppc to another disk/machine.
I believe today this is an important lack what should be solved.
Unfortunately I am not a perl programmer. But I can support in testing.
I have server as well as clients which
In the past, we have had multiple discussions about adding full file
checksums (e.g., md5, SHA-1) and/or path names to pool files to allow for
integrity checking and reverse file look-up from the pc directory.
On the other hand, I know some people are not interested in that
feature or overhead.
S
18 matches
Mail list logo
