Here is an idea for adding md5sum consistency checks along with a
rough ability to reverse-lookup the pc tree entries that are hard
linked to any given pool entry. (It probably is not worth coding if
ver 4.0 is near since all this functionality reportedly will be built
into the new version)
1. Cre
thanks
On Fri, Sep 5, 2008 at 11:09 PM, Les Mikesell <[EMAIL PROTECTED]> wrote:
> dan wrote:
>
>>
>> I think i may just add -I to the rsync commands. I have looked through
>> config.pl but I only see a single rsync args section, not one for fulls
>> and
>> incrementals.
>>
>
> In Rsync.pm, --ign
dan wrote:
>
> I think i may just add -I to the rsync commands. I have looked through
> config.pl but I only see a single rsync args section, not one for fulls and
> incrementals.
In Rsync.pm, --ignore-times is added to the args for full runs.
--
Les Mikesell
[EMAIL PROTECTED]
---
rsync should not(i mean, it is designed not) assume that a file exists under
any circumstances. It should still check every file's mtime.
I think i may just add -I to the rsync commands. I have looked through
config.pl but I only see a single rsync args section, not one for fulls and
incrementa
[EMAIL PROTECTED] wrote:
> On Wed, Sep 03, 2008 at 06:57:39PM -0600, dan wrote:
>> this was on an rsync incremental. There was no error in the Xfers log, it
>> is like the file was not there. The atime on the file is from before the
>> backup so I know the file was there. I have only seen this o
On Wed, Sep 03, 2008 at 06:57:39PM -0600, dan wrote:
> this was on an rsync incremental. There was no error in the Xfers log, it
> is like the file was not there. The atime on the file is from before the
> backup so I know the file was there. I have only seen this one time.
>
> The idea of mark
this was on an rsync incremental. There was no error in the Xfers log, it
is like the file was not there. The atime on the file is from before the
backup so I know the file was there. I have only seen this one time.
its true that only rsync actually does a file list but that doesnt mean that
a
dan wrote:
> I have a thought here, thought id run it through the users list before
> dropping it on the devs.
>
> My idea was to add a small step to the backuppc process to validate that
> all files that should be transfered were transfered and automatically
> flag the backup as a partial if t
On Wed, Sep 03, 2008 at 02:29:53PM -0600, dan wrote:
> I have a thought here, thought id run it through the users list before
> dropping it on the devs.
>
> My idea was to add a small step to the backuppc process to validate that all
> files that should be transfered were transfered and automatica
On 09/03 02:29 , dan wrote:
> The idea is to simply compare a list of files with some details such as
> mtime, size and filename. basically, have a post dump command to run a find
> against each share to be backed up on the remote side and on the backuppc
> side then compare the files.
This is a d
I have a thought here, thought id run it through the users list before
dropping it on the devs.
My idea was to add a small step to the backuppc process to validate that all
files that should be transfered were transfered and automatically flag the
backup as a partial if there is a discrepancy.
Th
Les Mikesell wrote:
> Jon Forrest wrote:
>>> I think it would theoretically be possible to
>>> get a target directory listing with the transfer methods that backuppc
>>> supports but it wouldn't be trivial.
>> I've started looking at the source code for BackupPC.
>> Too bad there aren't more comm
les wrote:
> Paul Fox wrote:
>
> > of course, they don't believe in man pages, do they... sigh. what
> > a crock.
>
> It's gnu, remember - the people who insist that you need the source to
> do anything useful.
yeah, i know.
i'm just cranky because i just found out the OLPC give-1-ge
Paul Fox wrote:
> of course, they don't believe in man pages, do they... sigh. what
> a crock.
It's gnu, remember - the people who insist that you need the source to
do anything useful.
--
Les Mikesell
[EMAIL PROTECTED]
--
Les Mikesell <[EMAIL PROTECTED]> wrote:
> Yes but it is specific to gnutar not anything general. Try timing:
that's worse, of course!!
> tar --totals --one-file-system -cf /dev/null /
> or
> tar --totals --one-file-system -cf - / > /dev/null
> vs.
> tar --totals --one-file-system -cf - / |c
Paul Fox wrote:
> > > tar -cvf /dev/null
> > >
> > > the tar to /dev/null actually doesn't take that long at all, maybe a few
> > > minutes depending on the size.
> >
> > Gnu tar actually recognizes if stdout is connected to /dev/null (even if
> > you redirect instead of specifying -f)
les wrote:
> Les Stott wrote:
>
> > tar -cvf /dev/null
> >
> > the tar to /dev/null actually doesn't take that long at all, maybe a few
> > minutes depending on the size.
>
> Gnu tar actually recognizes if stdout is connected to /dev/null (even if
> you redirect instead of specifying
Les Stott wrote:
> tar -cvf /dev/null
>
> the tar to /dev/null actually doesn't take that long at all, maybe a few
> minutes depending on the size.
Gnu tar actually recognizes if stdout is connected to /dev/null (even if
you redirect instead of specifying -f) and doesn't bother to read the
f
Jon Forrest wrote:
Les Mikesell wrote:
I don't think tar is capable of transferring a directory listing without
the contents of the files. Since it runs over ssh you could run some
other command, but the command isn't guaranteed to exist or to be
permitted by the sshd config at the other
Les Mikesell wrote:
> I don't think tar is capable of transferring a directory listing without
> the contents of the files. Since it runs over ssh you could run some
> other command, but the command isn't guaranteed to exist or to be
> permitted by the sshd config at the other end.
If 'tar' i
Jon Forrest wrote:
>
>> I think it would theoretically be possible to
>> get a target directory listing with the transfer methods that backuppc
>> supports but it wouldn't be trivial.
>
> I've started looking at the source code for BackupPC.
> Too bad there aren't more comments. There's obvious
12:56pm, Les Mikesell wrote:
> Jon Forrest wrote:
>
>> One reason why I think my idea has promise is because this is how
>> all the commercial backup products I've ever used work. Adding
>> this feature to BackupPC would just bring it closer to
>> the commercial backup products.
>
> Don't those pr
Les Mikesell wrote:
> Jon Forrest wrote:
>
>> One reason why I think my idea has promise is because this is how
>> all the commercial backup products I've ever used work. Adding
>> this feature to BackupPC would just bring it closer to
>> the commercial backup products.
>
> Don't those products a
Jon Forrest wrote:
> One reason why I think my idea has promise is because this is how
> all the commercial backup products I've ever used work. Adding
> this feature to BackupPC would just bring it closer to
> the commercial backup products.
Don't those products all require a client side agent,
Nils Breunese (Lemonbit) wrote:
> Sounds nice, but doesn't seem to cover all use cases. For instance, I
> exclude directories that may not exist at all on some of my clients. How
> would your GUI method facilitate that?
This would clearly be a per-client feature. If the directories
to exclude d
Jon Forrest wrote:
A couple of weeks ago I had trouble
configuring BackupPC to include and exclude
client directories. With the help of readers
of this list, I learned that I didn't understand
the syntax and semantics of the $Conf{BackupFilesOnly}
variable.
One way that I could have avoided thi
A couple of weeks ago I had trouble
configuring BackupPC to include and exclude
client directories. With the help of readers
of this list, I learned that I didn't understand
the syntax and semantics of the $Conf{BackupFilesOnly}
variable.
One way that I could have avoided this misunderstanding
wou
On 11/01 08:31 , Rob Owens wrote:
> Wrong list, I know, but I'd like to see a "Search" button. This is so
> that, for instance, if I know I had a file named 123.txt, but I can't
> remember when it was deleted or when was the last time I saw it, I can
> find it w/o manually looking through potentia
Wrong list, I know, but I'd like to see a "Search" button. This is so
that, for instance, if I know I had a file named 123.txt, but I can't
remember when it was deleted or when was the last time I saw it, I can
find it w/o manually looking through potentially 10's or 100's of backups.
-Rob
Steph
D]
Objet
Re: [BackupPC-users] Idea for the new version of BackupPC... or no ?
The delete button is not a bad idea. I think it's even been suggested
before.
Craig (or anyone else that develops this patch), I'd recommend it be
available, at least by default, only to cgi admin users.
The delete button is not a bad idea. I think it's even been suggested
before.
Craig (or anyone else that develops this patch), I'd recommend it be
available, at least by default, only to cgi admin users.
Another thought: It might not be a bad thing if there were a button on the
"Admin Options"
Hello,
I don't know if it's a good idea but I would like to know if it's a
possible to add a new button "Delete" ("Supprimer" in french) in the
webpage named "Summary of Backups".
Just to delete completly the backup selected.
In my case, it will be usefull.
Thanks.
Romain
SC2N -S.A Siège So
On 07/31 03:16 , Jack Coats wrote:
> I would like just a simple 'red light'/'yellow light'/'green light' -
> backup did not start (red), backup had problems but backed up some files
> (yellow), and (green) if everything completed without incident. ... But
> that is MY perspective. And yes, then I
I can see a desire for the small installations to want a 'one size fits
all' backup and monitoring product. BackupPC does most of what is needed
pretty well.
I would like just a simple 'red light'/'yellow light'/'green light' -
backup did not start (red), backup had problems but backed up some fi
2007/7/31, Ludovic Drolez <[EMAIL PROTECTED]>:
> But, It would be very convenient: from the status page, you would be able
> to see if all the backups are OK, and if nothing will prevent them to go on
> for the next weeks. One login. One page. Less wasted time.
But we all have different needs and
Lane
Sent: Tuesday, July 31, 2007 6:58 AM
Cc: backuppc-users@lists.sourceforge.net
Subject: Re: [BackupPC-users] Idea: disk usage graphs
Michael Mansour wrote:
> Hi Ludovic,
>
>> Hi !
>>
>> I think that the following feature would be nice:
>> - having a graph of the
Ludovic Drolez wrote:
>> This was proposed recently on this list, and it was pointed out that there
>> are already tools to do this (you mention rrdtool). The premise of Linux,
>
> Yes, I know that lots of other tools can do this (but you still have
> to write custom cacti scripts for the pool siz
Michael Mansour wrote:
> Hi Ludovic,
>
>> Hi !
>>
>> I think that the following feature would be nice:
>> - having a graph of the pool size, and remaining disk usage.
>>
>> It would allow us to predict future disk usage and anticipate a disk
>> upgrade. This could be easily added using the rrdtoo
> This was proposed recently on this list, and it was pointed out that there
> are already tools to do this (you mention rrdtool). The premise of Linux,
Yes, I know that lots of other tools can do this (but you still have
to write custom cacti scripts for the pool size, while BPC has the
informati
Hi Ludovic,
> Hi !
>
> I think that the following feature would be nice:
> - having a graph of the pool size, and remaining disk usage.
>
> It would allow us to predict future disk usage and anticipate a disk
> upgrade. This could be easily added using the rrdtool binary, but I
> may have not
On Tue, 31 Jul 2007 14:11:14 +0200, [EMAIL PROTECTED] said:
> I think that the following feature would be nice:
> - having a graph of the pool size, and remaining disk usage.
This was proposed recently on this list, and it was pointed out that there
are already tools to do this (you mention rrdto
Hi !
I think that the following feature would be nice:
- having a graph of the pool size, and remaining disk usage.
It would allow us to predict future disk usage and anticipate a disk upgrade.
This could be easily added using the rrdtool binary, but I may have not
time to do this, so, if someon
L.Drolez wrote:
I think that something interesting could be easily added to
backuppc: if
the 'rrdtool' binary is available, a graph of the pool size could
be shown
in the status page.
With this you could:
- predict when you will run out of space
- have hints about which backup boomed the po
Hi !
I think that something interesting could be easily added to backuppc: if
the 'rrdtool' binary is available, a graph of the pool size could be shown
in the status page.
With this you could:
- predict when you will run out of space
- have hints about which backup boomed the pool size (for thi
44 matches
Mail list logo
