Howdy.
MacOS X puts nobody's UID at -2 in /etc/passwd, which comes out to 4294967294.
Even with a current (2.6.1) Python interpreter, the call to
tmp_rp.chown(uid+1, gid+1) # just choose random uid/gid
in FSAbilities.set_ownership() results in an OverflowError.
Perhaps it would make sense to h
Frederik wrote:
> IOError: CRC check failed
>
> So I see no way to recover any of the increments.
>
In over 12,000 rdiff-backup sessions, I have yet to encounter that issue
or anything like it (in terms of unrecoverability).
I'm with Maarten -- check your hardware.
___
Xavier Bertou wrote:
> I must agree with what Frederik said. rdiff-backup works just fine
> when rsync works just fine, ie when you don't need a backup except for
> stupid user deletion of files. When real bad things happen,
> rdiff-backup doesn't handle any errors. File I/O error? The whole
> back
Frederik wrote:
Yes, it's normal that it fails in these cases. But it's not normal
that it is not able to recover from it without removing all
increments. For example, in case of corruption, it should ignore all
corrupted files, but it should not completely prevent creating new
backups or prevent
John Joseph Bachir wrote:
Anyone have any idea what this is about?
strace is your friend.
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.
Wiebe Cazemier wrote:
On Sunday 03 June 2007 09:16, Charles Duffy wrote:
Granted -- but I still see the security issues implicit with running
rdiff-backup as root on the server as a far greater liability than the
benefit of not needing the tool to restore.
You can't be root o
Gavin wrote:
Yes but if you do have root on server permissions are set correctly so
the mirror is more useful
and rdiff-backup is not needed to view/retrieve the files with correct
owner+permissions.
Granted -- but I still see the security issues implicit with running
rdiff-backup as root on th
Wiebe Cazemier wrote:
If you're backing up system files, you do want to run it as root, because
non-root users might not be able to read some files.
Yes, you want to be root on the client... but that's no excuse for being
root on the server.
__
Frederik wrote:
Actually, rdiff-backup is a disaster in dealing with full disks:
looking at the size of rdiff-backup-data, a lot of space is used by
old increments. Unfortunately, rdiff-backup --remove-older-than fails
because no more disk space is available! So this leaves me with a
chicken and
The closest you're going to be able to get on that is creating a
compressed copy of the files in question using rsyncable gzip (see
http://glasnost.beeznest.org/articles/206 for an introduction, and
http://samba.anu.edu.au/ftp/unpacked/rsync/patches/gzip-rsyncable.diff
for the patch itself) and
John Joseph Bachir wrote:
Hello. I just started using rdiff-backup. Everything seems to be going
as expected, except the first letter of every filename is in
represented as what I'm guessing is a numeric index from a character set.
Applications: ;065pplications
Desktop: ;068esktop
Is this nor
Baldur Norddahl wrote:
I am aware of an earlier thread on this mail list, which proposes
using LVM for freezing the source while doing the backup. This will
indeed work for my purpose, but will require extensively
reconfiguration of my setup and should be unnecessary. Even using LVM,
my backup
Greg Freemyer wrote:
If you have millions of anything, then the filesystem selection
probably matters more than the backup software. Reiser3 is known to
have been specifically tuned to handle huge numbers of small files.
Erk. I don't exactly want to start a flamewar here, but as someone who
h
Dave Howorth wrote:
Leave the "--prefix=/usr/local" off your "python setup.py install" command.
Hmm, I still think /usr/bin is the wrong place for rdiff-backup, unless
I make an RPM and install it that way, which seems like a lot of effort
for something I'm just trying to test.
Buildi
Dave Howorth wrote:
Charles Duffy wrote:
Dave Howorth wrote:
--prefix=/usr/local
Well, yeah. You manually specify a prefix that's not in Python's default
sys.path, and you're going to get the issue you see here.
Could you expand a bit on that, please?
I&
Dave Howorth wrote:
--prefix=/usr/local
Well, yeah. You manually specify a prefix that's not in Python's default
sys.path, and you're going to get the issue you see here.
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
http
How are you doing the installation? "python setup.py install"? If so,
what is the output from "which python"? Does it help if you hard-specify
an interpreter path?
The modules shouldn't have gone under /usr/local unless a non-default
Python installation were in use. (I work with SLES9, which i
Found the error: On the server side, stderr was being injected into
stdin. This led to header_string containing arbitrary text; when some of
that was interpreted as an integer value via C.str2long() and fed into
read() as a size argument, that was what lead to the OverflowError (or,
in Python 2
dean gaudet wrote:
i wonder why i don't have this problem on million+ inode systems... i've
had it working with python2.3 before too (although i'm using 2.4 now)...
i'm still on 1.0.x.
is there a 32/64-bit mismatch between your hosts? any chance there's some
bug in that?
Both systems ar
Running a backup with a very large number of files (about 150,000) on
both ends, one of the RPC requests returns a response larger than
PY_SSIZE_T_MAX:
Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib64/pytho
Kevin Horton wrote:
If Ben lacks the time and/or interest to maintain rdiff-backup, is
there anyone who is interested and capable of taking over? If so, he
could inquire if Ben is willing to hand over control. If Ben doesn't
want to hand over control, then the new maintainer could fork a new
I'm running backups in such a way that "rdiff-backup --server" is being
run with uid and gid backup. I want to be able to give users who are
allowed to run restores membership in the backup group, and arrange
permissions such that this is sufficient to permit operation.
I've written a small pa
Per subject. I'm able to access this file normally via the local
filesystem, and I have the same exception in the same place when trying
to run --check-destination-dir against a different destination location.
This is with Linux 2.6 on both ends; the NFS mount options are
rw,hard,intr,acl.
$
Ben Escoto wrote:
Charles Duffy <[EMAIL PROTECTED]>
wrote the following on Wed, 17 Aug 2005 09:52:10 -0500
Notably, part of the fs_abilities check is calling fsync_local(),
which is trying to fsync directories even though the test to
determine whether this could be safely done failed, b
Sebastien Maret wrote:
I've tried to make a new backup on the server and it's works fine. Are
the backups done with earlier versions of rdiff-backup imcompatible with
rdiff-backup-1.1.5 ?
Shouldn't be, no. (Not that I'm any authority, mind you -- but most of
the folks who are actually authori
dave kempe wrote:
> Charles Duffy wrote:
>> Can you explain why a syscall attempting to perform this rename
>> operation would fail with a permission denied error on ncpfs? Do you
>> get the same thing when you attempt doing that rename yourself with
>> mv (without t
David Kempe wrote:
Tue Feb 7 11:47:11 2006 Renaming
dcentrl/rsync/test/test2/rdiff-backup.tmp.4 to
dcentrl/rsync/test/test2/.X0-lock
Can you explain why a syscall attempting to perform this rename
operation would fail with a permission denied error on ncpfs? Do you get
the same thing when you
Please pardon the repost, but I haven't seen any replies in the last
five days on the relevant thread ("--check-destination-dir failage w/
1.0.4: Not running destination ability test?")
I'm not opposed to writing a patch for this issue myself, if some
guidance as to how it would be appropriate
Per subject; observed in rdiff-backup 1.0.4, lightly patched (so line
numbers may be different). The report below describes behavior prior to
such uninstallation. While I sent another message regarding this same
issue ~5 days ago, I've been able to pin it down a little better this time.
On the cli
See attached patch. I believe this makes more sense than exiting with
status 1 (indicating an error), as simply having nothing to do is a
harmless, valid state.
--- rdiff-backup-1.0.4/rdiff_backup/Main.py.orig2006-01-31
13:36:55.505083666 -0600
+++ rdiff-backup-1.0.4/rdiff_backup/Main.py
roland wrote:
first i'd be happy to know, how "reliable" rdiff-backup is in general.
Speaking as a user, rdiff-backup isn't perfect -- it has bugs, to be
sure -- but none of the issues we've seen impact data integrity. Our
internal QA team has given it their approval, and we're using it for
da
Eww -- sorry 'bout that formatting, all; didn't realize it would do
that. As an attachment, this time.
(Lacking this patch, btw, I was receiving security violations on the
specified method doing a simple restore of a backup specified with
"--restore-as-of 0B").
--- rdiff-backup-1.0.4/rdiff_bac
I've validated (via running pdb and looking at the actual file handle
the call is being made on) that it's a directory being fsync'd. However,
this still happens even if I munge Globals.py and force
Globals.fsync_directories to 0.
___
rdiff-backup-users
--- rdiff-backup-1.0.4/rdiff_backup/Security.py.orig2006-01-26
12:21:30.980533559 -0600
+++ rdiff-backup-1.0.4/rdiff_backup/Security.py 2006-01-26
12:21:57.997097214 -0600
@@ -140,6 +140,7 @@
if sec_level == "read-only" or sec_level == "all":
l.extend(["fs_abilities.get_
This is happening on a separate pair of systems from those mentioned in
my last email. The more interesting bits are near the bottom; feel free
to skip down.
On the client:
# rdiff-backup --check-destination-dir --remote-schema 'netcat %s
10873' 10.1.128.1::/backup
Traceback (most rec
I just upgraded one of my test systems (client and server) from
rdiff-backup 1.0.0 to 1.0.4 (both with my --force-path-prefix patch
applied; perhaps at some point I'll try to reopen the discussion on
merging it upstream). While I can run new backups and increment them,
rollbacks are failing on an a
Peter Schuller wrote:
Hello,
I am always reluctant to use --remove-older-than in scripts because
there is always the possibility that the clock is screwed up for
whatever reason and it decides to remove all reverse diffs. Often I
would find it very useful to be able to say "keep the N newest
sna
David Kempe wrote:
> we have solved similar problems where we had no control over some of
> the lower layers, by implementing a openvpn tunnel. SSH over openvpn
> seems to improve in reliability a little. I know it sounds whack, but
> it works.
If you have a VPN, there's no point to running SSH and
Ben Escoto wrote:
> Anyway, this would only improve speed and/or disk space, and from the
> survey I get the impression that few people care about that.
>
I'd argue that a nontrivial subset of those voting for repository
editing did so to allow them to better optimize disk space usage -- at
leas
Ben Escoto wrote:
For the people that voted for repository editing, what did you want
exactly?
As for me, I want the ability to merge old increments, such that beyond
a given point I can abandon daily increments and store only weekly
increments; and beyond that only monthly. As the dataset I wo
Shai wrote:
distutils.errors.DistutilsPlatformError: invalid Python installation:
unable to open /usr/lib/python2.2/config/Makefile (No such file or
directory)
What should I do?
Install the python-devel package for your distribution.
___
rdiff-back
From my perspective, the ideal approach to keeping older backups at a
lower density than new ones would be writing code to be able to merge
reverse-diffs, such that two historical diffs could be replaced with
only one containing the changes from both -- and excluding the
intermediate changes fr
Golden Butler wrote:
I'm still relatively a newbie to linux even though I've been using it
for almost two years, so excuse me for the ignorance. What is "strace",
and how would I be able to use to track down this segfault problem?
strace shows a program's syscalls -- roughly, the requests it'
Chris Wilson wrote:
So now I have to upgrade all my boxes to 1.0.0, including Gentoo ones
which don't know about 1.0.0 yet
Creating custom ebuilds is really, really easy -- so getting 1.0.0 in
use on your Gentoo systems shouldn't be much trouble at all. Send me
personal mail if you need any
Ben Escoto wrote:
Well I was just suggesting using usernames.. Like instead of having
the server run
rdiff-backup --restrict --force-path-prefix --server
you could have it run
cd ; sudo -u Y rdiff-backup --restrict . --server
to avoid patching rdiff-backup and for an
Ben Escoto wrote:
Well I don't really understand your setup yet, but it seems any way
you do it, the client will have to authenticate itself to the server
somehow. The script can just check these credentials in the same way
your patched rdiff-backup would.
It's not a matter of credentials --
Observe the following stack trace:
Directories on file system at /dev/shm/restore/rdiff-backup.tmp.5 are not
fsyncable.
Assuming it's unnecessary.
Unable to import module xattr.
Extended attributes not supported on filesystem at
/dev/shm/restore/rdiff-backup.tmp.5
Unable to import module posix1e
On Wed, 2005-08-17 at 08:03 +0100, Keith Edmunds wrote:
> Charles Duffy wrote:
> > Hmm. See, my concern is protecting inappropriate files on host from
> > being accessed. Perhaps I'll want to use a different security layer in
> > addition to application-based measures.
On Tue, 16 Aug 2005 23:44:42 -0500, Ben Escoto wrote:
> Ok I added
>
> rm -rf $RPM_BUILD_ROOT/usr/share/doc/*
>
> at the end of the %install section. I don't really understand why
> this would help, but it didn't seem to hurt.
To explain why it helps: Otherwise, on a distro which places doc
f
On Wed, 2005-08-17 at 01:33 -0500, Ben Escoto wrote:
> >>>>> Charles Duffy <[EMAIL PROTECTED]>
> >>>>> wrote the following on Tue, 16 Aug 2005 23:58:22 -0500
> >
> > If they aren't in the list of allowable commands, why am I seeing the
On Tue, 2005-08-16 at 23:30 -0700, dean gaudet wrote:
> that's my bad really -- you actually only need a single special backup
> key... and you can clone the /root/.ssh/authorized_keys2 file everywhere
> with that one key.
Yes, and I realize that -- but it doesn't address the [important] "hosts
On Tue, 2005-08-16 at 23:24 -0500, Ben Escoto wrote:
> >>>>> Charles Duffy <[EMAIL PROTECTED]>
> >>>>> wrote the following on Tue, 16 Aug 2005 01:07:32 -0500
> > While trying to implement the previously-discussed feature (adding a
> > prefi
On Tue, 2005-08-16 at 15:54 -0400, Aaron Davies wrote:
> I'm trying to upgrade to v1.0.0 before I fiddle around with my backup
> issues any further, and I'm having an issue getting it to run on my
> target box, an old Mac running Jaguar (OS X 10.2). Python is v.2.3.3,
> as installed by fink,
Charles Duffy wrote:
Going back to the path-prefixing feature, I have a patch that appears
to work under *very light* testing
...which, on further light testing, has turned up some issues (caused,
roughly, by os.path.join trying to be excessively smart).
An updated version is attached
The spec file provided in the rdiff-backup tarball has documentation
files covered with %doc entries under the %files section, but also
(apparently) puts them in place [more specifically,
$RPM_BUILD_ROOT/usr/share/doc/rdiff-backup-1.0.0] during the distutils
install phase. The issue with this i
While trying to implement the previously-discussed feature (adding a
prefix to all remotely-provided paths in server mode), I've come upon
what appears to be a bug in the server-mode security model.
Tue Aug 16 00:24:51 2005 Server sending (0): None
Tue Aug 16 00:24:51 2005 Client received (0)
Howdy. I'm interested in adding a new option to rdiff-backup to enforce
a prefix for local paths in server mode -- not by throwing an exception
if a path is requested outside this prefix (as done by the --restrict
option), but by prefixing this path to all requests made.
This will allow me to s
57 matches
Mail list logo
