Derek:
After running your backup with the exclusion, have you looked in
/mnt/backup/backups/mail/var/lib/imap/ to see if the socket directory
was, in fact, excluded? My guess is that it is not there.
My guess is that you first made a backup without the '--exclude
On 11/4/2019 2:22 PM, David Bristow wrote:
Hello,
I had to delete all references to a folder in one of my backups, using
rdiff-backup-delete.py, which one of the devs basically wrote for us.
The script completely removes certain files from the backup going back
to the first time it was used.
On 9/9/2019 9:53 PM, Walt Mankowski wrote:
I found a file named
rdiff-backup-data/current_mirror.2019-09-08T03:01:02-04:00.data
which contained
4351
I moved it out of the way and reran the backup command. This time it
through an exception. The output is in the attached log file.
On 8/2/2019 6:13 AM, Otto Kekäläinen wrote:
Hello!
With the adoption of librsync2 the old MD4 hash is no longer supported
and thus a non-backwards compatible change is introduced. All backups
must therefore start from "scratch".
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776246
I don't have experience with your setup. Nonetheless, here are some
things to check:
Check the linux server logs. Are there any messages about ssh
connection attempts from the Windows client?
Use tcpdump on linux (or maybe Wireshark on Windows) to see if a
connection attempt is occurring.
This is just a guess, but if your de-duplication process involves the
use of hard links which rdiff-backup is backing up, then your problem
may relate to the following bug (which affects hard links):
http://savannah.nongnu.org/bugs/?26848
The bug can generate the type of errors shown in your
On 12/4/2016 9:58 AM, Robert Nichols wrote:
On 12/03/2016 09:32 PM, Andrea Bolandrina wrote:
What problems does rdiff-backup have with hard linked content?
As far as I know hard links should be supported...
Supported? Yes, but with plenty of bugs. If links are added and
removed from a set,
On 8/23/2016 7:12 AM, Michael Born wrote:
I checked my rdiff-backup (version 1.2.8-22.1.4) which was from my main
repository.
I now switched to the official Archiving repository and got the version
1.2.8-42.5
I have to admit that I can't see what patches are in what version
You'd need to look
On 8/22/2016 4:21 PM, Michael Born wrote:
Wow, that was a fast response.
Am 21.08.2016 um 04:37 schrieb Joe Steele:
This is a bug. I was able to reproduce it and have created an issue for
it here:
https://github.com/sol1/rdiff-backup/issues/9
You can try to work around your problem by:
1
This is a bug. I was able to reproduce it and have created an issue for
it here:
https://github.com/sol1/rdiff-backup/issues/9
You can try to work around your problem by:
1) using '--check-destination-dir'; then
2) look at the name of your current_mirror file (and there must only be
one of
On 12/13/2015 7:03 AM, Andrea Cozzolino wrote:
I have quite the same problem and in the *same* environment
(openSUSE 13.2/rdiff-backup 1.2.8).
I have a broken and, so far, unrecoverable backup store.
Each time I try to backup my home dir, I got a "Negative seek"
error while "Writing file
On 7/4/2015 10:08 AM, Ron Leach wrote:
[1]
Exception '[Errno 28] No space left on device' raised of class 'type
'exceptions.IOError'':
File /var/lib/python-support/python2.5/rdiff_backup/Main.py, line
304, in error_check_Main
try: Main(arglist)
File
Based on experience with CentOS 4, I suspect that if you stat
/usr/share/terminfo/P/P9-W on the source system, you will find
that it has multiple hard links.
It could be totally irrelevant, but my first thought (because of
the hard links) is that the problem may stem from this bug:
I can't say what exactly caused your problem, but I can reproduce
such an error this way:
| $ mkdir -p src/d1/d2
| $ mkdir backup
| $ touch src/d1/f1
| $ touch src/d1/d2/f2
| $ rdiff-backup src/ backup/
| $ touch backup/d1/d2/f3
| $ rm -rf src/d1/d2/
| $ rdiff-backup src/ backup/
|
On 11/8/2013 1:07 PM, Alper Ortac wrote:
Thank you. That takes a whole lot of time (40 seconds in my
case). Is there another possibility to get this information
faster? I only need the date of the current backup.
Look at your current mirror file:
$ ls
On 10/30/2013 1:59 AM, Ian Zimmerman wrote:
On Sun, 27 Oct 2013 23:38:43 -0400
Joe Steele j...@madewell.net wrote:
Joe I created a patch to fix this problem 4+ years ago. It can be
Joe found attached to this bug report:
Joe http://savannah.nongnu.org/bugs/?26847
By the way, what do you gain
On 7/19/2013 6:12 AM, Dominic Raferd wrote:
On 19/07/2013 07:48, Grant wrote:
Will rdiff-backup save and version ACLs? I'm hoping to use rsync
--fake-super to preserve ownership and permission info in ACLs and
then create an rdiff-backup repository from the rsynced files.
Well it is
On 6/4/2013 1:35 PM, Stefan Lisowski wrote:
I try restoring to a file on Windows:
rdiff-backup -r 1h \;080roducts /opt/Products
From what I can tell, you shouldn't be using the encoded name on
the command line.
The above command should have been:
rdiff-backup -r 1h Products
On 6/6/2013 5:50 PM, Stefan Lisowski wrote:
stefan@hydra01
/cygdrive/k/backups/bigboy_backups_rdiff/opt/;080lone-2.5.5/zeocl
uster
$ rdiff-backup -v 5 -r 1h Products /opt/Products
Using rdiff-backup version 1.2.8
Unable to import module xattr.
Extended attributes not supported on filesystem at
That's too bad. I recall that the wiki had some useful info.
The internet archive has some pages from it:
http://web.archive.org/web/*/http://wiki.rdiff-backup.org/
The most recent crawl with useful data was on 6/24/12:
On 4/11/2013 9:24 AM, Scott Lair wrote:
Hello,
Is it possible to list files in an increment? I see a week ago that an
increment size was several gigs and want to find out what files are in
there.
When I want to know why a certain backup was large, I will look
in the file-statistics for the
On 4/11/2013 12:50 PM, Scott Lair wrote:
I wasn't having much luck with this so I thought I'd focus on the new
files search. I have the following line in one of my stats files.
opt/samba/m/ATX/2011/Years/2011/Support201304030936.log 1 13848 NA 0
when I run
zgrep -e ' 1 [0-9]+ NA 0$'
On 4/11/2013 4:04 PM, Scott Lair wrote:
On Thu, 2013-04-11 at 15:15 -0400, Joe Steele wrote:
On 4/11/2013 12:50 PM, Scott Lair wrote:
I wasn't having much luck with this so I thought I'd focus on the new
files search. I have the following line in one of my stats files.
opt/samba/m/ATX/2011
It looks like you were encountering the python bug identified here:
http://bugs.python.org/issue1747858
Before their fix, the uid was being converted to a (32 bit) signed int,
which, as you have noted, isn't big enough. After the fix, the uid is
converted to a long. I don't know anything
On 8/1/2011 10:29 AM, Robert Nichols wrote:
and I would add:
* Correct handling of hard-linked files. This is currently broken in
two places. (1) During a verify operation, rdiff-backup will
complain about a missing checksum for each link other than the one
that appears first in the
If I understand the question, then all you need to do is to look
at the various files listed within the pertinent sub-tree found
under backup-dir/rdiff-backup-data/increments/path to sub-tree.
--Joe
On 12/21/2010 5:56 PM, Greg Freemyer wrote:
All,
I've got a directory that seems to be
My understanding is that librsync is only needed for building
rdiff-backup (more specifically, for building _librsync.so).
During the build, rdiff-backup/_librsync.so is created and is
statically linked against librsync.a.
Once rdiff-backup is built, librsync can be uninstalled and
In all likelihood, your problem is caused by hardlinked files in
your backup. The --verify and --compare-hash directives in
version 1.2.8 have problems with such files.
You might take a look at bug report #26848:
https://savannah.nongnu.org/bugs/?26848
I have just now updated the report with
I suspect that if you check, you will find that the files listed
in your warning messages have 2 or more hardlinks to them.
After seeing your post, it occurred to me that your problem might
be related to a bug report I filed back in June (and which I have
just now updated):
Per man 5 crontab:
The entire command portion of the line, up to a newline or %
character, will be executed by /bin/sh or by the shell
specified in the SHELL variable of the cronfile. Percent-signs
(%) in the command, unless escaped with backslash (\), will be
changed into new-line
30 matches
Mail list logo
