AW: [rdiff-backup-users] two different times for current mirror found
Hi, looks to me like the data in the file will be fine (it says "Every file verified successfully"); however, you seem to have defined some extended attributes that have not been preserved in the metadata. However, I am not a professional in rdiff repository reading, just take it as a good guess :-) Cheers, David. > -Ursprüngliche Nachricht- > Von: rdiff-backup-users-bounces+mail=dkriesel@nongnu.org > [mailto:rdiff-backup-users-bounces+mail=dkriesel@nongnu.org] Im > Auftrag von Valerio Pachera > Gesendet: Freitag, 5. November 2010 17:01 > An: Lista rdiff-backup > Betreff: [rdiff-backup-users] two different times for current mirror found > > I have 3 backup folders for 3 backups made from a windows computer to a > debian lenny. > Both sides there is v 1.2.8. > > rdiff-backup --verify folder1 > Warning, two different times for current mirror found > Warning: Extended Attributes file not found Every file verified successfully. > > What does that mean? > What can cause this? > > ___ > 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 ___ 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
[rdiff-backup-users] Completely remove files / subfolder trees from RDiff repository
Dear List, I keep getting errors "SHA1 digest doesnt't match" in verification caused by some files that are not important to me. However, these errors are quite a bit nasty because they make the verification cronjobs send me e-mails. As far as I understood the documentation of RDiff, in order do completely remove given files and all of ist traces from a rdiff repository, I have to 1) delete the file in the mirrordata 2) delete all the increment and other files in the respective folder oft the rdiff-backup-data/increments folder 3) traverse all the metadata snapshots and mirrors and remove any traces oft hat file. Is this assumption correct? Now, here's the main question: Is there a command for rdiff that does the job automatically? Especially traversing all the metadata can be a pain in the ass even for one single file to remove. The best implementation would be something like the include/exclude syntax which then is matched throughout all of the three steps above. Optionally, it would be great to leave the rdiff repository in an recognizably intermediate state, that can be regressed if the operation fails, but this is not important (shouls be just common sense to keep a copy of your repository when performing such operations). If there is no commandline parameter that does the job (I have not found any), then I would like to request the feature ... :-) Cheers, David. -8< David Kriesel http://www.dkriesel.com Rheinische Friedrich-Wilhelms-Universität Bonn (University of Bonn) Department of Computer Science I Computational Geometry Römerstr. 164 53117 Bonn Germany Personal: Graurheindorfer Str. 75 D-53111 Bonn Germany Phone: +49 177 423 4223 Current geographical location in Google Earth: N 50°44'42.45" E 7° 5'44.09" (just to be copied in the search field) ___ 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
[rdiff-backup-users] Rdiff backup still chokes if read-only files are found at target
Hi guys, I have rdiff crashing when read-only files are in the rdiff repository. It gives the following Exceptions: Exception '[Error 5] Zugriff verweigert: 'D:\\/rd/data/home/kwasny/Eigene Dateie n/Eigene Bilder'' raised of class '': File "rdiff_backup\Main.pyc", line 306, in error_check_Main File "rdiff_backup\Main.pyc", line 326, in Main File "rdiff_backup\Main.pyc", line 282, in take_action File "rdiff_backup\Main.pyc", line 345, in Backup File "rdiff_backup\backup.pyc", line 51, in Mirror_and_increment File "rdiff_backup\backup.pyc", line 251, in patch_and_increment File "rdiff_backup\rorpiter.pyc", line 277, in __call__ File "rdiff_backup\rorpiter.pyc", line 229, in finish_branches File "rdiff_backup\backup.pyc", line 676, in end_process File "rdiff_backup\rpath.pyc", line 993, in rmdir Traceback (most recent call last): File "rdiff-backup", line 30, in File "rdiff_backup\Main.pyc", line 306, in error_check_Main File "rdiff_backup\Main.pyc", line 326, in Main File "rdiff_backup\Main.pyc", line 282, in take_action File "rdiff_backup\Main.pyc", line 345, in Backup File "rdiff_backup\backup.pyc", line 51, in Mirror_and_increment File "rdiff_backup\backup.pyc", line 251, in patch_and_increment File "rdiff_backup\rorpiter.pyc", line 277, in __call__ File "rdiff_backup\rorpiter.pyc", line 229, in finish_branches File "rdiff_backup\backup.pyc", line 676, in end_process File "rdiff_backup\rpath.pyc", line 993, in rmdir WindowsError: [Error 5] Zugriff verweigert: 'D:\\/rd/data/home/kwasny/Eigene Dat eien/Eigene Bilder' Sounds similar to me like the old read-only file issue. http://www.mail-archive.com/rdiff-backup-users@nongnu.org/msg03549.html Any advice? Cheers, David -8< David Kriesel http://www.dkriesel.com Rheinische Friedrich-Wilhelms-Universität Bonn (University of Bonn) Department of Computer Science I Computational Geometry Römerstr. 164 53117 Bonn Germany Personal: Graurheindorfer Str. 75 D-53111 Bonn Germany Phone: +49 177 423 4223 Current geographical location in Google Earth: N 50°44'42.45" E 7° 5'44.09" (just to be copied in the search field) ___ 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
AW: [rdiff-backup-users] Rdiff backup still chokes if read-only files are found at target
Anybody here? ;-) The list seems to be a bit quiet. If this is the wrong place for this report, someone please tell me the correct one :-) I feel I did not provide enough information to get rid of the below bug. So, here you go: 1. I am using rdiff 1.3.3 for a local backup on a windows server 2003 32bit machine. 2. I am using the windows release that can be downloaded on rdiff-backup.nongnu.org as rdiff-backup-1.3.3-win32.zip. 3. My rdiff call is: rdiff-backup --force --no-acls --no-hard-links --print-statistics --include "D:\\/home" --include "D:\\/profile" --exclude "D:\\/share/ElRv-Daten" --include "D:\\/share" --exclude "D:\\/**" D:\/ D:\/rd/data 4. "Zugriff verweigert" in the below message is german for "permission denied". When checking the folders, I found that the ACL entries are okay, but the read-only flag on the "Eigene Bilder" folder was set. So all in all, it seems to me that rdiff cannot remove this flag from folders. Below linked you find a similar problem with files. Next, windows prevents rdiff from deleting a folder that is still marked "read-only". Consecuently, Rdiff crashes. To support my concern, I can tell you that you find quite a number of read only folders on windows systems, because that windows itself uses the read only flag on folders differently than on files: see http://support.microsoft.com/kb/256614 . Additionally, the attribute setting for folders may be handled different (for example, you cant remove read only attribute on folders just using the explorer). Any help is appreciated, really... I like rdiff and dont want to chance the backup system (again)... Cheers, David > -Ursprüngliche Nachricht- > Von: rdiff-backup-users-bounces+mail=dkriesel@nongnu.org > [mailto:rdiff-backup-users-bounces+mail=dkriesel@nongnu.org] Im > Auftrag von D. Kriesel > Gesendet: Sonntag, 28. November 2010 01:52 > An: Lista rdiff-backup > Betreff: [rdiff-backup-users] Rdiff backup still chokes if read-only files are > found at target > > Hi guys, > > I have rdiff crashing when read-only files are in the rdiff repository. It > gives the following Exceptions: > > Exception '[Error 5] Zugriff verweigert: 'D:\\/rd/data/home/kwasny/Eigene > Dateie > n/Eigene Bilder'' raised of class '': > File "rdiff_backup\Main.pyc", line 306, in error_check_Main > File "rdiff_backup\Main.pyc", line 326, in Main > File "rdiff_backup\Main.pyc", line 282, in take_action > File "rdiff_backup\Main.pyc", line 345, in Backup > File "rdiff_backup\backup.pyc", line 51, in Mirror_and_increment > File "rdiff_backup\backup.pyc", line 251, in patch_and_increment > File "rdiff_backup\rorpiter.pyc", line 277, in __call__ > File "rdiff_backup\rorpiter.pyc", line 229, in finish_branches > File "rdiff_backup\backup.pyc", line 676, in end_process > File "rdiff_backup\rpath.pyc", line 993, in rmdir > > Traceback (most recent call last): > File "rdiff-backup", line 30, in > File "rdiff_backup\Main.pyc", line 306, in error_check_Main > File "rdiff_backup\Main.pyc", line 326, in Main > File "rdiff_backup\Main.pyc", line 282, in take_action > File "rdiff_backup\Main.pyc", line 345, in Backup > File "rdiff_backup\backup.pyc", line 51, in Mirror_and_increment > File "rdiff_backup\backup.pyc", line 251, in patch_and_increment > File "rdiff_backup\rorpiter.pyc", line 277, in __call__ > File "rdiff_backup\rorpiter.pyc", line 229, in finish_branches > File "rdiff_backup\backup.pyc", line 676, in end_process > File "rdiff_backup\rpath.pyc", line 993, in rmdir > WindowsError: [Error 5] Zugriff verweigert: > 'D:\\/rd/data/home/kwasny/Eigene > Dat > eien/Eigene Bilder' > > > Sounds similar to me like the old read-only file issue. > <http://www.mail-archive.com/rdiff-backup-users@nongnu.org/msg03549.html> http://www.mail-archive.com/rdiff-backup- <http://www.mail-archive.com/rdiff-backup-users@nongnu.org/msg03549.html> > us...@nongnu.org/msg03549.html > > Any advice? > > Cheers, > David > ___ 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
AW: AW: [rdiff-backup-users] Rdiff backup still chokes if read-only files are found at target
> Following your posting, I have tested the behaviour of our system > backing up read-only folders and files with rdiff-backup, and it works > correctly, even when the read-only files change. We are backing up from > Windows machines but to a Linux server (using TimeDicer as wrapper for > rdiff-backup), I suspect this is where your problem lies. > > So a possible solution is to move your backup repository to a Linux > server, this could even be a VM hosted on your Windows machine. Dominic, thank you so far! I think setting up a linux server might be a solution, and will consider this, yes. We need a running backup and if this is the way to do, we need to do it. Moreover, I did not know timedicer so far. Reading the TODO list that includes a GUI, I suggest you to have a look on http://www.nongnu.org/jbackpack/ - this is a nice gui for RDIFF repositories. However, this does not solve the issue within rdiff-backup. Even though I could just install a linux machine, for many users this will not be an option Greetz from Bonn, David ___ 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
AW: [rdiff-backup-users] rdiff-backup fails, no gzipped file
Reading your error message, I agree there is no filename to be found - please run the rdiff-backup call once again, but with the parameter "--terminal-verbosity 5" added to the command line (of course you may exchange the parameter with -v5 to get the same console output, but in this case you will log the lots of regression messages to the logfile in the rdiff-backup-repository as well). I think this will reveal the gz-file in question. It should be the newest gzipped increment of the file that rdiff-backup tried to regress when the error occurs. If the filename is still not clear, try exchanging 5 to 8 and recall rdiff-backup again. Hope that helps, David. Von: rdiff-backup-users-bounces+mail=dkriesel@nongnu.org [mailto:rdiff-backup-users-bounces+mail=dkriesel@nongnu.org] Im Auftrag von ~D Gesendet: Sonntag, 5. Dezember 2010 19:01 An: rdiff-backup-users@nongnu.org Betreff: Re: [rdiff-backup-users] rdiff-backup fails, no gzipped file On 12/05/2010 06:42 PM, Dominic Raferd wrote: See Andrew Ferguson's response regarding this error message here: http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-list s-3/rdiff-backup-23/regression-fails-ioerror-not-a-gzipped-file-93222/ Andrew is the current maintainer of rdiff-backup so his word is law! It's not exactly clear which file I have to remove and how. Regards, ~D Von: rdiff-backup-users-bounces+mail=dkriesel@nongnu.org [mailto:rdiff-backup-users-bounces+mail=dkriesel@nongnu.org] Im Auftrag von ~D Gesendet: Sonntag, 5. Dezember 2010 19:01 An: rdiff-backup-users@nongnu.org Betreff: Re: [rdiff-backup-users] rdiff-backup fails, no gzipped file On 12/05/2010 06:42 PM, Dominic Raferd wrote: See Andrew Ferguson's response regarding this error message here: http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-list s-3/rdiff-backup-23/regression-fails-ioerror-not-a-gzipped-file-93222/ Andrew is the current maintainer of rdiff-backup so his word is law! It's not exactly clear which file I have to remove and how. Regards, ~D ___ 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
AW: AW: [rdiff-backup-users] rdiff-backup fails, no gzipped file
On 12/05/2010 07:46 PM, D. Kriesel wrote: >>--terminal-verbosity 5 >It doesn't seems to give memore in the backup.log file then Yeah, this is what I tried to say, the parameter "-v5" would give you information on every single file in both the backuplog and the terminal, while the "--terminal-verbosity 5" only increases the verbosity on the terminal, but not in the backup.log. David ___ 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
AW: AW: AW: AW: [rdiff-backup-users] rdiff-backup fails, no gzipped file
Try to rsync the complete rdiff repository to another place so you have a backup ... then you can safely try :) I am still wondering why there is no valuable information shown even in the verbose modes ... > -Ursprüngliche Nachricht- > Von: ~D [mailto:schoapp...@gmail.com] > Gesendet: Sonntag, 5. Dezember 2010 22:57 > An: D. Kriesel; rdiff-backup-users@nongnu.org > Betreff: Re: AW: AW: AW: [rdiff-backup-users] rdiff-backup fails, no gzipped > file > > On 12/05/2010 08:46 PM, D. Kriesel wrote: > > The last gz file that is mentioned seems to be > /home/backup/backup_laptop/rdiff-backup-data/rdiff-backup.tmp.0/5-_ > > a.snapshot.gz ... but there is so much after this, don't know if it is > > right ... > > > > > > > Hmm not sure about the next step to try to solve this... > > > ~D ___ 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
AW: AW: AW: AW: AW: [rdiff-backup-users] rdiff-backup fails, no gzipped file
> Do you prevent a shutdown or reboot when rdiff-backup is running? How? Since rdiff-backup does not like backup interruptions (and therefore is not usable on slow or unreliable connections) I rdiff to a local repository on the server (the server usually doesn't reboot) and rsync the entire repository to the remote destination. > > Regards, > > ~D > > ___ > 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 ___ 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
AW: [rdiff-backup-users] Severe performance degradation
Hi maarten, Some questions to help myself (and the list) helping: 1) Which file systems on source and target did you use before and after the server change? Which other ones did you try? 2) What kind of data do you have? Millions of dirs with millions of small files or millions of files in just a few dirs or several very large files (gigabytes) or all of them? > Still, what is observable is that any initial backup run (with --force) > runs significantly faster on the new server. Think so, too. > Any differential run > afterwards is slower than on the original server. I feel this proves > there are no performance bottlenecks in the network, disks, filesystems > etc of the server. > The new server runs rdiff-backup 1.2.8, the old one 1.0.5. Did you upgrade the remote server too? > Downgrading > the new server to 1.0.5 makes things a bit interesting: that speeds it > up a bit, but still a fair bit slower than the original. As of Rdiff-backup 1.1.1, hashing is done with sha-1, maybe this slows down a bit. Source: http://rdiff-backup.nongnu.org/CHANGELOG-stable > During investigation we experimented with different filesystems, testing > local versus remote backups, looking at compile flags and versions of > librsync and python, but we have had no success there. Did you try reiserfs (nice with lots and lots of small files)? ___ 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
AW: [rdiff-backup-users] Severe performance degradation
> Probably something above 5. Yeah, please give it a 8 ... maybe then make it a --terminal-verbosity 8 rather than -v8 so that you don't let the backup-log in the target explode ... ___ 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
Re: [rdiff-backup-users] [PATCH] Sparse file support
I would also love you to be proved wrong, but some weeks ago i asked the head developer if he is still active in the project and did not even get an answer. "Dominic Raferd" schrieb: >On 03/01/2011 20:27, Eric Wheeler wrote: >> On Sun, Jan 02, 2011 at 08:11:00PM -0800, Eric Wheeler wrote: >>>> Feedback and comments are appreciated! >> Original Message- >> From: Matthew Miller> >>> How will this interact with existing backups? >> rdiff-backup re-writes changed destination files, so if a source file >> changes, rdiff-backup will write the whole file after calculating a >> reverse-diff for the increment tree. >> >> Existing backup trees will become sparse over time, as files change. >> >> -Eric >So I guess it is forward-compatible, but not backward-compatible? >Existing repositories can be read fine with rdiff-backup patched for >sparse file support, but repositories created with sparse file support >cannot be read by unpatched rdiff-backup. That's okay, but it might >make >most of us feel that we would rather not use this patch unless we >specifically need it, until it is part of mainstream rdiff-backup. > >Sadly, development of rdiff-backup has gone silent for a while now. I >think these patches are great (as were Daniel Miller's a while ago, >which provided a --verify-full option) but no one from the development >side seems to be updating the code at the moment. (I would love to be >proved wrong.) > >- Dominic > >___ >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 -- D. Kriesel / dkriesel.com ___ 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
Re: [rdiff-backup-users] Re: What happens if you add a --exclude to an existing rdiff-backup?
Hi, according to rdiff-backups doc, excluded files are just treated as if they would not exist. This means that a snapshot of such a file will be created in the metadata once a backup run with the exclusion is performed, and the file will be deleted from the mirror data. Cheers, david "Dominic Raferd" schrieb: >I agree that makes sense in terms of the question in the body of your >posting. But the subject of your posting was a slightly different >question: 'What happens if you add a --exclude to an existing >rdiff-backup?' > >If a week ago you added --exclude /home/fred to your rdiff-backup line > >backing up /home, will /home/fred now be removed from the destination >by >a "--remove-older-than 5D" run? > >In other words, if you add exclusion criteria to an existing >rdiff-backup run, are the copies of the newly-excluded files removed >from the main repository and placed in the increments folder [in which >case they *would* be removed by a subsequent --remove-older-than >command], or are they just left where they were [in which case they >*wouldn't* be]? > >I don't know the answer, but if someone does I would be interested. > >Dominic > >On 07/01/11 21:31, Chris G wrote: >> On Fri, Jan 07, 2011 at 02:38:45PM -0500, cov...@ccs.covici.com >wrote: >>> When the files are deleted, they are copied to the increments folder >and >>> kept till they are removed by --remove-older-than. >>> >> That makes sense, thank you. >> >>> Chris G wrote: >>> >>>> If you delete files/directories from the 'source' of an >rdiff-backup >>>> will they get removed from the destination with an appropriate >>>> "--remove-older-than" run? >>>> >>>> For example if rdiff-backup has been backing up a hierarchy with a >>>> directory called 'tmp' for a while and then the 'tmp' directory is >>>> removed can one get rdiff-backup to remove the 'tmp' backups 7 days >>>> later by "--remove-older-than 7D". >>>> >>>> From the man page it sounds as if deleted files *will* be >removed:- >>>> >>>>Note that snapshots of deleted files are covered by >this opera- >>>>tion. Thus if you deleted a file two weeks ago, >backed up imme- >>>>diately afterwards, and then ran rdiff-backup >with --remove- >>>>older-than 10D today, no trace of that file >would remain. >>>>Finally, file selection options such as --include >and --exclude >>>>don't affect --remove-older-than. >>>> >>>> But this bit from the examples section of the documentation worries >me >>>> slightly:- >>>> >>>> Note that an existing file which hasn't changed for a year >will still be >>>> preserved. But a file which was deleted 15 days ago cannot be >restored >>>> after this command is run. >>>> >>>> -- >>>> Chris Green >>>> >>>> ___ >>>> 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 >>> -- >>> Your life is like a penny. You're going to lose it. The question >is: >>> How do >>> you spend it? >>> >>> John Covici >>> cov...@ccs.covici.com >>> >>> ___ >>> 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 > >___ >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 -- D. Kriesel / dkriesel.com ___ 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
AW: [rdiff-backup-users] [PATCH] Sparse file support
Hi Dominic, this is certainly a cool idea, only I have no Python developer experience und therefore you for sure don't want me as a project member :-). Currently, I just try to help out people on the mailinglist from my experience as a computer scientist and rdiff-backup user. Anyway, there is hope. I am currently preparing my PhD project, and plan to use python for some scripting. Once I feel my understanding of python and the internals of rdiff-backup is good enough, I will file a request as you said. David > AFAIK Andrew's last posting on this newsgroup was March 2009, and his > last entry in CVS was January 2010, which is indeed the last entry by > anyone. Josh (who also created the excellent rdiffWeb GUI front-end) was > last seen here April 2010. You could try requesting to become a project > member > http://savannah.nongnu.org/my/groups.php?words=rdiff- > backup#searchgroup? > > Dominic > ___ 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
AW: [rdiff-backup-users] Re: Re: What happens if you add a --exclude to an existing rdiff-backup?
> Oops, I meant to change that, I haven't added an exclude to the > rdiff-backup command. What I have is an rsync across to the backup > machine and then the rdiff-backup runs there. I though I had a --exclude > in the rdiff-backup run but it's actually in the rsync. I only noticed > this when I started composing the E-Mail and, as I said, forgot to > change the subject. If you use rsync with exclusions AFTER rdiff-backup, what you get are inconsistencies in the final rdiff repository and therefore pain in the ass when verifying it. If you first rsync and then rdiff-backup, you should be fine whatsoever. Long story short: Let only rdiff-backup perform operations whithin the rdiff-backup repository. If you rsync the repository to some place excluding parts of it, it will be like you deleted files out of it. ___ 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
AW: [rdiff-backup-users] Re: What happens if you add a --exclude to an existing rdiff-backup?
> It would be good if there was a way of removing a subset of data from > the entire repository. So let's say I put a 500GB folder in /home by > accident and it has gone into the repository and is bloating it. I can > exclude it from my future rdiff-backup runs but the folder will still be > held as snapshot[s]. If I run --remove-older-than it will remove all > data older than whenever, but I want to keep all the other stuff and > just remove this folder (and its contents). RIGHT! This is the ONE feature I miss about rdiff-backup and which is my largest concern about it. I'll try to put it in a formalized way: "I want to be able to remove an entire subtree of an rdiff-backup repository _and every single trace of it in the metadata_". This is not possible right now, as far as I know. If this was possible, it would just be great. In my opinion, one would just have to remove * any diffs, snapshots, increment, dir and missing markers and similar files of the subtree (easy because you just would have to delete a subtree within the metadata plus some few additional files) * any trace of any file within the subtree to delete in the zipped backup table of content files. Please correct me if I'm wrong. If anyone wants to implement this feature, It will gladly be my shout for a sixpack :-) David ___ 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
AW: [rdiff-backup-users] Version error when trying to backup
Hi, this is a long shot but maybe you just might try version 1.3.3 on both sides, which is essentially 1.2.8 minus some little bugs. Cheers, David -Ursprüngliche Nachricht- Von: rdiff-backup-users-bounces+mail=dkriesel@nongnu.org [mailto:rdiff-backup-users-bounces+mail=dkriesel@nongnu.org] Im Auftrag von Thomas Pönitz Gesendet: Freitag, 21. Januar 2011 10:45 An: rdiff-backup-users@nongnu.org Betreff: [rdiff-backup-users] Version error when trying to backup Hallo! Is there a quick solution to the following problem? Host 1: Ubuntu 10.04 64bit (x86_64): # rdiff-backup -V rdiff-backup 1.2.8 Host 2: Qnap 32bit (ARM): # rdiff-backup -V rdiff-backup 1.2.8 Error message is: "rdiff-backup does not have the same version at the source and at the destination." Thanks ___ 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 ___ 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
Re: [rdiff-backup-users] IOError: [Errno 75] Value too large for defined data type
y", line
>62,
>> in copyfileobj
>> inbuf = inputfp.read(blocksize)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/rpath.py", line
>1415, in read
>> def read(self, length = -1): return self.file.read(length)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/hash.py", line 47,
>in read
>> buf = self.fileobj.read(length)
>>
>> Traceback (most recent call last):
>>File "/usr/bin/rdiff-backup", line 30, in
>> rdiff_backup.Main.error_check_Main(sys.argv[1:])
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line
>304,
>> in error_check_Main
>> try: Main(arglist)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line
>324, in Main
>> take_action(rps)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line
>280,
>> in take_action
>> elif action == "backup": Backup(rps[0], rps[1])
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/Main.py", line
>346, in Backup
>> backup.Mirror(rpin, rpout)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/backup.py", line
>38, in Mirror
>> DestS.patch(dest_rpath, source_diffiter)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/backup.py", line
>232, in patch
>> ITR(diff.index, diff)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/rorpiter.py", line
>> 281, in __call__
>> last_branch.fast_process(*args)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/backup.py", line
>> 529, in fast_process
>> if self.patch_to_temp(mirror_rp, diff_rorp, tf):
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/backup.py", line
>> 553, in patch_to_temp
>> result = self.patch_snapshot_to_temp(diff_rorp, new)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/backup.py", line
>> 582, in patch_snapshot_to_temp
>> (diff_rorp, new))
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/robust.py", line
>32,
>> in check_common_error
>> try: return function(*args)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/rpath.py", line
>105, in copy
>> if rpin.isreg(): return copy_reg_file(rpin, rpout, compress)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/rpath.py", line
>133,
>> in copy_reg_file
>> return rpout.write_from_fileobj(rpin.open("rb"), compress =
>compress)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/rpath.py", line
>> 1195, in write_from_fileobj
>> copyfileobj(fp, outfp)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/rpath.py", line
>62,
>> in copyfileobj
>> inbuf = inputfp.read(blocksize)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/rpath.py", line
>1415, in read
>> def read(self, length = -1): return self.file.read(length)
>>File "/usr/lib/pymodules/python2.6/rdiff_backup/hash.py", line 47,
>in read
>> buf = self.fileobj.read(length)
>> IOError: [Errno 75] Value too large for defined data type
>> Search through the rdiff-backup-users Archives but couldn't find
>> any cue to solve the problem.
>>
>> Search the net for similar information and it seems to be related
>with
>> python version before 2.2 and presently I'm using 2.6.5.
>> Follow some version information.
>>
>> <<<
>> $ python --version
>> Python 2.6.5
>> $ rsync --version
>> rsync version 3.0.7 protocol version 30
>> $ dpkg -l | grep rsync
>> ii librsync10.9.7-7
>>rsync remote-delta algorithm library
>> ii rsync3.0.7-1ubuntu1.1
>>fast remote file copy program (like
>rcp)
>> Thank you for your time.
>>
>
>___
>rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
>https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
>Wiki URL:
>http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
--
D. Kriesel / dkriesel.com
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Activity
A note I forgot in my first mail: I recently switched back to a python-controlled rsync backup because of the issues mentioned in my first mail ... ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Activity
> Yes I think rdiff-backup is currently unmaintained. > Anyone who wants to take it forward (and has the skills to do so > which unfortunately I have not) might need to make a fork > (which in due course could become rdiff-backup2?) > [...] > There was a discussion a while ago here and there was a > strong view that the existing project should be fixed rather than > a new one started, I suppose because rdiff-backup as it stands > is 99.5% perfect and any project, even if it fixed the 0.5%, > is likely to introduce new bugs and failings. I second that. I believe that it might be the optimal solution to fork a project like rdiffbackup2, but not only to "fix" the existing rdiff-backup, but also to reform some architectural things (like the repository format, and a few other things named). >I don't see how creating larger-granularity reverse-deltas > would really make it more robust, >it would just make the archives bigger. Let us define the grade of robustness as the percentage of the backup timeline a file is regressable to. Assume, one has got monthly reverse deltas in addition to daily ones. Without the monthly deltas, one broken daily delta makes a regression file for the complete backup timeline part that is located earlier than the delta was created. With additional monthly timelines, the corruption of some daily deltas just causes "gaps" in the regressable timeline. Just to point out the principle, optimization needed ;). The archive would still be a lot smaller than a multi generation full backup. However, maybe you are right and multigranularity reverse deltas are not the way to do - still I see the problem of the "touchiness" of the backup repository, with its lots and lots of single files that all need to be correct without any file changed. > >* Missing operators on an existing repository. For use of > > rdiff-backup in larger scale it should be possible to e.g. > > - merge time steps > > - delete timesteps and correct deltas accordingly > > - remove subtrees (sometimes one backups large data sets by accident) > > - lots more. > > yes these would be helpful especially to correct backup mistakes which can permanently bloat a repository And in cases where you want to thin out the time accuracy of earlier backups (e.g. reducing the cover profile from ten year old data from daily to monthly), and in lots and lots of other cases ... :-) > Yes, the best advice re a windows target seems to be: don't. I think you can reliably use rdiff-backup.exe to backup windows data to a linux target, though. Yep, both of your statements are true, in my opinion. However, the hash mismatches are not only reported by windows users. I believe that the main problem with windows targets is indeed the write only attribute on folders that is used by windows in another way as developers are used to from unix based systems. Especially, the write only attribute on folders is *not* used in windows to prevent accidental altering of a folder (like you are used to in files). It is used to mark a folder as "special" for the windows explorer, like the font folder or similar, see "cause" in the link http://support.microsoft.com/kb/326549/en-us. The write only attribute on folders is therefore managed by the system itself (personally, I think this way of marking special folders is complete bullshit). > and I would add: > ability to run a thorough verification of an rdiff-backup archive. > add a switch to enable 'forced' regression of an archive. Agreed ;) > AFAIK the only other open source project like rdiff-backup is duplicity. I would wish for rdiff-backup2 to stick with the reverse delta concept for the reasons you mentioned. ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Activity
Thanks for the crash plan hit - I'm definetly going to give this one a try :) Wojciech Stryjewski schrieb: >> I also would like to use it in larger scale, as it is - to the best >of my >> knowledge - the only free and flexible 4D-Backup-solution. However, I > >If you don't mind using a free but non open source program, then there >is www.crashplan.com. Although their business model is providing >online space for backup storage, I believe you can still use their >backup application for free to do backups between your own machines. >And their software works on Windows, Linux, Mac, and Sun. > -- D. Kriesel / dkriesel.com ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Activity
Crash plan looks nice just viewed by its features, not sure if the technical quality and stability reaches for example rsync, any experience? -- D. Kriesel / dkriesel.com___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Lost Connection
Second that. I believe that a local rdiff, followed by an rsync to a remote destination might be the most resilient solution. Nicolas Jungers schrieb: >On 2011-09-23 21:50, Alex wrote: >> I will check, but just used rsync and it worked, I believe that is >not >> network. Thank you so far > >rsync is very resistant to network flakiness and rdiff-backup is very >sensitive to it. > >N. > >> >> 2011/9/23 Greg Troxel <mailto:g...@work.lexort.com>> >> >> >> Try running tcpdump and seeing what happens, and check >> /var/log/messsages or equiv on both systems. >> >> Is the network between flaky or reliable? >> >> >> >> >> ___ >> rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users >> Wiki URL: >http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki > > >___ >rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org >https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users >Wiki URL: >http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki -- D. Kriesel / dkriesel.com ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] 1.2.8 vs 1.3.3
Greg, it seems this mailing list has not seen any message of the currently responsible project leader for a long time. I agree in thinking that 1.3.3 is the best and most stable version so far, It has still bugs though. Cheers David. > -Ursprüngliche Nachricht- > Von: rdiff-backup-users-bounces+mail=dkriesel@nongnu.org [mailto:rdiff- > backup-users-bounces+mail=dkriesel@nongnu.org] Im Auftrag von Greg > Troxel > Gesendet: Montag, 31. Oktober 2011 19:07 > An: rdiff-backup-users@nongnu.org > Betreff: [rdiff-backup-users] 1.2.8 vs 1.3.3 > > > On the web page, 1.2.8 is listed as stable and 1.3.3 as > development/unstable. But, it's been a long time. > > So: > > are there changes since 1.3.3? > if so, should there be a new release? > > is anyone who has project admin permission around? > > is 1.3.3 considered stable? As in, should I upgrade the entry in > pkgsrc to 1.3.3 from 1.2.8 so users just get 1.3.3 (which is really: > is it in the best interest of a user who doesn't know enough to choose > to be handed 1.2.8 or 1.3.3?) > > Thanks, > Greg ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Is Rdiff-backup still developed?
Thanks, Filip, I appreciate that! --David "Filip Gruszczyński" schrieb: >> I think lots of people are using rdiff-backup but no one is >maintaining it, >> sadly. Still it works for most of us very well. > >Thanks for the information. Cool it works, it sucks no one is keeping >it alive though. > >> Do you have any plans to release an update to rdiff-backup-fs 1.0.0? > >Yes. I have a lot on my head recently (changed job and country too), >but I have some changes in SCM waiting to be deployed. I will try to >get to that and release a new version with some fixes that people were >asking for. > >Best, > >> Regards >> >> Dominic >> >> On 14/11/2011 13:44, Filip Gruszczyński wrote: >>> >>> Is there anyone maintaining or developing rdiff-backup still or is >>> this project dead now? >>> >> >> > > > >-- >Filip Gruszczyński > >___ >rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org >https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users >Wiki URL: >http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki -- D. Kriesel / dkriesel.com ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] resuming initial backup
Rdiff-backup takes any existing data as a base in a target dir that has to be initialized, so just remove the rdiff-metadata from the target, while keeping the data that has already been copied :-) Cheers David > -Ursprüngliche Nachricht- > Von: rdiff-backup-users-bounces+mail=dkriesel@nongnu.org [mailto:rdiff- > backup-users-bounces+mail=dkriesel@nongnu.org] Im Auftrag von tim > Gesendet: Sonntag, 20. Mai 2012 13:24 > An: rdiff-backup-users@nongnu.org > Betreff: [rdiff-backup-users] resuming initial backup > > hi, > > i'm using a synology ds411 nas as backup target. the processor on this > device is very slow, so i don't get a transfer rate of more than 5 mb/s > when accessing it via ssh (cpu-bound). this makes backups for my 500GB > data partition rather painful. > > i'd therefore like to interrupt and later resume the initial backup. > however rdiff-backup tells me: > Found interrupted initial backup. Removing... > > ... and then starts copying the files ... is there any way to resume an > initial backup? > > thanks, tim > > > ___ > rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users > Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] resuming initial backup
PS.: You might have to --force the backup, not sure, but I know it works ... > -Ursprüngliche Nachricht- > Von: rdiff-backup-users-bounces+mail=dkriesel@nongnu.org [mailto:rdiff- > backup-users-bounces+mail=dkriesel@nongnu.org] Im Auftrag von D. > Kriesel > Gesendet: Sonntag, 20. Mai 2012 13:34 > An: 'tim'; rdiff-backup-users@nongnu.org > Betreff: Re: [rdiff-backup-users] resuming initial backup > > Rdiff-backup takes any existing data as a base in a target dir that has to > be initialized, so just remove the rdiff-metadata from the target, while > keeping the data that has already been copied :-) > > Cheers > David ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] resuming initial backup
The whole history will be lost when following this procedure, which renders it inappropriate for backup repositories whose history actually exists. However, if I get Tim right, he is talking about an interrupted _initial_ backup run. In this case, giving up the entire history obviously does not do any harm. Without any metadata (i.e. the rdiff-backup-data subfolder), afaik a forced rdiff-backup run will take whatever there is in the target folder as a base and won't retransfer existing parts. So my solution might be the right thing to do in this special case. Tim, just to let you know in addition: A more general solution that is resistant against transmission issues might actually be to 1) rdiff-backup to a local repository, followed by an 2) rsync to the remote box that causes the slow bandwidth. HTH David > -Ursprüngliche Nachricht- > Von: rdiff-backup-users-bounces+mail=dkriesel@nongnu.org [mailto:rdiff- > backup-users-bounces+mail=dkriesel@nongnu.org] Im Auftrag von > Dominic Raferd > Gesendet: Sonntag, 20. Mai 2012 13:54 > An: rdiff-backup-users@nongnu.org > Betreff: Re: [rdiff-backup-users] resuming initial backup > > What exactly needs to be deleted (i.e. the rdiff metadata)? What happens > to the data history (held in the rdiff-backup directory), is it still > all recoverable after you have followed this procedure? > > Dominic > > On 20/05/2012 12:34, D. Kriesel wrote: > > PS.: You might have to --force the backup, not sure, but I know it works ... > > > >> -Ursprüngliche Nachricht- > >> Von: rdiff-backup-users-bounces+mail=dkriesel@nongnu.org > > [mailto:rdiff- > >> backup-users-bounces+mail=dkriesel@nongnu.org] Im Auftrag von D. > >> Kriesel > >> Gesendet: Sonntag, 20. Mai 2012 13:34 > >> An: 'tim'; rdiff-backup-users@nongnu.org > >> Betreff: Re: [rdiff-backup-users] resuming initial backup > >> > >> Rdiff-backup takes any existing data as a base in a target dir that has to > >> be initialized, so just remove the rdiff-metadata from the target, while > >> keeping the data that has already been copied :-) > >> > >> Cheers > >> David > > > > > > ___ > > rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users > > Wiki URL: http://rdiff- > backup.solutionsfirst.com.au/index.php/RdiffBackupWiki > > ___ > rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org > https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users > Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] resuming initial backup
> thanks for your explanations ... i was a bit confused to see a lot of > "Processing changed file" messages of files which have already been > transferred ... could be that checksumming these files is a performance > bottleneck on the NAS device ... so doing the rdiff-backup locally and > uploading via rsync might be an option ... Yeah, might be that this is the bottleneck. In this case I indeed suggest to split the backup in two parts: Rdiff-backup locally (quick, robust, no need for transmissions) and let rsync do the transmission to the target. The latter might be a lot quicker than a transmission using rdiff-backup, for rsync usually supposes two files to be identical if filesize and timestamp match. ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] rdiff-backup file consistency
Thanks for mentioning obnam, which I have not known so far. Seems to have some very nice features even though I would be interested in how it internally works (what kind of deltas are used, how efficient is the transmission (comparable to rsync?)). Maybe I will give it a shot :-) Nicolas Jungers schrieb: >Hi Sorvath, > >I use rdiff-backup with TB sized data stores, some churning 10's of GB >a >day (I haven't so far experienced any problem), but if I had to shop >for >a new backup system I'd investigate obnam. Which I'll probably do >anyway. > >Regards, >Nicolas > >On 06/08/2012 10:02 PM, shorvath wrote: >> Hi and thanks for the replies. >> >> Florian, you mention you use rdiff-backup (for max 20G) and rsync for >larger. >> Is it not recommended to use rdiff-backup on large backups? Mine are >several Tb's with possible gb's daily increments. >> Would it be recommend to stick to rsync? >> How about backuppc? >> What are your thoughts/comments/suggestions regarding that? >> >> I backup several servers to a local backup server (daily,weekly, >monthly) and then sync that offsite. >> Currently each local backup is checksummed, xfered offsite and >checksummed again. >> We have a set of scripts that rsyncs, rotates, reports and checksums >but unfortunately they are very inefficient and are just not up to the >job. >> I have the choice of rewriting them from scratch or use something >that's already been written (rsnapshot, rdiff-backup, backuppc) >> All are much more efficient than anything I could come up with so why >reinvent the wheel? >> I just need to decide on one that does, at the very least, what we're >currently doing (albeit not very well) >> >> As for ram errors...All our servers have ecc ram. >> For bit errors... I'm VERY tempted to take the plunge into the zfs on >linux project but despite the many good reports on stability, as this >is a production service, I'm nervous. >> >> >+-- >> |This was sent by mem...@thehorvaths.co.uk via Backup Central. >> |Forward SPAM to ab...@backupcentral.com. >> >+-- >> >> >> >> ___ >> rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users >> Wiki URL: >http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki > > >___ >rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org >https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users >Wiki URL: >http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki -- D. Kriesel / dkriesel.com ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] rdiff-backup file consistency
If I get it right, there is no such thing as deltas. Every generation seems to virtually stand for its own. However, double chunks of data (no matter if being caused by different machines or generations or whatever) are deduplicated in a generalized way. Nice design! As check for duplicate data made before transmission, this could be also very efficient (however, one could still transmit with rsync and than use obnam). I'll stop spamming this list now with obnam features, however the delta question is the one that arises for sure when other backup systems are mentioned here ;) Cheers David -- D. Kriesel / dkriesel.com ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] rdiff-backup file consistency
After reading the obnam documentation I think a combination of 1) several rsync-linkdest backupslots (for easy accessability) and 2) an additional obnam repository (for more generation flexibility while at the same time preventing nearly all drawbacks of rdiff-backup mentioned in this thread) might do the job for everyone of us. I'm gonna give it a shot and report back if I experience major caveats. Cheers David shorvath schrieb: >So I've been giving obnam a quick test drive and although it does look >very interesting it seems that the backups are not accessible in the >way an rsync backup is. >The advantage with rsync, at least in my case, is that in the even of a >total disaster, I am able to serve my backups as a usable replacement. >Rdiff-backup is similar in the sense that at least the most recent >backup can be offered to clients in the same manner and with the >rdiff-backup fuse module increments can also be accessed, the same goes >for backuppc with the help of a fuse module. >I can't see anyway of doing this (that I can see, but I may be wrong) >with obnam. >If this is the case then obnam is not a viable solution for me. >I hope I'm wrong as it does look promising. >What's important to me is >a) backups are verified >b) can be presented at anytime (Even if it's read only) in the event of >a disaster. > >Is anyone using zfs-on-linux here? (http://zfsonlinux.org/) >I know I can use solaris/openindiana/eon or freebsd but we are a linux >house and I need to keep things consistent. > >+-- >|This was sent by mem...@thehorvaths.co.uk via Backup Central. >|Forward SPAM to ab...@backupcentral.com. >+-- > > > >___ >rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org >https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users >Wiki URL: >http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki -- D. Kriesel / dkriesel.com ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Re: [rdiff-backup-users] Wiki, anybody?
If you need some wiki / vserver with respect to rdiff, don't hesitate to ask! -- D. Kriesel / dkriesel.com Am 13. Mai 2013 13:10:54 schrieb Dominic Raferd : On 12/05/2013 03:05, Edward Ned Harvey (rdiff-backup) wrote: Thanks for that. I sent them an email, and we'll see what happens. Great to have you onboard as maintainer Ned! The wiki pages would not have changed in a deliberate way since 24 June 2012 (or indeed in the preceding year or more), so the data from the wayback archive at that date should be 'latest and greatest'. Dominic -- TimeDicer: Free File Recovery from Whenever ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
