First, I’d like to thank the developers for their hard work.
I need to backup two folders located on different hard drives. My file list:
C:/directory1
D:/directory2
I use the following command:
rdiff-backup.exe backup --include-globbing-filelist C:/path/to/filelist
--exclude '**&#
All of a sudden, one backup server (previously working for some time) is
failing on any request to rdiff-backup. For example;
root@safe:~# rdiff-backup --version
Traceback (most recent call last):
File "/usr/local/bin/rdiff-backup", line 32, in
rdiff_backup.Main.error_
Salut Patrik,
By default, when running "rdiff-backup src dest", any extraneous files in
the destination are deleted and only available in the rdiff-backup-data
directory. In my new use case, when I run "rdiff-backup", I want to keep
files in the destination as normal fil
Peace and love, folks!
I plan to backup some files from ‘/home’ daily, and some other files there with
a separate backup command, weekly.
Is it safe to send both backups to the same backup directory?
For example,
/home/alex/.bashrc — backup daily.
/home/alex/.mozilla/firefox/something.default
«holes», and then weekly backups partly
filling those holes.
Is that OK? Or could there be some side effects of writing different backups to
the same directory, and it’s better to send them to different directories?
Something like, daily:
rdiff-backup -v 5 --api-version 201 backup --preserve
On 11/19/23 06:42, EricZolf wrote:
Hi,
I'm especially looking at Frank, but perhaps some SuSE packager is
here, or anybody else with specific needs.
As a long time Fedora and RH/Centos user I would hate to see
rdiff-backup disappear from the repositories.
I have seen packages drop th
> rdiff-backup -v9 --api-version 201 backup --print-statistics
testingbackup testingbackup-backup
Perfect! Thanks.
Wayne Sallee
[1]wa...@waynesallee.com
[2]http://www.WayneSallee.com
Original Message
*Subject: * Re: this command line interface
s readable.
Wayne Sallee
[1]wa...@waynesallee.com
[2]http://www.WayneSallee.com
Original Message
*Subject: * Mailing list messing up my posts.
*From: * Wayne Sallee [3]
*To: * Rdiff-backup-users [4]
*CC: *
*Date: * 2023-7-15 02:37 PM
I use my lfs build: [1]http://waynesallee.com/linux.html
I installed rdiff-backup from source. Then later upgraded from source.
On your computer terminal, if you type man rdiff-backup, and scroll
down to the bottom, you will see the version number. But if you go to
the webpage [2
Original Message
*Subject: * Re: this command line interface is deprecated
*From: * Ericzolf [1]
*To: * Rdiff-backup-users [2]
*CC: *
*Date: * 2023-7-15 05:19 AM
Hi,
What api is it talking about?
I tried adding "--api-version 201&qu
Never mind on that one. It never had a progress bar. :-)
Wayne Sallee
[1]wa...@waynesallee.com
[2]http://www.WayneSallee.com
Original Message
*Subject: * Upload File Transfer Status Progress Bar Missing
*From: * Wayne Sallee [3]
*To: * Rdiff
ee [3]
*To: * Rdiff-backup-users [4]
*CC: *
*Date: * 2023-7-14 11:52 AM
I downloaded rdiff-backup-2.2.5 and installed, but the man page did
not get updated.
My man page is still Version 1.2.8
Any advice?
Wayne Sallee
[5]wa...@waynesallee.com
Hello
when running "rdiff-backup-delete" an error message pops up:
fail to acquired repository lock. A backup may be running.
However, there is no other backup, neither
rdiff-backup nor rdiff-backup-delete.
Trying to indentify a LOCK file, for example by
find /mnt/uSbdisk/FOLDER/rd
Hello,
I deploy rdiff-backup for a few major main directories (source).
One of these main folders on backup media causes problems according to
rdiff-backup -v9 --check-destination-dir /mnt/usbdisk/FOLDER
The most recent error message is:
EOFError: Compressed file ended before the end-of-stream
Hello group,
I figured this was a better place to get help than posting to the GitHub issues
location.
Had been using rdiff-backups from around late 2021 to early 2022 while I was
displaced due to renovations. I was using it based on an article here
https://opensource.com/life/16/3/turn
Hi,
Let ".abc" be an arbitrary filename extension. A lot of files with this
filename extension
were backed up with rdiff-backup without having been excluded in a proper
exclude-file-
list (It goes without saying that exclusion of unwanted files is the better
option).
Now I have t
Thanks a lot for your e-mail and sorry for my late response.
A partition on my customer's computers has 900+ GB data which are backed up by
rdiff-
backup on a daily basis (increment). The average daily data volume to be backed
up (due
to changes) is about 300 MB.
The rdiff-backup &q
Hello!
Is there a reason why the -v2 etc parameters can't be entered after the
plain mode parameter?
rdiff-backup -v2 backup ...
vs
rdiff-backup backup -v2 ...
Took me a while to figure out why the latter doesn't work. :)
Thanks and good luck!
Reio
On 18.12.2022 12:54, EricZolf
On 2023-01-03 13:49, Robert Nichols wrote:
On 1/3/23 11:44 AM, Robert Nichols wrote:
I have one rdiff-backup installation for which "rdiff-backup
--version" reports "rdiff-backup 2.2.0" and another which reports
"rdiff-backup 2.2.2". The problem:
1. On both
In the context of rdiff-backup the option „--remove-older-than timeInterval“
removes old
increment files thus freeing up space on backup media. A recommended
timeInterval is
„52W“ which stands for „52 weeks“. After having run the rdiff-backup with this
option, it is
not possible to restore a
Hello,
could somebody shed some light to the question of restoring files backed up by
rdiff-
backup, please?
Given an original file, say file A. It will be backed up with rdiff-backup, and
also
its increments (assuming that there are many changes to file A).
When restoring a given version
y the current_mirror file.
Use rsync with --delete to do that.
Thanks, Chris.
On Thu, 23 Dec 2021 at 11:24, Reio Remma via Any discussion of
rdiff-backup wrote:
Hello!
I'm migrating my backups from an LVM volume to ZFS dataset,
however after rsyncing the data over, I'm gettin
Hello!
I'm migrating my backups from an LVM volume to ZFS dataset, however after
rsyncing the data over, I'm getting the following error:
$ rdiff-backup --verify backup-zfs/hostname
Warning, two different times for current mirror found
Fatal Error: Metadata file
'/mnt/back
partially
due to the fact the rdiff-backup needs to apply each increment as a patch,
stepping backwards until the desired state is achieved.
Is there a simple way around this? I wouldn't mind taking up the space
needed for a full snapshot if there is some argument that can accomplish
this, bu
On 2021-06-01 10:32 a.m., Yves Bellefeuille wrote:
Alvin Starr wrote:
I thought rdiff-backup like rsync keeps track of the file metadata
like size and creation date to skip reading the data again if the
file has not been updated?
I assume rdiff-backup does the same thing to decide if a file
On 2021-06-01 10:20 a.m., Yves Bellefeuille wrote:
"Jonas Schoepf"
My drive is connected via USB.
I think we're on the right track. What version of USB?
Before using rdiff-backup I used just rsync, where the initial backup
took also quite long, but the following b
Seems it does a lot of lstat() during run with option `--check-destination-dir`
Which is fallback in case backup can’t be finished. Hm.
>Среда, 12 мая 2021, 22:44 +09:00 от Andrei Enshin :
>
>Hi,
>
>Thank you for the explanation.
>
>During backup rdiff-backup did lstat
Okay, seems I can see the reason of such behavior.
Sorry for disturbing with such questions.
We do run backup every 4 hours and seems there is 7200 seconds timeout. It
means rdiff-backup will be killed and then we will run it again with
`--check-destination-dir` option which causes very
Seems it does a lot of lstat() during run with option `--check-destination-dir`
Which is fallback in case backup can’t be finished. Hm.
>Среда, 12 мая 2021, 22:44 +09:00 от Andrei Enshin :
>
>Hi,
>
>Thank you for the explanation.
>
>During backup rdiff-backup did lstat
Hi,
Thank you for the explanation.
During backup rdiff-backup did lstat for
/some/path/rdiff-backup-data/increments/foo/bar
which returned — ENOENT .
Does it mean it tried to check some file in increments which is not here?
If it is not in increments, does it mean it was never backed up?
If
Hi rdiff-backup folks,
Since recent, during backing up I can see spike in IOPS up to 500 which exhaust
limit of a VM. Therefore backup process takes very long. I've straced a bit and
what I can see is: many failed lstat() syscalls:
% time seconds usecs/call callserrors sy
Using mailing lists is a bit new to me so I hope this will end up in the right
place, otherwise I'm sorry!
With regards to deleting files taking a long time, I didn't mean that the
actual file operations would be slow but rather that I have a pretty extensive
exclude list with a bunch of globbi
On 2020-07-25 12:24 p.m., rainbowx--- via Any discussion of rdiff-backup
wrote:
Hello,
I upgraded my rdiff-backup from version 1.2.8 to version 2.0.0 (the latest that was
installed on Ubuntu 20.04 when just doing "apt install rdiff-backup") and ran a
backup to my usual backu
Hello,
I upgraded my rdiff-backup from version 1.2.8 to version 2.0.0 (the latest that
was installed on Ubuntu 20.04 when just doing "apt install rdiff-backup") and
ran a backup to my usual backup location.
Unfortunately my exclude file has Windows (CRLF) line endings and I was struc
On Wed, 13 May 2020 at 15:42, RL wrote:
>
> rufus@Air-PC:~/WK/testin> rdiff-backup -v3 --include
> /home/rufus/WK/testin/dummy --exclude ** /home/rufus/WK/testin
> /home/rufus/WK/testout2
> Fatal Error: Switches missing or wrong number of arguments
> See the rdiff-backup
am planning on "updating" my backup hardware, and will
> probably switch from rsync to rdiff (I have used rsync for many years, and
> have been happy with it, except for that one time years ago when I deleted
> a
> bunch of files and did not notice until about a day later, an
ut open to discussion) that it's best
> done if one person does it in one go. e. Once this is done, I would second
> Patrick's suggestion and create an rdiff-backup project, open it to the
> community and push my repository to there for further common work (I wouldn't
&
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto:rdiff-backup-users-
> bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of Dave
> Kempe
>
> we just renewed rdiff-backup.org domain rego. It redirects
> to http://www.nongnu.org/rdiff
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto:rdiff-backup-users-
> bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of Frank
> Crawford
>
> Firstly, what version of rdiff-backup do most people use? There is the
> stable 1.2.8 an
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto:rdiff-backup-users-
> bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of Alvin
> Starr
>
> Clearly there are hundreds of better ways to back up a sparse file.
>
> The point is
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto:rdiff-backup-users-
> bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of Alvin
> Starr
>
> Has any progress been made on getting rdiff-backup supported again?
>
> I ran into a qu
Ron, I'm not answering your question, as I see Thomas has already done a good
job. ;-)
I'm the "official" maintainer on rdiff-backup now, but it doesn't mean I do a
lot (super busy with paid work)... But there's a specific question I'd like to
ask y
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto:rdiff-backup-users-
> bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of Joschka
> Tillmanns
>
> I wrote a web interface for rdiff-backup in google's new language
> golang. I co
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto:rdiff-backup-users-
> bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of Grant
>
> I'm struggling to devise an incremental, automated backup scheme that
> remotely and securely
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto:rdiff-backup-users-
> bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of Ibrahim
> Dembele
>
> I am working on a project which consist to use rdiff-backup to make
> backup of data on
You're awesome. Thank you. I spent the weekend dealing with server problems -
I'll have to continue a little more - but then should be able to get back to
this.
> -Original Message-
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto
d to learn CVS would legitimately be an obstacle to
acquiring new developers. I figured svn will not be an obstacle. I figured
git is a double-edged sword. As you said, it's "the new hotness," (or "hot
mess?") ;-) but I don't believe running git will *attrac
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto:rdiff-backup-users-
> bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of Kevin
> Fenzi
>
> Sure. If we can document how to setup and test we could also get others
> doing them.
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto:rdiff-backup-users-
> bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of Kevin
>
> Greetings.
>
> Now that there is a maintainer again, perhaps he would be willing to
&
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto:rdiff-backup-users-
> bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of KP
>
> I am trying to use rdiff-backup. Client is OS X 10.7.5, using v 1.2.8.
> Backup
> host is NAS4F
I converted the source repository from CVS to Subversion. I don't think
anybody cares except me, and future maintainers, but here's the official
announcement anyway. ;-)
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto:rdiff-backup-users-
> bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of Ans
> Alghamdi
>
> I just find it a bit odd that this powerful tool does not have any bug fix (if
> ther
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto:rdiff-backup-users-
> bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of Dominic
>
> Great to have you onboard as maintainer Ned!
You speak too soon. ;-)
> The wiki pages would not
> From: rdiff-backup-users-bounces+rdiff-
> backup=nedharvey@nongnu.org [mailto:rdiff-backup-users-
> bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of Joe
> Steele
>
> That's too bad. I recall that the wiki had some useful info.
>
> The internet a
below this
one.
-Eric
From [EMAIL PROTECTED] Mon Jan 22 13:35:34 2007 -0800
Date: Mon, 22 Jan 2007 13:35:34 -0800 (PST)
From: [EMAIL PROTECTED]
To: rdiff-backup-users@nongnu.org
Subject: CRC check Failed
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; chars
using rdiff-backup to back up rdiff-backup repos. As long as you structure
the directorys right, its works really well.
When searching for the rdiff-backup-data directory, does rdiff-backup
check top down, or bottom up?
An addendum to that (and maybe this was actually your question?) is how
rdiff-b
On Thu, 16 Aug 2007, Andrew Ferguson wrote:
When searching for the rdiff-backup-data directory, does rdiff-backup
check top down, or bottom up?
rdiff-backup takes the 'dumb' approach of appending "rdiff-backup-data"
to the second argument, not even bothering to search:
[.
On Fri, 17 Aug 2007, Dave Kempe wrote:
While i agree with everything Andrew has said regarding long filenames and
such - on filesystems that don't require escaping, we have had no problems
using rdiff-backup to back up rdiff-backup repos. As long as you structure
the directorys right
On Thu, 12 Jul 2007, Andrew Ferguson wrote:
if I try to start a server on OSX via SSH, an error occurs:
---
sh: line1: rdiff-backup: command not found
---
rdiff-backup _is_ in the
On Mon, 9 Jul 2007, Andrew Ferguson wrote:
Step A, Backup Sync:
1. Write changes as diffs against the current repository into
something like $REPO/rdiff-backup-data/scratch/.
2. Simultaneously, write changes as rdiffs against the will-be new
version for placement in $REPO/rdiff-backup-data
$REPO/rdiff-backup-data/scratch/.
2. Simultaneously, write changes as rdiffs against the will-be new
version for placement in $REPO/rdiff-backup-data/increments/.
Step B, Commit of Sync; may be done offline (CRITICAL SECTION):
1. Patch all of the current $REPO against rdiff-backup/data/scratch
I have been giving thoughts to breaking rdiff-backup's meta-data code into
a normalized abstraction to unlink rdiff-backup from its meta-data
storage. This would allow meta-data to be stored in an SQL server, DBM,
flat file (current) or quantum goo (future?).
Creating meta-data inter
on-dir happily crashes:
[EMAIL PROTECTED] backup]# rdiff-backup --check-destination-dir Luna
Exception 'CRC check failed' raised of class '':
We've had this exact problem and there's fixes floating around the mail
archives. Basically, find any zero-byte .gz files,
backup]# rdiff-backup --check-destination-dir Luna
Exception 'CRC check failed' raised of class '':
We've had this exact problem and there's fixes floating around the mail
archives. Basically, find any zero-byte .gz files, in the
rdiff-bakcup-data directory, delete &
On Thu, 17 May 2007, dean gaudet wrote:
If you have large 1.0.5 repositories, can you test upgrades to 1.1.x from
1.0.5 and see what kind of metadata needs fixed up? Regression procedure
which comes to mind is:
rdiff-backup-1.1.x /some/data /backup/1.0.5-data/
rdiff-backup-1.1.x --check
On Wed, 16 May 2007, Dimi Paun wrote:
This is release 1.0.0 of SafeKeep, a centralized and easy to use
backup application that combines the best features of a mirror
and an incremental backup.
Wow! I must say that what SafeKeep is doing with rdiff-backup is
something I have been meaning to
ing on the community to provide enough proof that 1.1.x is
actually stable.
Dean,
If you have large 1.0.5 repositories, can you test upgrades to 1.1.x from
1.0.5 and see what kind of metadata needs fixed up? Regression procedure
which comes to mind is:
rdiff-backup-1.1.x /some/data /backup/
About v0.11.1, the changelog reports (roughly) the following:
---
Now rdiff-backup writes metadata (uid, gid, mtime, etc.) to a
compressed text file in the rdiff-backup-data directory. Here are
some ramifications:
[...]
Some files may be recognized
On Fri, 30 Mar 2007, Baldur Norddahl wrote:
I want to use rdiff-backup with my Postgresql database. The problem is that
the tool refuses to backup files that are changing.
We simply pg_dumpall > /backup/sqldump.sql and then rdiff-backup the
/backup directory. Then you don't have
correctly what is happening here?
-Eric
Example:
$ ls -a test1
. .. file1 test2 test4
$ ls -a test1/test2
. .. file1 .NOBACKUP test3
$ /tmp/bin/rdiff-backup --exclude /**/.NOBACKUP /tmp/test1 /tmp/backup_test
$ ls -a backup_test
. .. file1 rdiff-backup-data test2 test4
$ ls -a
How similar to this is rdiff-backup --exclude /**/.NOBACKUP ?
-Eric
On Thu, 15 Mar 2007, dean gaudet wrote:
excellent, i've wanted this feature... i'll apply it next time i'm running
through patches. any chance you could do a 1.1.x port as well?
thanks
-dean
On Thu, 15
ghby wrote:
Hello everyone,
I have been using rdiff-backup at the company where I work to back
up about 500 GB of data. In order to simplify management of this data I
needed to split that one large archive into lots of smaller archives
while preserving historical increments. I wrote a quick
Greg,
We perform rdiff-backups for our customers and charge a hosting fee. We
are currently rdiffing as much as ~400GB for some customers and are
entertaining a new ~3TB backup. If you are able to get us an initial
image of your data and a place to ssh into with rdiff-backup 1.0.5, we can
On Sun, 25 Feb 2007, Luke Scott wrote:
On Sun, 2007-02-25 at 16:07 -0800, Eric wrote:
Yes and no. Basically, when /rdiff-fs/10-11-2007/some/file is accessed,
it performs a
"rdiff-backup --restore-as-of 10-11-2007 /backups/some/file /tmp/file" and
proxies the IO on /rdiff-fs/10-11
This would of course be a read-only mount.
I don't know what the storage size impact is, because I don't know if
rsync keeps diffs of files, or if it stores whole copies and only uses
the rdiff algorithm for transport.
Only for transport... This is why tools like rdiff-backup exist.
I
On Sat, 24 Feb 2007, Luke Scott wrote:
My hope is to create an option in rdiff-backup so that instead of the
mirror directory containing duplicates of the original data, the mirror
contains *hardlinks* to the original data.
Your need gives me an idea which would be useful for our own
al data on the former.
_______
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.solutionsfirst.com.au/index.php/RdiffBackupWiki
On Mon, 5 Feb 2007, Richard Steven Hack wrote:
I recently was testing various versions of rdiff-backup for use on Windows,
but everything appeared to have problems either with large files > 4GB or
other issues.
Compile using the CVS version of librsync :) 4gb boundaries vanish, even
un
minimum of 1024.
We've had the same problem - does anyone know if I go find/change PATH_MAX
in /usr/include somewhere and recompile rdiff-backup/librsync if it will
fix the problem?
-Eric
___
rdiff-backup-users mailing list at rdiff-backup-
On Mon, 29 Jan 2007, dean gaudet wrote:
here's a new release to fix the merge error in 1.1.8. enjoy!
-dean
Thank you for staying atop of maintenance, Dean!
-Eric
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
On Fri, 26 Jan 2007, Marc Dyksterhouse wrote:
Hi all,
I had some issues backing up a linux machine to a Windows box using
rdiff-backup. I got passed all my (known) issues today so I wanted to submit
the fixes so others could take advantage of them. I started with version
1.1.7
times on the mailing list, and so far there
is not a good fix for it. DEVELOPERS: If you can think of a good fix
which could be added to --check-destination-dir, this would be wonderful!
I don't know enough about the inner workings of the rdiff-backup-data
tree, but usually this error ap
We are using 1.0.4 and it has been running stable for many months. Every
once in a while this CRC check comes across and in the past, the only way
we knew to resolve it is to remove the rdiff-backup-data directory and
start over. --check-destination-dir also fails with the same error
I am trying to run rdiff-backup (v. 1.1.7) in windows from a batch
script. The destination directory is on a linux drive that is mounted
via samba. For some of the directories I'm backing up, this works fine.
However, on some the backup stops in the middle and I get the errors
listed
Core 5 and found that rdiff-backup does work on files
4gb. We are rdiffing a 20gb Windows BKF file which changes every
night. md5sums match after each backup. If anyone is curious, download
the FC5 librsync-0.9.7-7.src.rpm and have a look-see at the patch which
comes with it.
We'v
I back up my entire system with rdiff-backup to a local drive, then
rsync the entire rdiff-backup over to another box. I backup email,
Postgresql, Mysql, Apache, etc.
Just be aware that unless you are taking special precautions, the
postgresql backup is not guaranteed to be consistent. I am
Hi,
I am using rdiff-backup to handle backups of both linux and WinNT4 systems to a
linux machine.
I'm hitting the error below for a set of files on the WinNT4 machine ("Text
file busy") - looks like the files are in use, and so the NT share refuses
access to the file. I get
The CVS may be old, but the last stable release was "Version 1.0.4,
released January 15th 2006, is the current stable version." released from
the website.
http://www.nongnu.org/rdiff-backup/
We have had very few problems with it. If the backup was successful, it
will restore.
On Fri, 21 Jul 2006, Karjala wrote:
Has anyone managed to automate rdiff-backup on a windows machine?
Try the windows AT command?
-Eric
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo
On Tue, 18 Jul 2006, Jes Kasper Klittum wrote:
The link is e1000 in both ends, so there should be no lag. It may be a
timeout
issue, though, is there a built in timeout in the rdiff connection that I
could tweak?
Is it e1k <--> e1k via cross cable or switch? Some older e1000
On Fri, 7 Jul 2006, Karjala wrote:
How do we do that?
It compiles nicely under cygwin. We backup windows to unix with
cygwin+ssh+rdiff nightly.
-Eric
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
http
On Mon, 3 Jul 2006, Noah wrote:
So Im temporarily using another machines for backups until I sort out my
rdiff-backup version mismatch issues between client and server.
I am wondering if somebody has had experience moving rdiff-backup backup data
- the entire directory - between machines
function)
_librsyncmodule.c:386: structure has no member named `patch_job'
_librsyncmodule.c:387: `RS_DONE' undeclared (first use in this function)
_librsyncmodule.c:387: `RS_BLOCKED' undeclared (first use in this function)
_librsyncmodule.c: In function `init_librsync':
_librsyncmodule.c:4
ED]>
To: "Jason Faulkner" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, May 24, 2006 11:53 PM
Subject: Re: [rdiff-backup-users] rdiff-backup performance stats.
On Wed, May 24, 2006 at 05:49:35PM -0400, Jason Faulkner wrote:
[EMAIL PROTECTED] wrote:
>
>
> Looks like something i
right now (30D worth of increments included),
and it's done in <10 hours, over a 1.5MBit internet line.
This is truly a kudos to the rdiff-backup dev team. People are using this
in production with hundreds of gigabytes of data, reliably. I am tr
ors 0
--
___
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.solutionsfirst.com.au/index.php/RdiffBackupWiki
etter luck. Seriously though, I'm not sure they should have
filenames that freaking long anyway .
-E
On Sun, 21 May 2006, dean gaudet wrote:
rdiff-backup requires a significant amount of extra space to fit its
filenames... at least until 1.1.x where ben has made it able to deal with
&quo
We are doing backups for directory paths which are extremely large. Is
there a way to tell if 'filename too long' is a rdiff-backup issue, or an
issue of our destination filesystem?
-Eric
ListError customerfolders/Plexus - WI - Plant4/722-4432-XXX/CAM/Mod to 24
pallets to
bri
Maybe we should check fail/success when looking in that directory and if
it fails, just give an error. If something is chmod 000, obviously
somebody wants to keep everything out.
-Eric
On Tue, 16 May 2006, The Anarcat wrote:
Here I am again. After having removed the rdiff-backup
ucessful backup (the one before it failed) which have no increments from
the backup which filled the drive (most recent).
The files which do have increments from the backup which filled the drive
need to have the increments applied in reverse to put the files back as
they were so that their
1 - 100 of 101 matches
Mail list logo
