Ok, I'm feeling stupid, but I can't make this work today..
Trying to restore a directory with all files and subdirs
The backup is something like this:
rdiff-backup c:/abc-data/ E:/abc-backup/main-data/
Both C and E are local
I want to restore:
c:/abc-data/way/down/the/path/directory/
So,
I know this discussion ended, in practical terms a while ago, but I
started some thoughts back then, and didn't have time to finish them.
So, I did so today, and thought they might be helpful in a conceptual
way.
One way to cut down on verify times would be to limit the number of delta's in
the
[Inline]
On Nov 25, 2009, at 12:25 PM, listserv.traf...@sloop.net wrote:
snip explanation of how rdiff-backup works
Sounds good.
So, a --verify isn't needed to verify the current files. The very
nature of RDB is that they're exact. (provided you trust the RDB
protocol...which we assume.)
I mis-posted, and should have replied to the list, instead of just
Daniel...so here it is...
---
I'm not sure what you're doing with your --verify... [I'm confused, I
think...]
It *sounds* like you want a full CRC style check of the *current*
files after the backup is complete. (i.e. File X gets
[Now I'm bottom posting... :)]
---
I'm not aware, so if I'm wrong perhaps someone could correct me, but
I'd like a command to, in essence, do a comprehensive
--verify-all-files-in-the-archive. [I'm pretty sure such a thing
doesn't exist, at least I never saw it in the docs.]
This would
See inline...
I'm not sure what you're doing with your --verify...
It *sounds* like you want a full CRC style check of the *current*
files after the backup is complete. (i.e. File X gets updated with a
delta, and you want to verify that file X is the same both on the
source and destination
I know Matt corrected this post, but I wanted to address this:
---
If you do a --verify-at-time xyz where xyz is your oldest backup, it
should verify all files in that backup - so every delta should be
applied. This should verify that all delta's (backups) are good and
functioning.
[In short, it
While this isn't strictly on-topic about rdiff-backup, it is
quasi-on-topic.
I've gotten RDiff-Backup and volume shadow service working at the
same time on XP/2003/Vista - so I can backup anything regardless of
it's in-use status: registry, system files, etc.
The question now is:
-Has anyone
I posted this last week, but got no feedback - so I tried poking
around a bit, and trying some stuff from the FAQ and the mailing list.
However...
*** I THINK I NOW KNOW WHAT IS WRONG ***
The whole path of the file and it's name exceeds 256 characters.
(I figured this out by trying to create the
Exception '[Errno 2] No such file or directory:
'E:/rdiff-backup-rep2/data/rdiff-backup-data/increments/Engineering/illustrations/pdf/manuals/New/229_1021
(Utility Center Delivery assembly)/il1588 General Dimensions - Universal
Utility Center Delivery
Well, I spent some of yesterday getting shadow volumes to work on XP.
(They should work on XP, 2003 Server, and all flavors of Vista, IIRC
- the method I'm using should work on Vista home versions since the
volume shadow snapshot [vss] service is available on VH.)
If anyone wants this
I'm getting this error again. Last time I got it, I started a new
repository.
But it's back...
Here's a -v 6 listing around the error.
---
Processing changed file Shared-docs/Abc/Jiff's Document Info.1234.QBW.nd
Regular copying ('Shared-docs', 'Abc', Jiff's Document Info.1234.QBW.nd) to
I'm getting these errors.
Windows Binary 1.2.8, running on Server 2003
Local source and dest.
---
Incrementing mirror file E:/qxy-backup/main-data/Abc/SomeData/Active Clients
P-S/jones, q.IDX
Exception '[Errno 13] Permission denied: 'c:/qxy-data/Abc/SomeData/Active
Clients P-S/jones, q.QDF''
I have questions about regressing repo's
Environment:
Windows generally: using the win binary.
Source and dests are local disks, NTFS.
(It might be helpful to explain in generality, and then specific to
the above environment as it is different. I'm likely to add a topic
on it to the Wiki - so
I think this works...it's worth a try...
c:\rdiff\rdiff-backup.exe --remote-schema "c:\Program files\plink\plink.exe" -i "c:\Program files\security\privatekey.ppk" %s rdiff-backup --sever
Also, I'd change the backslashes to forward slashes...like so
c:\rdiff\rdiff-backup.exe --remote-schema
Wiki additions to the FAQ:
http://wiki.rdiff-backup.org/wiki/index.php/FAQs
Items 9 10.
Have at it.
-Greg
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL:
Are the exit codes the same, and available to cygwin event though
it's a windows binary? (I do see the output is the same unix style
output (with a unix vs dos line return).
The exit codes should be the same, but, truthfully, the state of rdiff-
backup's exit codes are not very good. I don't
listserv.traf...@sloop.net wrote:
I'm not sure if no 3 covers file errors like files being busy etc...
I'd guess that even if it did, I'd like a code that is basically
everything went smoothly, but some files were locked, or otherwise
unavailable.
This will tell us we got a good backup,
A few notes after some testing...
The Native windows version doesn't exhibit the same symptoms.
After backing up the same tree to the same location, a -l lists
Found 0 increments:
Current Mirror ...
Which is what I would expect.
---
This is the error I get with the cygwin version
$
One more note, if it makes any difference.
---
Under cygwin, it will continue to make diffs, and show multiple
increments in the rdiff-backup-data directory. (i.e. It won't
complain about an incomplete backup, and try to regress the state. It
will continue to make additional diffs, but then choke
Hello Andrew,
Monday, March 30, 2009, 6:24:47 PM, you wrote:
Greg,
As Jason suggested, I would try using the 1.3.3 version. That version
has the new --use-compatible-timestamps option which should clear up
your trouble.
I'll try and look into whether it makes sense to clean this up on
Since these issues seem to come up often, and they were issues I was
most concerned about, I thought I'd place them on the wiki.
Here's a draft: Comments welcome before I add them.
Did I state anything unclearly, wrong etc. Please save me from later
shame! :)
-Greg
---
Question:
What happens
Update: Re-read what I wrote - a few changes.
Also, included some notes that I didn't intend to include.
If you intend to proof, proof this second version...
---
Question:
What happens when I have to restore a file?
Answer:
If the file hasn't changed between current and the version of the
The default version of rdiff-backup in cygwin is 1.2.1.
I'd like to use a more current version.
I've downloaded the dev env for cygwin and run the build/make/install
for 1.2.8. (I needed more recent builds of another app, so this
is what started the need for a more recent version of
Yes, it looks like that is correct, based on my reading of the source,
and some quick experimentation.
Does that match with your experiments?
Andrew, et al.
It certainly appears to, though it's difficult to tell what it's
doing under the hood.
I can't tell if it is, for sure, taking the
as an aside
I plan to stage backup to a second hard-drive on-line in the system,
and then rsync a copy to a second disk.
Another option to consider is making the backup drive a RAID 1 volume.
Then the mirroring is automatic and occurs at backup time.
Matt Flaschen
True enough, but that
--verify-at-time xyz
Wondering about --verify-at-time xyz
What exactly does this switch do?
From my understanding of the man-page, it appears to recreate the
actual file based on the date used in xyz, and then compare a *new*
computation of the SHA1 hash with the SHA1 hash calculated and
stored
Follow-up on snap-shots of diffs.
From this thread ...
http://lists.nongnu.org/archive/html/rdiff-backup-users/2009-01/msg00118.html
I'll quote a bit...
---
On Jan 16, 2009, at 7:00 AM, Michael Biebl wrote:
2.) If one of the rdiffs goes corrupt (e.g. via a bad sector), all my
older
Yeah, I'm only wanting to high-light problems with the backup for
user intervention - such as files that are open and can't be backed
up, destination disk full conditions etc.
I can build a list just by trial and error, but having a set of common
errors up-front would be a lot easier than going
[I'm not sure what the culture is about follow-ups on top, so pardon
me in advance if I violate the culture.]
The discussion about this on prior thread appeared to negate that
as the actual behavior...
I'll quote.
From this thread:
*almost: you don't need to save snap-shots every X days, only every X
times a file changed. For most files, this is a notable difference.
Yes, thanks for the distinction. That's what I intended. (Changes in
the source file.)
A regular restore usually means the data from _now_, or some point
*almost: you don't need to save snap-shots every X days, only every X
times a file changed. For most files, this is a notable difference.
Yes, thanks for the distinction. That's what I intended. (Changes in
the source file.)
A regular restore usually means the data from _now_, or some point
I have several questions, but I'll split them into separate posts so
they're better found and followed on the list for posterity purposes.
I don't think it really matters in this discussion, but in all the
cases I'm using RDiff-Backup currently, I'm using local resources -
either on the same
I read a discussion a while back about rolling back to a really old
version of a file in the repository/archive.
[A file with lots of reverse diffs to apply...]
To paraphrase what I read, but never got a good answer to, do you
have to start with the current version and apply all the reverse
34 matches
Mail list logo
