Re: [rdiff-backup-users] Broken rdiff-backup on Fedora 11
On Tue, 02 Feb 2010 20:23:57 -0800, John Jason Jordan joh...@comcast.net wrote: Sorry for the formatting. Hard to copy and paste from the command line. My script is: #!/bin/bash sudo rdiff-backup --include-globbing-filelist /home/jjj/rdiff_excludes.txt / /media/Backups/Full_system_backup_Fedora 2 /home/jjj/rdiff-errors.txt sudo rdiff-backup 2 --list-increment-sizes /media/Backups/Full_system_backup_Fedora 2 /home/jjj/rdiff-stats.txt [...] It is interesting that pybackpack runs fine. My understanding is that it is just a GUI front end for rdiff-backup, so why does it work and rdiff-backup does not work from the command line? Well, that bash script didn't survive the cut and paste either, so I'm sure exactly what it actually says. If pybackpack does use rdiff-backup under the covers and you can back up files with it, then your rdiff-backup installation would appear to be correct. (You should double check that you only have one copy of rdfiff-backup on the system, in case pybackpack is using a different one from the one you get when you run the command from the command line.) So one suspects the problem is with the bash script somehow, or with the repository you are manipulating if it is different from the one pybackpack is using. Have you tried running rdiff-backup directly from the command line doing something simple like just viewing the help output? And then try the commands from the bash script individually, and/or other rdiff-backup commands that just read from the repository. -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls ___ 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] Broken rdiff-backup on Fedora 11
On Wed, 03 Feb 2010 12:01:23 -0800, John Jason Jordan joh...@comcast.net wrote: which I can swap with the DVD drive. On this disk there is a folder Full_system_backup_Jaunty. I created a new folder Full_system_backup_Fedora and then modified the script so it would write to the new folder. Other than changing the destination folder I made no other changes to the script. However, I also modified my rdiff_excludes.txt file by adding - *.iso and - /home/jjj/Azureus Downloads/. I don't think changing the excludes will have made a difference, but you could try deleting them just to check. From the looks of the traceback you posted, I suspect there's something wrong with your destination folder. Although I don't really understand the code in detail, it appears to me as though rdiff-backup is finding an empty list of increments, something it apparently isn't prepared to handle. I'm assuming you are getting one traceback for each command in your bash file, if that isn't the case let me know :) I'd advise deleting your backup target directory and reinitializing it. -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls ___ 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] OverflowError: signed integer is greater than maximum
On Sat, 16 Jan 2010 18:11:56 +0100, Michel Le Cocq miconof80.l...@gmail.com wrote: File /usr/local/lib/python2.6/site-packages/rdiff_backup/rpath.py, line 973, in chown try: self.conn.C.lchown(self.path, uid, gid) OverflowError: signed integer is greater than maximum Michel Le Cocq a écrit: Andrew Ferguson-4 wrote: On Jan 5, 2009, at 4:00 PM, Brad Beyenhof wrote: Backing up from the 64-bit system works fine, and two of the directories I'm backing up from the 32-bit system are fine as well. However, one directory reports OverflowError: signed integer is greater than maximum and quits partway through the backup. The terminal output with the default verbosity is below; I can attach a log with a higher verbosity if requested. Hi Brad, This is a known problem that is due to a bug in Python. The Python bug has been fixed in their SVN, and was slated to be a part of 2.5.3, so it should be included in the latest Python releases: 2.5.4, 2.6.1, and 3.0. Try upgrading your Python to 2.5.4 or 2.6.1. Here is some more information about the problem: https://bugs.launchpad.net/ubuntu/+source/rdiff-backup/+bug/245844 http://bugs.python.org/issue1747858 But then there's http://bugs.python.org/issue6873, which indicates that perhaps lchown still has the problem in the released Python versions. If you can figure out how to reproduce it outside of rdiff-backup the Python team would be grateful :) -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls ___ 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] Using rdiff-backup for syncing files from a test server to a production server
On Fri, 18 Dec 2009 11:12:56 -0500, Brandon Simmons brandon.m.simm...@gmail.com wrote: I would like to be able to make modifications to server config files on my test server, and then be able to send them to the production server using rdiff-backup. I only want to copy over a few files explicitly, for example when I create a new init script, I would add it to my list of includes. The trouble I am having is in trying to figure out how to initialize this setup. It seems that if I use '--force' for the initial rdiff-backup, that it clobbers all the files on the production server. I hope it's clear what I'm trying to do, and thanks for any clues. That sounds like a job for rsync, not rdiff-backup. -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls ___ 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] Using rdiff-backup for syncing files from a test server to a production server
On Fri, 18 Dec 2009 12:31:33 -0500, Brandon Simmons brandon.m.simm...@gmail.com wrote: I wanted to use rdiff-backup so that I could easily roll back changes on the production server if the modifications weren't working correctly. But now that I think about it, I can see how if the production server is the backup copy with the incremental snapshots, that won't allow me to do that anyway. Any other ideas on a system that will allow me to roll back changes? 1) Put your source config files under a version control system. 2) Use rdiff-backup to create a backup somewhere (but not in the production directories) so you can restore from there at need. 3) Use one of the configuration management systems[1] to push your configs out to the production servers and provide for rollbacks. [1] http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls ___ 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] delete initial mirror
On Fri, 23 Oct 2009 at 06:40, Alex Samad wrote: On Thu, Oct 22, 2009 at 08:41:57AM -0400, Daniel Miller wrote: On Oct 21, 2009, at 10:03 PM, plug bert wrote: Hmm...so in that case, if i want to incrementally back up a 100gb file daily for one week, and for simplicity's sake, assume the file grows 1gb per day, my backup media will need to be at least 100gb + 6gb? Yes... plus a bit of space for rdiff-backup housekeeping data. sorry, doesn't rdiff-backup work at the file level, not the block level. so a 100G file that has 1 byte changed, mean that 200G of backup space is used ? so for 6 days of changes to the 100G file that would take up 600G of space No, it uses librsync and does deltas on arbitrary length octet streams. So it only transmits and stores the changed data, not a new copy of the entire file. --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
Re: [rdiff-backup-users] delete initial mirror
On Wed, 21 Oct 2009 at 20:54, Alex Samad wrote: On Wed, Oct 21, 2009 at 12:56:12AM -0700, plug bert wrote: Hello All, Is it possible to delete the initial mirror made by rdiff-backup after an incremental backup is made? We're looking into ways of performing incremental backups for mbox-style mailboxes; is this setup possible: Sunday: make an initial mirror Monday - Saturday: schedule incremental backup, *delete* initial mirror Sunday: make initial mirror(i.e. reformat the mirror drive, start from scratch) Monday - Saturday : incremental backup again Let's say someone deleted a file on Wednesday; *without* the initial mirror, is it possible to restore the file? i think you can use remove older than 7B - mean delete anything older than 7 runs or 7D for delate any info older than 7 days. Not sure if rdiff-backup has the concept of full / incremental - although it incrementally updates the backup. As I understand things, and assuming I understand your goals, Alex is correct here. If your goal is to always have a valid backup, but to not keep data around that is older than a week because of storage concerns, then what you want to do with rdiff-backup is make an initial backup, and then after every daily incremental backup, do an rdiff-backup --remove-older-than 7d on your backup tree. rdiff-backup keeps the backup tree in sync with the current tree, and maintains _older_ revisions by using reverse diffs (as someone else pointed out). So by using this scheme you will always have a current complete backup, and you will also always have the last seven days of changes. So if someone deletes a file on Wednesday, it will remain available for restore until the following Wednesday. --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
