[rdiff-backup-users] Re: Re: Re: What happens if you add a --exclude to an existing rdiff-backup?
On Sat, Jan 08, 2011 at 12:09:07PM +0100, D. Kriesel wrote: > > 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. No, you've misunderstood (I think). I run a daily rsync from machineA/dirx to machineB/dirx. Then I run rdiff-backup on machineB from dirx to dirxbackup. So from rdiff-backup's point of view (if rsync is set up so that dirx on machineB is a genuine *mirror* of dirx on machineA) it just looks as if the files in question have been deleted by the user (or whatever). I'm not using rsync to copy the rdiff-backup archive. -- 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
[rdiff-backup-users] Re: Re: What happens if you add a --exclude to an existing rdiff-backup?
On Sat, Jan 08, 2011 at 08:39:15AM +, Dominic Raferd wrote: > 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?' > 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 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. > Yes, it's the question I originally *thought* I needed to ask. -- 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
[rdiff-backup-users] Re: What happens if you add a --exclude to an existing rdiff-backup?
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 -- 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
[rdiff-backup-users] What happens if you add a --exclude to an existing rdiff-backup?
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
[rdiff-backup-users] Using the --remove-older-than option, clarification required
I have some big chunks of backup I want to remove. For example I have backed up a load of virtual machines unnecessarily, these are in /home/chris/.VirtualBox. So what do I actually do? The backup command is:- /opt/bin/rdiff-backup /DataVolume/chris /ExtendVolume/chris (the files on /DataVolume are put there across the network by rsync) Is the way to remove my .VirtualBox directory this:- rdiff-backup --remove-older-than 1s --force /ExtendVolume/chris/.VirtualBox (I have already told rsync not to copy the .VirtualBox directory across and I have removed it from /DataVolume) No, can't do that, it just says:- r...@backup$ rdiff-backup --remove-older-than 1s --force /ExtendVolume/chris/.VirtualBox Fatal Error: Increments for directory /ExtendVolume/chris/.VirtualBox cannot be removed separately. Instead run on entire directory /ExtendVolume/chris. So the FAQ is a bit misleading, or at least doesn't simply say 'no' to the question. Is there any way out of this problem? If I simply remove .VirtualBox from /ExtendVolume will anything break, i.e. can I continue to run my rdiff-backup as at present without seeing loads of errors? -- 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
[rdiff-backup-users] Re: Re: Can anyone explain this error when running rdiff-backup from cron?
On Mon, Nov 22, 2010 at 03:27:10PM +0100, Andreas Olsson wrote: > mån 2010-11-22 klockan 14:10 + skrev Chris G: > > Of course! Thanks. I used to have passwordless login which used to use > > an ssh-key without a passphrase but a while ago I changed to using a > > passphrase (the same as my login so I don't have to enter the > > passphrase) so of course the cron job doesn't work any more. > > > > Are there any ways to work around this problem so that the cron job can > > work but I can still have a passphrase protected ssh-key? > > Not really. A second best solution might be to use a separate password > less key, with restrictions imposed on it in ~/.ssh/authorized_keys. > > On cheddar.halon.org.uk you could put something like this in your > authorized_keys file. > > command="/usr/bin/python /usr/bin/rdiff-backup --server --restrict > /home/chris/backups/isbd",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty > ssh-rsa B3NzaC1yc2E... > > That way there will be less of an issue if the ssh key is "stolen". > > Example on running rdiff-backup with an explicit ssh-key: > > rdiff-backup --remote-schema 'ssh -i /home/foo/.ssh/backup2cheddar %s > rdiff-backup --server' /home/isbd > ch...@cheddar.halon.org.uk::/home/chris/backups/isbd > Ah, yes, that's an acceptable approach, thanks for the idea. -- 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
Re: [rdiff-backup-users] Can anyone explain this error when running rdiff-backup from cron?
On Mon, Nov 22, 2010 at 03:17:15PM +0100, Jernej Simončič wrote: > On Monday, November 22, 2010, 15:10:26, Chris G wrote: > > > Are there any ways to work around this problem so that the cron job can > > work but I can still have a passphrase protected ssh-key? > > Not really - and even if there was a way, it would be no more secure > than having an unprotected SSH key in the first place. > Pity, OK, thanks. -- 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
[rdiff-backup-users] Re: Can anyone explain this error when running rdiff-backup from cron?
On Mon, Nov 22, 2010 at 02:58:14PM +0100, Andreas Olsson wrote: > mån 2010-11-22 klockan 13:41 + skrev Chris G: > > I have an rdiff-backup that runs as a cron job, "crontab -l" shows:- > > > > 25 02 * * * /usr/local/bin/rdiff-backup /home/isbd > > ch...@cheddar.halon.org.uk::backups/isbd > > > > > > When run from the command line this works fine:- > > > > chris$ /usr/local/bin/rdiff-backup /home/isbd > > ch...@cheddar.halon.org.uk::backups/isbd > > > > /usr/local/lib/python2.6/dist-packages/rdiff_backup/SetConnections.py:148: > > DeprecationWarning: os.popen2 is deprecated. Use the subprocess module. > > stdin, stdout = os.popen2(remote_cmd) > > Warning: Local version 1.2.8 does not match remote version 1.2.5. > > > > > > But when run as a cron job (from my crontab) I get the following errors > > (mailed to me):- > > > > > > /usr/local/lib/python2.6/dist-packages/rdiff_backup/SetConnections.py:148: > > DeprecationWarning: os.popen2 is deprecated. Use the subprocess module. > > stdin, stdout = os.popen2(remote_cmd) > > Permission denied, please try again. > > Permission denied, please try again. > > Permission denied (publickey,password). > > Fatal Error: Truncated header string (problem probably originated > > remotely) > > ... > > When you are logged in interactively, how do you auth against > ch...@cheddar.halon.org.uk? A ssh-key perhaps? If so, is the ssh-key > protected by a passphrase? > Of course! Thanks. I used to have passwordless login which used to use an ssh-key without a passphrase but a while ago I changed to using a passphrase (the same as my login so I don't have to enter the passphrase) so of course the cron job doesn't work any more. Are there any ways to work around this problem so that the cron job can work but I can still have a passphrase protected ssh-key? -- 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
[rdiff-backup-users] Problem when compiling - can't find Python.h
I use rdiff-backup to do backups to two external systems where I have shell login accounts. Trying to compile version 1.3.3 on *both* of these systems fails because Python.h is missing:- ... ... ... copying rdiff_backup/user_group.py -> build/lib.linux-i686-2.5/rdiff_backup copying rdiff_backup/win_acls.py -> build/lib.linux-i686-2.5/rdiff_backup running build_ext building 'rdiff_backup.C' extension creating build/temp.linux-i686-2.5 gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.5 -c cmodule.c -o build/temp.linux-i686-2.5/cmodule.o cmodule.c:24:20: error: Python.h: No such file or directory cmodule.c:76: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token ... ... ... So, is this simply because the remote systems don't have some Python development headers installed or is there some more subtle problem? -- 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
[rdiff-backup-users] Can anyone explain this error when running rdiff-backup from cron?
I realise this isn't really an rdiff-backup problem but I'm rather stumped by this problem. I have an rdiff-backup that runs as a cron job, "crontab -l" shows:- 25 02 * * * /usr/local/bin/rdiff-backup /home/isbd ch...@cheddar.halon.org.uk::backups/isbd When run from the command line this works fine:- chris$ /usr/local/bin/rdiff-backup /home/isbd ch...@cheddar.halon.org.uk::backups/isbd /usr/local/lib/python2.6/dist-packages/rdiff_backup/SetConnections.py:148: DeprecationWarning: os.popen2 is deprecated. Use the subprocess module. stdin, stdout = os.popen2(remote_cmd) Warning: Local version 1.2.8 does not match remote version 1.2.5. But when run as a cron job (from my crontab) I get the following errors (mailed to me):- /usr/local/lib/python2.6/dist-packages/rdiff_backup/SetConnections.py:148: DeprecationWarning: os.popen2 is deprecated. Use the subprocess module. stdin, stdout = os.popen2(remote_cmd) Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,password). Fatal Error: Truncated header string (problem probably originated remotely) Couldn't start up the remote connection by executing ssh -C ch...@cheddar.halon.org.uk rdiff-backup --server Remember that, under the default settings, rdiff-backup must be installed in the PATH on the remote system. See the man page for more information on this. This message may also be displayed if the remote version of rdiff-backup is quite different from the local version (1.2.8). While I'm about it will moving to Version 1.3.3 get rid of all those warning messages? -- 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
[rdiff-backup-users] Re: Unable to backup due to remote system closing connection
On Sun, Jan 24, 2010 at 11:17:28AM +, Alex Pounds wrote: > On Sun, Jan 24, 2010 at 08:11:46AM +, Dominic Raferd wrote: > > There is a long thread about this issue at > > http://www.howtoforge.com/forums/showthread.php?t=3618. But the > > problem in the end seemed to be (in this case) that the user had > > generated the authorized_keys file with nano and had not switched > > off hard wrapping, so that when the file was saved nano broke up the > > line. > > Thanks for the pointer, but that doesn't seem to be the problem in this > case: > > gertie ~$ sudo wc -l /mnt/backup/.ssh/authorized_keys > 1 /mnt/backup/.ssh/authorized_keys > > Catting the authorized_keys file with the -A option shows only one > end-of-line character, too. > My approach would be to take all the ssh restrictions off on gertie and get ssh passwordless login working for an ordinary login. Get rdiff-backup working with this setup and *then* start adding the ssh restrictions to make it more secure. -- 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
[rdiff-backup-users] Re: Ways to speed rdiff-backup a bit
On Fri, Jan 15, 2010 at 05:27:59PM +1000, Gavin wrote: > Chris G wrote: > > I'm running rdiff-backup on a Western Digital My Book World Edition > > II, it's a little NAS server that runs linux and has ssh login > > available. > > > > The rdiff-backup is running from one of the NAS server's drives to the > > other drive, i.e. it's not being run from another system to (or from) > > the NAS and thus is not limited by network bandwidth. > > > > I'm backing up two large[ish] directories, one is around 164Gb, the > > other is about 35Gb. > > > > The 35Gb one takes about 7 minutes to run, which is fine, but the > > 165Gb one takes 4 hours and 5 minutes. Presumably there's some sort > > of resource limitation which the bigger backup is hitting and hence > > running slower. > > > > Is there anything I can do to improve performance? My first guess > > would be that rdiff-backup is running out of 'real' memory and > > swapping which is slowing things. > > > > It has 126828 kB of memory, more than I thought, that's 128Mb. > > > > The processor is an ARM926EJ-S, 183 BogoMIPS. > > > How about splitting the larger backup into 3 or 4 parts? > > Yes, that's a possibility, though it is rather one large bit and several small bits. However it might be that decreasing the size by a fairly small amount would help so it's worth trying. Thanks. -- 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
[rdiff-backup-users] Re: Ways to speed rdiff-backup a bit
On Thu, Jan 14, 2010 at 06:18:33PM +, Chris G wrote: > I'm running rdiff-backup on a Western Digital My Book World Edition > II, it's a little NAS server that runs linux and has ssh login > available. > > The rdiff-backup is running from one of the NAS server's drives to the > other drive, i.e. it's not being run from another system to (or from) > the NAS and thus is not limited by network bandwidth. > > I'm backing up two large[ish] directories, one is around 164Gb, the > other is about 35Gb. > > The 35Gb one takes about 7 minutes to run, which is fine, but the > 165Gb one takes 4 hours and 5 minutes. Presumably there's some sort > of resource limitation which the bigger backup is hitting and hence > running slower. > > Is there anything I can do to improve performance? My first guess > would be that rdiff-backup is running out of 'real' memory and > swapping which is slowing things. > > It has 126828 kB of memory, more than I thought, that's 128Mb. > > The processor is an ARM926EJ-S, 183 BogoMIPS. > ... and here are the rdiff-backup session_statistics files:- StartTime 1263436518.00 (Thu Jan 14 02:35:18 2010) EndTime 1263451841.07 (Thu Jan 14 06:50:41 2010) ElapsedTime 15323.07 (4 hours 15 minutes 23.07 seconds) SourceFiles 253324 SourceFileSize 167143773023 (156 GB) MirrorFiles 253050 MirrorFileSize 167116487371 (156 GB) NewFiles 274 NewFileSize 23594577 (22.5 MB) DeletedFiles 0 DeletedFileSize 0 (0 bytes) ChangedFiles 431 ChangedSourceSize 18543551628 (17.3 GB) ChangedMirrorSize 18539860553 (17.3 GB) IncrementFiles 706 IncrementFileSize 90764595 (86.6 MB) TotalDestinationSizeChange 118050247 (113 MB) Errors 0 StartTime 1263451844.00 (Thu Jan 14 06:50:44 2010) EndTime 1263452264.06 (Thu Jan 14 06:57:44 2010) ElapsedTime 420.06 (7 minutes) SourceFiles 25405 SourceFileSize 35810108114 (33.4 GB) MirrorFiles 25405 MirrorFileSize 35810108114 (33.4 GB) NewFiles 0 NewFileSize 0 (0 bytes) DeletedFiles 0 DeletedFileSize 0 (0 bytes) ChangedFiles 0 ChangedSourceSize 0 (0 bytes) ChangedMirrorSize 0 (0 bytes) IncrementFiles 0 IncrementFileSize 0 (0 bytes) TotalDestinationSizeChange 0 (0 bytes) Errors 0 Hmmm, there's something funny going on here! There should be some changed files in that second (33Gb) backup, I'll go and investigate. -- 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
[rdiff-backup-users] Ways to speed rdiff-backup a bit
I'm running rdiff-backup on a Western Digital My Book World Edition II, it's a little NAS server that runs linux and has ssh login available. The rdiff-backup is running from one of the NAS server's drives to the other drive, i.e. it's not being run from another system to (or from) the NAS and thus is not limited by network bandwidth. I'm backing up two large[ish] directories, one is around 164Gb, the other is about 35Gb. The 35Gb one takes about 7 minutes to run, which is fine, but the 165Gb one takes 4 hours and 5 minutes. Presumably there's some sort of resource limitation which the bigger backup is hitting and hence running slower. Is there anything I can do to improve performance? My first guess would be that rdiff-backup is running out of 'real' memory and swapping which is slowing things. It has 126828 kB of memory, more than I thought, that's 128Mb. The processor is an ARM926EJ-S, 183 BogoMIPS. -- 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
[rdiff-backup-users] Re: Find out Failed Backup
On Sun, Jan 10, 2010 at 09:50:39AM +1000, Gavin wrote: > Hi all > > I back up a directory to a remote system by rdiff-backup and I'm doing > it as periodic cron jobs. How can I find out that a back-up session > failed? I saw an entry at the FAQ that told about two > current_mirror_ files with different dates. Is it enough to check > this situation? > Any output (i.e. an error or warning) from rdiff-backup will be E-Mailed by cron to the owner of the cron job. So, if rdiff-backup runs totally successfully you will get no output, if it fails you will get an error message. If the owner of the cron job isn't a user who reads mail then you can set the environment variable MAILTO in the crontab to send the mail where you want, i.e. add a line like the following to your crontab:- mailto=ga...@wherever.gavin,reads.mail If you want to get confirmation that the crontab has been run then you can put simple 'echo' lines in the script that runs rdiff-backup. They will then appear as mail sent to the above MAILTO user. (All the above applies to cron on modern Linux, if your rdiff-backup is running on something else then read the man pages for cron and crontab to confirm it's the same) -- 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
[rdiff-backup-users] A response to an old thread about --restrict-update-only
A while ago, in a long thread, the following was said:- > > Regarding first creating new repositories, yes, I think that too will be > blocked. There was some discussion a few years ago about this: > http://savannah.nongnu.org/bugs/?16897 ... I don't remember what was > resolved. I suppose we could add os.mkdir() to the safe list. > It's not a big issue for me, if/when I set up new clients and/or new hierarchies to back up I'm quite happy to do some manual backups or remove the --restrict-update-only from teh destination temporarily. Well, I can now confirm this is true, you can't create a new backup with a --restrict-update-only in place. However, once you have created the backup then --restrict-update-only can be added and seems to do what's expected. I have thus got the following in the ~/.ssh/authorized_keys file on the backup 'server':- command="rdiff-backup --server --restrict-update-only backups",no-pty,no-port-forwarding ssh-rsa I have a dedicated client account for running the backup which has a passphraseless ssh key and is restricted to only doing backups by the above. It's obviously not totally secure but it's good enough while at the same time doing backups daily with no effort on my part. (It's only one of several backups I do, each with different strengths and weaknesses) -- 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
[rdiff-backup-users] Re: Can one set up a login for rdiff-backup only (not via sshd_config)?
On Mon, Jan 04, 2010 at 01:34:39PM +, Chris G wrote: > Is it possible to set up a dedicated login for rdiff-backup to use > without using sshd_config? > > I have a NAS backup system which runs linux but has an ancient version > of ssh on it which I don't want to play about with. So I'd prefer to > create a dedicated login (a user called 'bak') which *only* allows > rdiff-backup to run. > > Is there any way I can do this? I guess rdiff-backup needs a shell to > run in so I can't just set the shell field in /etc/passwd to > "rdiff-backup --server". Would I get away with a .profile for the > user that runs "rdiff-backup --server" or something like that with a > --remote-schema set to nothing? > I worked out how to do it after quite a bit of mucking about and experimentation, it needs a little shell script to run rdiff-backup as (at least on the system I was using) you can't add parameters to the 'shell' entry in /etc/passwd. Thus I ended up with an entry in /etc/passwd as follows:- bak:x:505:1000:Backup Login,,,:/bak:/opt/bin/rdb ...and /opt/bin/rdb is simply:- #!/bin/sh /opt/bin/rdiff-backup --server -- 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
[rdiff-backup-users] Can one set up a login for rdiff-backup only (not via sshd_config)?
Is it possible to set up a dedicated login for rdiff-backup to use without using sshd_config? I have a NAS backup system which runs linux but has an ancient version of ssh on it which I don't want to play about with. So I'd prefer to create a dedicated login (a user called 'bak') which *only* allows rdiff-backup to run. Is there any way I can do this? I guess rdiff-backup needs a shell to run in so I can't just set the shell field in /etc/passwd to "rdiff-backup --server". Would I get away with a .profile for the user that runs "rdiff-backup --server" or something like that with a --remote-schema set to nothing? -- 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
[rdiff-backup-users] Re: Backup to smbfs
On Sun, Jan 03, 2010 at 08:15:47PM +0100, Andrea Talucci wrote: > I all, > I have some problem using rdiff-backup to write to a NAS drive locally > mounted as smbfs. I've browsed this list for 2 days finding some suggest > but no one resolving... > It seems that the error is caused by some chmod command, that (I > guess...) cannot be executed on a smbfs. > I had no end of trouble trying to backup to SMB/CIFS NAS systems. After much wasted time etc. I searched around for a NAS that supports NFS and bought one, in my case a WD My Book World Edition II, problem solve. I gave the SMB/CIFS NAS away. > Can I have some help ? > > Cheers, > Andy > > Here is the output: > > $ rdiff-backup -v5 ./Immagini/foto/ /media/dlink/test_foto/ > > > Using rdiff-backup version 1.2.8 > Cannot change permissions on target directory. > Unable to import module xattr. > Extended attributes not supported on filesystem at Immagini/foto > Unable to import module posix1e from pylibacl package. > POSIX ACLs not supported on filesystem at Immagini/foto > Unable to import win32security module. Windows ACLs > not supported by filesystem at Immagini/foto > escape_dos_devices not required by filesystem at Immagini/foto > - > Detected abilities for source (read only) file system: > Access control lists Off > Extended attributes Off > Windows access control lists Off > Case sensitivity On > Escape DOS devices Off > Escape trailing spaces Off > Mac OS X style resource forksOff > Mac OS X Finder information Off > - > Warning: hard linking not supported by filesystem at > /media/dlink/test_foto/rdiff-backup-data > Directories on file system at > /media/dlink/test_foto/rdiff-backup-data/rdiff-backup.tmp.0 are not > fsyncable. > Assuming it's unnecessary. > Unable to import module xattr. > Extended attributes not supported on filesystem at > /media/dlink/test_foto/rdiff-backup-data/rdiff-backup.tmp.0 > Unable to import module posix1e from pylibacl package. > POSIX ACLs not supported on filesystem at > /media/dlink/test_foto/rdiff-backup-data/rdiff-backup.tmp.0 > Unable to import win32security module. Windows ACLs > not supported by filesystem at > /media/dlink/test_foto/rdiff-backup-data/rdiff-backup.tmp.0 > escape_dos_devices not required by filesystem at > /media/dlink/test_foto/rdiff-backup-data/rdiff-backup.tmp.0 > - > Detected abilities for destination (read/write) file system: > Ownership changing Off > Hard linking N/A > fsync() directories Off > Directory inc permissionsOff > High-bit permissions Off > Symlink permissions Off > Extended filenames On > Windows reserved filenames On > Access control lists Off > Extended attributes Off > Windows access control lists Off > Case sensitivity On > Escape DOS devices Off > Escape trailing spaces Off > Mac OS X style resource forksOff > Mac OS X Finder information Off > - > Backup: must_escape_dos_devices = 0 > Starting mirror Immagini/foto to /media/dlink/test_foto > Processing changed file . > Processing changed file 2000 e prec > Processing changed file 2000 e prec/cena + music (grecia).jpg > Exception '[Errno 13] Permission denied: '/media/dlink/test_foto/2000 e > prec/rdiff-backup.tmp.1'' raised of class '': > 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 se
[rdiff-backup-users] Re: Allowing only rdiff-backup across a connection, how to set up?
On Wed, Dec 23, 2009 at 11:08:50PM +0100, Giorgio wrote: >Hi, > >2009/12/23 Chris G <[1...@isbd.net> > > If I want to allow *only* rdiff backup to use an ssh link between two > machines what's the best way of setting it up? > >There's a good howto here: > >[2]http://arctic.org/~dean/rdiff-backup/unattended.html > Yes, thanks, that's very useful. -- 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
[rdiff-backup-users] Allowing only rdiff-backup across a connection, how to set up?
If I want to allow *only* rdiff backup to use an ssh link between two machines what's the best way of setting it up? What I want to be able to do is set up a [relatively] insecure passwordless ssh link, i.e. a private key at one end with no passphrase, but make it fairly secure by only allowing rdiff-backup to run across that connection. If I simply put "ForceCommand rdiff-backup" at the ssh 'server' end will it do what I want or do I need to put the exact rdiff-backup remote end command there? or is there a better/easier way to achieve what I want to do? -- 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
[rdiff-backup-users] What does "Warning: Access Control List file not found
What does this error mean:- Warning: Access Control List file not found Do I need to do anyhting about it? I probably provoked it by moving various things around on the system being backed up by rdiff-backup (not while it was doing it though). -- 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
[rdiff-backup-users] Re: Age old problem, how to 'archive' old data out of backups?
On Thu, Sep 03, 2009 at 07:08:28PM -0700, James Downs wrote: > > On Sep 3, 2009, at 3:14 PM, Chris G wrote: > >> Is there any easy/obvious way of archiving old data out of home >> directories so that rdiff-backup backups shrink? I suspect that there > > If you delete data from the source directories, and then later "-- > remove-older-than", old versions will get purged, including files that > were deleted. At that point, you will no longer be able to recover that > file. > > Is this what you're looking for? > Yes, sort of, but not quite as --remove-older-than will remove *everything* older than the given date won't it? Some very old stuff I want to keep but not others. E.g. I have a ~/tmp directory which gets backup up, it would be nice to be able to clear out ~/tmp *and* the backups of it. I do want it to be backed up but there's a fair chance that I don't want to keep the backups for long. There are other similar but less well defined areas. Another very obvious example is if one renames or moves a large chunk of data. I currently have my photographs catalogued and managed by digikam, I'm thinking of renaming the root of my pictures now that digikam can have multiple roots, if I do this I'll have 200Gb or so of duplicated backup! I want the ability to, for example, rename ~/pictures (the current digikam tree) to, say, ~/images. Then, once things have settled, I want to be able to delete the backup of ~/pictures as eveything that was there is now in ~/images. OK, I'll lose any history but once I've checked the new digikam tree is OK there's no history that I want or need. -- 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
[rdiff-backup-users] Re: Age old problem, how to 'archive' old data out of backups?
On Thu, Sep 03, 2009 at 06:38:22PM -0400, Greg Freemyer wrote: > On Thu, Sep 3, 2009 at 6:14 PM, Chris G wrote: > > Is there any easy/obvious way of archiving old data out of home > > directories so that rdiff-backup backups shrink? I suspect that there > > isn't but it's surely an important requirement for any sane backup system. > > > > My home directory is now something like 220Gb, of that about half > > (mostly images) is real live data, the other half is backups done > > during OS upgrades, backups of other users' data, backups of old disk > > drives, etc. I really don't need live backups of this 'other half' > > but I can't see any easy way of getting rid of it such that it > > actually cuts down what rdiff-backup copies as well. > > > > Is there any way around this problem? > > Can you put it all in a "backup" directory under home? > > If so, tell rdiff-backup not to backup that directory. It has an > exclude capability. > But that doesn't clear it out of the destination once it's there. I have lots of old bits and pieces around that I used to want to backup but I don't want to any more. I can *delete* then from the 'source' but how does one clear them off the destination? -- 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
[rdiff-backup-users] Age old problem, how to 'archive' old data out of backups?
Is there any easy/obvious way of archiving old data out of home directories so that rdiff-backup backups shrink? I suspect that there isn't but it's surely an important requirement for any sane backup system. My home directory is now something like 220Gb, of that about half (mostly images) is real live data, the other half is backups done during OS upgrades, backups of other users' data, backups of old disk drives, etc. I really don't need live backups of this 'other half' but I can't see any easy way of getting rid of it such that it actually cuts down what rdiff-backup copies as well. Is there any way around this problem? -- 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
[rdiff-backup-users] Re: What does this traceback mean - I'm lost!
On Thu, Sep 03, 2009 at 12:09:34PM +0100, Chris G wrote:
> I just got this traceback from rdiff-backup, it's not telling me
> anything I understand at all. It's happening since I added
> --exclude-device-files to my rdiff-backup command but I can't
Oops, it was --exclude-other-filesystems.
> guarantee that's the only thing I've done as a lot has changed
> recently (new target system, version 1.28 of rdiff-backup, etc.).
>
Well I have just manually retried the backup with the
--exclude-other-filesystems and first time around it said "Previous
backup seems to have failed, regressing destination now." but was
otherwise OK, second time it worked without problems.
In fact they all seem to be working OK now so the below error appears
to have been a one-off, it would still be nice to know what caused it
though.
>
> Traceback (most recent call last):
> File "/usr/local/bin/rdiff-backup", line 30, in
> rdiff_backup.Main.error_check_Main(sys.argv[1:])
> File "/var/lib/python-support/python2.6/rdiff_backup/Main.py", line
> 304, in
> error_check_Main
> try: Main(arglist)
> File "/var/lib/python-support/python2.6/rdiff_backup/Main.py", line
> 324, in
> Main
> take_action(rps)
> File "/var/lib/python-support/python2.6/rdiff_backup/Main.py", line
> 280, in
> take_action
> elif action == "backup": Backup(rps[0], rps[1])
> File "/var/lib/python-support/python2.6/rdiff_backup/Main.py", line
> 343, in
> Backup
> backup.Mirror_and_increment(rpin, rpout, incdir)
> File "/var/lib/python-support/python2.6/rdiff_backup/backup.py",
> line 51, in
> Mirror_and_increment
> DestS.patch_and_increment(dest_rpath, source_diffiter, inc_rpath)
> File "/var/lib/python-support/python2.6/rdiff_backup/backup.py",
> line 243, in
> patch_and_increment
> ITR(diff.index, diff)
> File "/var/lib/python-support/python2.6/rdiff_backup/rorpiter.py",
> line 284,
> in __call__
> branch.start_process(*args)
> File "/var/lib/python-support/python2.6/rdiff_backup/backup.py",
> line 718, in
> start_process
> ("Either %s or %s must be a directory" % (repr(diff_rorp.path),
> AttributeError: RORPath instance has no attribute 'path'
> run-parts: /etc/cron.daily/backup exited with return code 1
>
> --
> Chris Green
>
--
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
[rdiff-backup-users] What does this traceback mean - I'm lost!
I just got this traceback from rdiff-backup, it's not telling me
anything I understand at all. It's happening since I added
--exclude-device-files to my rdiff-backup command but I can't
guarantee that's the only thing I've done as a lot has changed
recently (new target system, version 1.28 of rdiff-backup, etc.).
Traceback (most recent call last):
File "/usr/local/bin/rdiff-backup", line 30, in
rdiff_backup.Main.error_check_Main(sys.argv[1:])
File "/var/lib/python-support/python2.6/rdiff_backup/Main.py", line
304, in
error_check_Main
try: Main(arglist)
File "/var/lib/python-support/python2.6/rdiff_backup/Main.py", line
324, in
Main
take_action(rps)
File "/var/lib/python-support/python2.6/rdiff_backup/Main.py", line
280, in
take_action
elif action == "backup": Backup(rps[0], rps[1])
File "/var/lib/python-support/python2.6/rdiff_backup/Main.py", line
343, in
Backup
backup.Mirror_and_increment(rpin, rpout, incdir)
File "/var/lib/python-support/python2.6/rdiff_backup/backup.py",
line 51, in
Mirror_and_increment
DestS.patch_and_increment(dest_rpath, source_diffiter, inc_rpath)
File "/var/lib/python-support/python2.6/rdiff_backup/backup.py",
line 243, in
patch_and_increment
ITR(diff.index, diff)
File "/var/lib/python-support/python2.6/rdiff_backup/rorpiter.py",
line 284,
in __call__
branch.start_process(*args)
File "/var/lib/python-support/python2.6/rdiff_backup/backup.py",
line 718, in
start_process
("Either %s or %s must be a directory" % (repr(diff_rorp.path),
AttributeError: RORPath instance has no attribute 'path'
run-parts: /etc/cron.daily/backup exited with return code 1
--
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
[rdiff-backup-users] Re: Re: Re: Will these errors clear on the next pass?
On Wed, Sep 02, 2009 at 08:12:18PM +0100, Chris Wilson wrote: > Hi Chris, > > On Wed, 2 Sep 2009, Chris G wrote: > >>>>>>> /etc/cron.daily/backup: UpdateError >>>>>>> nfs/rpc_pipefs/nfs/clnt6/info Updated mirror temp file >>>>>>> /bak/var/lib/nfs/rpc_pipefs/nfs/clnt6/rdiff-backup.tmp.52 >>>>>>> does not match source UpdateError >>>>>>> nfs/rpc_pipefs/nfs/clnt7/info >>> >>>> ... and it doesn't go away by itself, I have *exactly* the same errors >>>> today. >> >> On looking harder at it I realised *why* it won't go away. The "does >> not match" errors are coming from /var/lib/nfs/rpc_pipefs/nfs >> directories and I'm backing up to, guess what, a remote NFS mounted >> drive so the files in question really *are* changing during the backup. >> >> I want to back up /var/lib so this is a problem. >> >> All I need is a way to make the error messages go away so a successful >> backup is silent. > > Try --exclude-other-filesystems or --exclude /var/lib/nfs/rpc_pipefs > > There's no reason to back up an rpc_pipefs because you wouldn't want to > restore it. Same for /proc, /sys, etc. > Yes, that should do it, it isn't initially obvious that those 'files' aren't real files but special NFS filesystem ones. I've added --exclude-other-filesystems to the backup so we'll see tomorrow if it worked. Thank you! -- 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
[rdiff-backup-users] Re: Re: Will these errors clear on the next pass?
On Mon, Aug 31, 2009 at 08:24:54AM -0400, Daniel Miller wrote: > > On Aug 31, 2009, at 6:43 AM, Chris G wrote: > >> On Sun, Aug 30, 2009 at 02:54:57PM +0100, Chris G wrote: >>> On Sun, Aug 30, 2009 at 01:08:22PM +0200, Andreas Olsson wrote: >>>> On Sunday 30 August 2009 12:52:49 Chris G wrote: >>>>> I had an interrupted backup which resulted in the following >>>>> errors:- >>>>> >>>>> - Forwarded message from Anacron - >>>>> >>>>> /etc/cron.daily/backup: >>>>> UpdateError nfs/rpc_pipefs/nfs/clnt6/info Updated mirror temp file >>>>> /bak/var/lib/nfs/rpc_pipefs/nfs/clnt6/rdiff-backup.tmp.52 does >>>>> not match >>>>> source UpdateError nfs/rpc_pipefs/nfs/clnt7/info Updated mirror >>>>> temp file >>>>> /bak/var/lib/nfs/rpc_pipefs/nfs/clnt7/rdiff-backup.tmp.53 does >>>>> not match >>>>> source UpdateError nfs/rpc_pipefs/nfs/clnt8/info Updated mirror >>>>> temp file >>>>> /bak/var/lib/nfs/rpc_pipefs/nfs/clnt8/rdiff-backup.tmp.54 does >>>>> not match >>>>> source >>>>> >>>>> >>>>> - End forwarded message - >>>>> >>>>> Will these clear up on the next pass? If not how does one deal >>>>> with them? >>>> >>>> Looks very much like http://wiki.rdiff-backup.org/wiki/index.php/ >>>> UpdateErrorOne >>>> > > > >> ... and it doesn't go away by itself, I have *exactly* the same errors >> today. > > No, it probably won't go away by itself. I get the same type of error on > the same (high activity) log file every single day. The link that > Andreas sent has an explanation of the issue and some potential work- > arounds. > On looking harder at it I realised *why* it won't go away. The "does not match" errors are coming from /var/lib/nfs/rpc_pipefs/nfs directories and I'm backing up to, guess what, a remote NFS mounted drive so the files in question really *are* changing during the backup. I want to back up /var/lib so this is a problem. > I personally think rdiff-backup should have an option that you could > specify "files in directory X should be backed up even if they change > during the backup". It would be cleaner than the other two "simple" > solutions mentioned on the wiki. > All I need is a way to make the error messages go away so a successful backup is silent. -- 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
[rdiff-backup-users] Re: Will these errors clear on the next pass?
On Sun, Aug 30, 2009 at 02:54:57PM +0100, Chris G wrote: > On Sun, Aug 30, 2009 at 01:08:22PM +0200, Andreas Olsson wrote: > > On Sunday 30 August 2009 12:52:49 Chris G wrote: > > > I had an interrupted backup which resulted in the following errors:- > > > > > > - Forwarded message from Anacron - > > > > > > /etc/cron.daily/backup: > > > UpdateError nfs/rpc_pipefs/nfs/clnt6/info Updated mirror temp file > > > /bak/var/lib/nfs/rpc_pipefs/nfs/clnt6/rdiff-backup.tmp.52 does not match > > > source UpdateError nfs/rpc_pipefs/nfs/clnt7/info Updated mirror temp file > > > /bak/var/lib/nfs/rpc_pipefs/nfs/clnt7/rdiff-backup.tmp.53 does not match > > > source UpdateError nfs/rpc_pipefs/nfs/clnt8/info Updated mirror temp file > > > /bak/var/lib/nfs/rpc_pipefs/nfs/clnt8/rdiff-backup.tmp.54 does not match > > > source > > > > > > > > > - End forwarded message - > > > > > > Will these clear up on the next pass? If not how does one deal with them? > > > > Looks very much like > > http://wiki.rdiff-backup.org/wiki/index.php/UpdateErrorOne > > > > Are you sure your backup actually got interrupted? > > > I think so, it was me that interrupted it! My system was running a > bit slowly and I noticed the rdiff-backup was still running several > hours after it started so I assumed something was broken and killed > it. This was a backup to a new remote disk so I thought I must have > done something wrong, I think it was actually just the first backup > taking a long time. > ... and it doesn't go away by itself, I have *exactly* the same errors today. -- 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
[rdiff-backup-users] Re: Will these errors clear on the next pass?
On Sun, Aug 30, 2009 at 01:08:22PM +0200, Andreas Olsson wrote: > On Sunday 30 August 2009 12:52:49 Chris G wrote: > > I had an interrupted backup which resulted in the following errors:- > > > > - Forwarded message from Anacron - > > > > /etc/cron.daily/backup: > > UpdateError nfs/rpc_pipefs/nfs/clnt6/info Updated mirror temp file > > /bak/var/lib/nfs/rpc_pipefs/nfs/clnt6/rdiff-backup.tmp.52 does not match > > source UpdateError nfs/rpc_pipefs/nfs/clnt7/info Updated mirror temp file > > /bak/var/lib/nfs/rpc_pipefs/nfs/clnt7/rdiff-backup.tmp.53 does not match > > source UpdateError nfs/rpc_pipefs/nfs/clnt8/info Updated mirror temp file > > /bak/var/lib/nfs/rpc_pipefs/nfs/clnt8/rdiff-backup.tmp.54 does not match > > source > > > > > > - End forwarded message - > > > > Will these clear up on the next pass? If not how does one deal with them? > > Looks very much like > http://wiki.rdiff-backup.org/wiki/index.php/UpdateErrorOne > > Are you sure your backup actually got interrupted? > I think so, it was me that interrupted it! My system was running a bit slowly and I noticed the rdiff-backup was still running several hours after it started so I assumed something was broken and killed it. This was a backup to a new remote disk so I thought I must have done something wrong, I think it was actually just the first backup taking a long time. -- 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
[rdiff-backup-users] Will these errors clear on the next pass?
I had an interrupted backup which resulted in the following errors:- - Forwarded message from Anacron - /etc/cron.daily/backup: UpdateError nfs/rpc_pipefs/nfs/clnt6/info Updated mirror temp file /bak/var/lib/nfs/rpc_pipefs/nfs/clnt6/rdiff-backup.tmp.52 does not match source UpdateError nfs/rpc_pipefs/nfs/clnt7/info Updated mirror temp file /bak/var/lib/nfs/rpc_pipefs/nfs/clnt7/rdiff-backup.tmp.53 does not match source UpdateError nfs/rpc_pipefs/nfs/clnt8/info Updated mirror temp file /bak/var/lib/nfs/rpc_pipefs/nfs/clnt8/rdiff-backup.tmp.54 does not match source - End forwarded message - Will these clear up on the next pass? If not how does one deal with them? -- 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
[rdiff-backup-users] os.popen2 is deprecated - what to do?
I'm getting lots of messages from my rdiff-backup scripts saying:- /var/lib/python-support/python2.6/rdiff_backup/SetConnections.py:148: DeprecationWarning: os.popen2 is deprecated. Use the subprocess module. stdin, stdout = os.popen2(remote_cmd) Has this been fixed in a recent version of rdiff-backup? -- 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
[rdiff-backup-users] Re: Is rdiff-backup useful for my purpose?
On Mon, Mar 30, 2009 at 06:33:39PM +0200, Fabrice DELENTE wrote: > Hello. > > I'd like to do the following: > > I have two computers on which I work. I'd like to sync some directories on > both of these computers, so that both of them always have the latest version > of the files I'm working on. > > I didn't find any option in rdiff-backup that updates files only; is it > possible, and is rdiff-backup adapted to the task, or should I look for > something else? > > I'd like to use rdiff-backup if possible as I have been very impressed by > its speed to copy a directory. > I think that rsync is probably better fitted to this particular task. -- 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
[rdiff-backup-users] Re: Re: What's this error telling me?
On Mon, Mar 02, 2009 at 04:31:05PM +, Chris G wrote: > On Mon, Mar 02, 2009 at 11:19:20AM -0500, Andrew Ferguson wrote: > > > > On Mar 2, 2009, at 11:16 AM, Chris G wrote: > > > >> On Mon, Mar 02, 2009 at 10:59:45AM -0500, Andrew Ferguson wrote: > >>> On Mar 2, 2009, at 10:48 AM, Chris G wrote: > >>>> r...@chris:/home/chris# rdiff-backup -v1 /home/ben > >>>> b...@garage::/bak/chris/home/ben > >>> > >>> > >>> Maybe remove -v1 (or change to -v8) and see what else rdiff-backup may be > >>> trying to tell you? -v1 means to print the least amount of information > >>> possible. The default is -v3. > >>> > >> I'd forgotten that was there, however removing makes little difference > >> except that I get the whole traceback twice. > > > > > > Can you run it with -v8 and paste everything? Sometimes there are helpful > > messages which are easy to miss. > > > One thing that the -v3 showed me was that I *wasn't* running version > 1.2.6 at both ends. I'm fixing that before I go any further. > and that was what the problem was! With 1.2.6 at both ends the backup works OK. This harks back to the recent thread about version mismatches, the reason I had a mismatch is rather complicated:- I run Ubuntu 8.10 on all my home systems, this currently provides version 1.1.16 from the Ubuntu repositories. I run backups across my LAN and to a remote system. The remote system (not under my control) runs version 1.0.5. So I update my desktop system and the remote system to have a local copy of rdiff-backup 1.2.6, this worked well until I noticed the errors from my LAN system which had still got 1.1.16. As I say, now fixed, but this version problem can become a bit of a drag. ... oh, and by the way, that -v1 is necessary so that I don't get an E-Mail from cron every time the backup runs. -- 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
[rdiff-backup-users] Re: Re: What's this error telling me?
On Mon, Mar 02, 2009 at 11:19:20AM -0500, Andrew Ferguson wrote: > > On Mar 2, 2009, at 11:16 AM, Chris G wrote: > >> On Mon, Mar 02, 2009 at 10:59:45AM -0500, Andrew Ferguson wrote: >>> On Mar 2, 2009, at 10:48 AM, Chris G wrote: >>>> r...@chris:/home/chris# rdiff-backup -v1 /home/ben >>>> b...@garage::/bak/chris/home/ben >>> >>> >>> Maybe remove -v1 (or change to -v8) and see what else rdiff-backup may be >>> trying to tell you? -v1 means to print the least amount of information >>> possible. The default is -v3. >>> >> I'd forgotten that was there, however removing makes little difference >> except that I get the whole traceback twice. > > > Can you run it with -v8 and paste everything? Sometimes there are helpful > messages which are easy to miss. > One thing that the -v3 showed me was that I *wasn't* running version 1.2.6 at both ends. I'm fixing that before I go any further. -- 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
[rdiff-backup-users] Re: What's this error telling me?
On Mon, Mar 02, 2009 at 10:59:45AM -0500, Andrew Ferguson wrote: > On Mar 2, 2009, at 10:48 AM, Chris G wrote: >>r...@chris:/home/chris# rdiff-backup -v1 /home/ben >> b...@garage::/bak/chris/home/ben > > > Maybe remove -v1 (or change to -v8) and see what else rdiff-backup may be > trying to tell you? -v1 means to print the least amount of information > possible. The default is -v3. > I'd forgotten that was there, however removing makes little difference except that I get the whole traceback twice. -- 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
[rdiff-backup-users] What's this error telling me?
I'm getting this error when running rdiff-backup version 1.2.6 between two xubuntu 8.10 systems:- r...@chris:/home/chris# rdiff-backup -v1 /home/ben b...@garage::/bak/chris/home/ben Traceback (most recent call last): File "/usr/local/bin/rdiff-backup", line 30, in rdiff_backup.Main.error_check_Main(sys.argv[1:]) File "/usr/local/lib/python2.5/site-packages/rdiff_backup/Main.py", line 304, in error_check_Main try: Main(arglist) File "/usr/local/lib/python2.5/site-packages/rdiff_backup/Main.py", line 321, in Main rps = map(SetConnections.cmdpair2rp, cmdpairs) File "/usr/local/lib/python2.5/site-packages/rdiff_backup/SetConnections.py", line 78, in cmdpair2rp return rpath.RPath(conn, filename).normalize() File "/usr/local/lib/python2.5/site-packages/rdiff_backup/rpath.py", line 884, in __init__ else: self.setdata() File "/usr/local/lib/python2.5/site-packages/rdiff_backup/rpath.py", line 908, in setdata self.data = self.conn.rpath.make_file_dict(self.path) File "/usr/local/lib/python2.5/site-packages/rdiff_backup/connection.py", line 450, in __call__ return apply(self.connection.reval, (self.name,) + args) File "/usr/local/lib/python2.5/site-packages/rdiff_backup/connection.py", line 370, in reval if isinstance(result, Exception): raise result rdiff_backup.Security.Violation: Warning Security Violation! Bad request for function: rpath.make_file_dict with arguments: ['/bak/chris/home/ben'] Fatal Error: Lost connection to the remote system I *did* have a -restrict-update-only parameter at the remote end but have now removed it and restarted sshd but I'm still getting the error. -- 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
[rdiff-backup-users] Re: How to manage with old[ish] versions?
On Thu, Feb 19, 2009 at 10:58:58PM +, Chris Wilson wrote: > Hi Chris, > > On Thu, 19 Feb 2009, Chris G wrote: > >> I am using rdiff-backup from xubuntu 8.10, the version available on the >> Ubuntu repositories is 1.1.16. This makes life rather difficult when >> trying to backup to and fro from systems where I'm building rdiff-backup >> myself. >> >> OK, I can do backups between different versions but it gives warning >> messages and also different versions are sometimes incompatible. >> >> Is there any way to tell a newer version to work compatibly (and silently) >> with older versions? > > I find the simples way is to ignore the packages and install exactly the > version that I want from source. Works on any distro :) > Yes, that's what I have ended up doing, it's not *entirely* straightforward though as one end of the backup is just an ssh access account on my hosting provider so I don't have root there. Thus I need to install things needed for rdiff-backup as well as rdiff-backup itself. I have to build/install librsync with "--prefix=$HOME" before doing the same with rdiff-backup which needs a few extra install parameters to tell it where things are. At 'this' end it's relatively easy because I can just apt-get any libraries required and then install the latest rdiff-backup with a prefix setting so it installs in /usr/local/bin and doesn't interfere with anything else. > I find the backwards-incompatibility to be one of the biggest bugbears of > rdiff-backup and boxbackup (which I maintain). I'm still running > rdiff-backup 1.0.x on all my machines for this reason. > -- 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
[rdiff-backup-users] How to manage with old[ish] versions?
I am using rdiff-backup from xubuntu 8.10, the version available on the Ubuntu repositories is 1.1.16. This makes life rather difficult when trying to backup to and fro from systems where I'm building rdiff-backup myself. OK, I can do backups between different versions but it gives warning messages and also different versions are sometimes incompatible. Is there any way to tell a newer version to work compatibly (and silently) with older versions? -- 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
Re: [rdiff-backup-users] Clarification of --restrict-update-only
On Thu, Feb 05, 2009 at 08:20:45AM -0500, Andrew Ferguson wrote: > On Feb 5, 2009, at 8:13 AM, Dominic wrote: >> The ones I think most interesting are first whether new repositories can >> be created (logically yes, but does it work?), and second >> --check-destination-dir (and automatic fixing of a previous failed >> backup). Logically --check-destination-dir should work because the action >> that rdiff-backup takes in this case is not a security risk (it is only >> undoing a backup that has failed, and a malicious user cannot use it to >> remove valid backups), but as it involves deleting data on the server >> --restrict-update-only might prevent it. I guess the best way to find out >> for sure is to create a failed backup and try it... > > Automatically repairing a failed backup will fail if you have > --restrict-update-only for exactly the reason Dominic describes. I have > thought this one through yet, but perhaps over the course of multiple > backup sessions, a malicious user could construct a source to fail in a bad > way when the repository tries to repair itself. > > An administrator paranoid and involved enough to be using > --restrict-update-only is assumed to be vigilant enough to pay attention > when rdiff-backup has failed (since it will error and backtrace) and > manually intervene to repair the repository. > Exactly, I will notice if I'm getting any errors from rdiff-backup and will go and investigate. > > Regarding first creating new repositories, yes, I think that too will be > blocked. There was some discussion a few years ago about this: > http://savannah.nongnu.org/bugs/?16897 ... I don't remember what was > resolved. I suppose we could add os.mkdir() to the safe list. > It's not a big issue for me, if/when I set up new clients and/or new hierarchies to back up I'm quite happy to do some manual backups or remove the --restrict-update-only from teh destination temporarily. -- 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
Re: [rdiff-backup-users] Clarification of --restrict-update-only
On Thu, Feb 05, 2009 at 01:13:23PM +, Dominic wrote: > Chris G wrote: >>> >>>> Anyway, back to the original point of my question, if I put:- >>>> >>>> Match User=bak >>>> ForceCommand rdiff-backup --server --restrict-update-only / >>>> >>>> at the end of my sshd configuration on the backup server will it prevent >>>> rdiff-backup doing anything but updates on any/every part of the >>>> backup hierarchy? >>>> >>> From my reading of man page I think you are correct, but I suggest you >>> accept the position of 'restrict-update-only Tester In Chief' and let us >>> know how you get on! I would be interested to know if it causes any >>> problems when comparing or recovering files (but I don't think it >>> should). Can you use it when creating a new repository? >> K, I'll add the extra parameter and see how it all goes. > To get you started I did a list of rdiff-backup options below showing > whether they should work okay when used on the rdiff-backup push client > side with your proposed --restrict-update-only server-side restriction - > 'Yes' means I think it should always work and 'No' means I think it might > sometimes or always cause a failure depending on the situation. > > The ones I think most interesting are first whether new repositories can be > created (logically yes, but does it work?), and second > --check-destination-dir (and automatic fixing of a previous failed backup). > Logically --check-destination-dir should work because the action that > rdiff-backup takes in this case is not a security risk (it is only undoing > a backup that has failed, and a malicious user cannot use it to remove > valid backups), but as it involves deleting data on the server > --restrict-update-only might prevent it. I guess the best way to find out > for sure is to create a failed backup and try it... > Excellent, thank you for all this information. > Some historic (Jun 2006) discussion here: > http://www.nabble.com/-bug--16897--Security-Violation-on-first-increment-while-using-restrict-update-only-td4963925.html > > Dominic > > *??? [default], -b,* *--backup-mode (might be a problem creating new > repositories?)* > > *Yes --calculate-average* > > *Yes --carbonfile* > > *??? --check-destination-dir (and **automatic fixing of a previous > failed backup)* > > *Yes --compare** > > No*--create-full-path* > > Yes *--current-time* /seconds/ > > Yes *--exclude** > > No*--force* > > Yes *--group-mapping-file* /filename/ > > Yes *--include** > > Yes *--list** > > Yes *--max-file-size* /size/ > > Yes *--min-file-size* /size/ > > Yes *--never-drop-acls* > > Yes *--no-** > > Yes *--null-separator* > > Yes *--parsable-output* > > Yes *--override-chars-to-quote* > > Yes *--preserve-numerical-ids* > > Yes *--print-statistics* > > Yes *-r,* *--restore-as-of* /restore/*_*/time/ > > Yes *--remote-schema* /schema/ > > No*--remote-tempdir* /path/ (workaround: add --tempdir to > ForceCommand in sshd_config?) > > No*--remove-older-than* /time/*_*/spec/ > > N/A *--restrict* /path/ > > N/A *--restrict-read-only* /path/ > > N/A *--restrict-update-only* /path/ > > N/A *--server* > > Yes *--ssh-no-compression* > > Yes *--tempdir* /path/ > > Yes *--terminal-verbosity* /[0-9]/ > > Yes *--test-server* > > Yes *--use-compatible-timestamps* > > Yes *--user-mapping-file* /filename/ > > Yes *-v*/[0-9]/*,* *--verbosity* /[0-9]/ > > Yes *--verify** > > Yes *-V,* *--version* > > > > > ___ > 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 > -- 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
Re: [rdiff-backup-users] Clarification of --restrict-update-only
On Thu, Feb 05, 2009 at 11:08:04AM +, Dominic wrote: > Chris G wrote: >> Stateless except that they need some way of telling their owner that >> the backup has failed. In my small LAN situation the backup server >> runs unattended in the garage, my desktop machine runs all the time >> and other desktop machine are turned on as required. >> >> I *need* to know if the backups to the machine in the garage have >> failed, I'm not disciplined enough to check manually if the machine >> is running every day. Backups can fail if the cable gets >> disconnected, if the machine dies/loses power, or if the software >> screws up. A 'push' backup gives me a pretty foolproof way of >> checking that does nothing if all is well and sends me a mail message >> if it's gone wrong. > Using the pull backup approach, why can't the backup server send you emails > if there are problems with the backup? > It can, but that is just as dependent on the machine working as the backup is. Pull the ethernet cable out and it won't work. > Or get it to send you a daily email anyway saying what's been happening, > and if you don't get it one day, you know something's up. > *Not* getting an E-Mail is not a good way to tell myself something is wrong, unfortunately my mind doesn't work that way round! :-) I do look at my Logwatch E-Mails but only occasionally and when I remember, soemthing like that isn't good for monitoring backups. > Or get it to scp a small file each day to your main machine(s) indicating > that all is well with backups today, and your main machine(s) can check for > this daily and send you an email if the file isn't there or if the file > contents indicate that there is a problem? > Yes, there are various ways of doing this (plus nagios etc.) but they all introduce more complexity and thus ways of failing. I'm looking for the simplest possible way of doing it that's reasonably fail-safe. It looks as if what I have plus the --restrict-update-only should get me to about where I want to be. -- 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
Re: [rdiff-backup-users] Clarification of --restrict-update-only
On Thu, Feb 05, 2009 at 11:28:09AM +, Dominic wrote: > Chris G wrote: >> Anyway, back to the original point of my question, if I put:- >> >> Match User=bak >> ForceCommand rdiff-backup --server --restrict-update-only / >> >> at the end of my sshd configuration on the backup server will it prevent >> rdiff-backup doing anything but updates on any/every part of the >> backup hierarchy? > From my reading of man page I think you are correct, but I suggest you > accept the position of 'restrict-update-only Tester In Chief' and let us > know how you get on! I would be interested to know if it causes any > problems when comparing or recovering files (but I don't think it should). > Can you use it when creating a new repository? > OK, I'll add the extra parameter and see how it all goes. I can easily enough try adding another client after having added the parameter. > I take it you are not concerned about what a local root user might do on > the backup machine? How secure is your garage?! > The garage's "security" is that it's quite a way from the house and thus even a serious fire in the house shouldn't affect the garage. That's the primary reason for putting a backup in the garage. The rdiff-backup questions relate more to an electronic intruder getting access to the garage system from the client systems in the house. It's very unlikely that an electronic intruder would get into the garage system, it has no 'outside facing' ports at all, the only way to get to it is via my desktop machine - hence all these questions here to try and minimise that risk. If someone breaks into the garage physically they could, obviously, get into the machine but they'd need passwords from there to get into the other machines on the LAN. The garage is fairly secure, as secure as the house probably. A burglar who steals computers from the house probably won't even think to look for computers in the garage. I also back up the most important stuff (i.e. the company accounts) off site at my hosting company login account. That's not particularly secure against electronic intruders but *is* secure against burglars in our house. I.e. the idea is that I should be safe against any one type of intrusion. -- 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
Re: [rdiff-backup-users] Clarification of --restrict-update-only
Anyway, back to the original point of my question, if I put:- Match User=bak ForceCommand rdiff-backup --server --restrict-update-only / at the end of my sshd configuration on the backup server will it prevent rdiff-backup doing anything but updates on any/every part of the backup hierarchy? I know the "ForceCommand rdiff-backup --server" bit works, attempts to log in to the backup server using ssh to the bak account fail. Thus the only thing an intruder can do from a client machine using the passwordless bak account is to run rdiff-backup. If I can further restrict it to minimise the possibility of deleting useful data then so much the better, I just want to clarify how the restrict-update-only works. -- 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
Re: [rdiff-backup-users] Clarification of --restrict-update-only
On Wed, Feb 04, 2009 at 08:32:07PM -0500, Dimi Paun wrote: > > On Thu, 2009-02-05 at 01:52 +0100, Jakob Unterwurzacher wrote: > > IMO "the" solution to this is to use pull-style backups. The backup > > machine should login to your machine (and not the other way round) and > > start the backup. > > That's right -- this is the model we use in safekeep too > (plug http://safekeep.sf.net). It also has the added advantage > of nicely centralizing all settings, in effect making the > machines that are being backed-up stateless from a configuration > perspective. > Stateless except that they need some way of telling their owner that the backup has failed. In my small LAN situation the backup server runs unattended in the garage, my desktop machine runs all the time and other desktop machine are turned on as required. I *need* to know if the backups to the machine in the garage have failed, I'm not disciplined enough to check manually if the machine is running every day. Backups can fail if the cable gets disconnected, if the machine dies/loses power, or if the software screws up. A 'push' backup gives me a pretty foolproof way of checking that does nothing if all is well and sends me a mail message if it's gone wrong. -- 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
Re: [rdiff-backup-users] Clarification of --restrict-update-only
On Thu, Feb 05, 2009 at 01:52:20AM +0100, Jakob Unterwurzacher wrote: > Chris G schrieb: > > If I never turn it on it will be perfectly safe. :-) > > > > Yes, my client (the machine to be backed up) is fairly secure. > > However given that ssh access from the outside world is allowed (even > > if only for non-root and from specific IPs) there is a risk that > > someone could get into it and wreak havoc. What I want to do is to > > minimise the risk that anyone who does that will also be able to get > > at my backups and destroy them too. > > > > IMO "the" solution to this is to use pull-style backups. The backup > machine should login to your machine (and not the other way round) and > start the backup. That's how I *had* arranged it but it has the difficulty of needing extra monitoring software to tell me if the backups are no longer working. A 'push' backup has the big advantage that any errors or failures get mailed to me withing 24 hours without me having to add any sort of extra monitoring. The client machine is actually pretty secure, it has ssh access allowed from the outside world but only from two specific IP addresses neither of which is a publicly accessible machine so the chances of an intruder getting in are pretty small. > That way, no intruder on your machine can destroy the backups. If he > deletes files, the deletes will be backed-up, but the files will still > be in the increments. That's what I'm trying to approach with a 'push' backup plus some extra arguments to rdiff-backup. -- 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
Re: [rdiff-backup-users] Clarification of --restrict-update-only
On Wed, Feb 04, 2009 at 03:33:05PM -0500, John covici wrote: > on Wednesday 02/04/2009 Chris G(c...@isbd.net) wrote > > On Wed, Feb 04, 2009 at 01:52:32PM -0500, John covici wrote: > > > on Wednesday 02/04/2009 Chris G(c...@isbd.net) wrote > > > > I'm using rdiff-backup to backup files across a LAN. The destination > > > > machine has a dedicated backup account which has passwordless ssh > > > > login set up for client machines that want to do backups. > > > > > > > > To make things a bit more secure I have added the following to my > > > > sshd_config on the destination/backup machine:- > > > > > > > > Match User=bak > > > > ForceCommand rdiff-backup --server > > > > > > > > So far so good. I can backup as required but it's not possible to > > > > login to the bak account using ssh. I'd like to lock it down a bit > > > > further by using the --restrict-update-only option so that if an > > > > intruder did gain access to a client machine they wouldn't be able to > > > > remove anything useful from the backups by deleting or overwriting. > > > > > > > > However I'm not quite clear how --restrict-update-only works, can I > > > > just do something like:- > > > > > > > > Match User=bak > > > > ForceCommand rdiff-backup --server --restrict-update-only / > > > > > > > > and thus prevent anything other than updates for *all* backups? > > > > > > > > > > Why don't you just have in your sshd config > > > PermitRootLogin without-password > > > > > > and have a public key of your client in the > > > /root/.ssh/authorized_hosts on the server. I don't think the > > > restrict-update is very secure anyway, but this works well. > > > > > That would permit exactly what I'm trying to avoid wouldn't it? > > > > If (heaven forbid) an intruder got root access to my machine (which is > > the backup client) then they would have free access to the backup > > machine as well. Thus a malicious intruder would be able to delete > > everything on my machine *and* on the backup machine as well. > > > > What I'm trying to do is have a backup which isn't trivially > > accessible from the client. > > > But you could do the same thing on your client so no one could ever > log in to root unless they had a public key on your client. > If I never turn it on it will be perfectly safe. :-) Yes, my client (the machine to be backed up) is fairly secure. However given that ssh access from the outside world is allowed (even if only for non-root and from specific IPs) there is a risk that someone could get into it and wreak havoc. What I want to do is to minimise the risk that anyone who does that will also be able to get at my backups and destroy them too. -- 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
Re: [rdiff-backup-users] Clarification of --restrict-update-only
On Wed, Feb 04, 2009 at 01:52:32PM -0500, John covici wrote: > on Wednesday 02/04/2009 Chris G(c...@isbd.net) wrote > > I'm using rdiff-backup to backup files across a LAN. The destination > > machine has a dedicated backup account which has passwordless ssh > > login set up for client machines that want to do backups. > > > > To make things a bit more secure I have added the following to my > > sshd_config on the destination/backup machine:- > > > > Match User=bak > > ForceCommand rdiff-backup --server > > > > So far so good. I can backup as required but it's not possible to > > login to the bak account using ssh. I'd like to lock it down a bit > > further by using the --restrict-update-only option so that if an > > intruder did gain access to a client machine they wouldn't be able to > > remove anything useful from the backups by deleting or overwriting. > > > > However I'm not quite clear how --restrict-update-only works, can I > > just do something like:- > > > > Match User=bak > > ForceCommand rdiff-backup --server --restrict-update-only / > > > > and thus prevent anything other than updates for *all* backups? > > > > Why don't you just have in your sshd config > PermitRootLogin without-password > > and have a public key of your client in the > /root/.ssh/authorized_hosts on the server. I don't think the > restrict-update is very secure anyway, but this works well. > That would permit exactly what I'm trying to avoid wouldn't it? If (heaven forbid) an intruder got root access to my machine (which is the backup client) then they would have free access to the backup machine as well. Thus a malicious intruder would be able to delete everything on my machine *and* on the backup machine as well. What I'm trying to do is have a backup which isn't trivially accessible from the client. -- 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
[rdiff-backup-users] Clarification of --restrict-update-only
I'm using rdiff-backup to backup files across a LAN. The destination machine has a dedicated backup account which has passwordless ssh login set up for client machines that want to do backups. To make things a bit more secure I have added the following to my sshd_config on the destination/backup machine:- Match User=bak ForceCommand rdiff-backup --server So far so good. I can backup as required but it's not possible to login to the bak account using ssh. I'd like to lock it down a bit further by using the --restrict-update-only option so that if an intruder did gain access to a client machine they wouldn't be able to remove anything useful from the backups by deleting or overwriting. However I'm not quite clear how --restrict-update-only works, can I just do something like:- Match User=bak ForceCommand rdiff-backup --server --restrict-update-only / and thus prevent anything other than updates for *all* backups? -- 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
[rdiff-backup-users] Re: Re: "Truncated header string" error, how to diagnose?
On Sun, May 11, 2008 at 06:46:28PM +0200, Chris Wilson wrote: > Hi Chris, > > On Sun, 11 May 2008, Chris G wrote: > >> I've now cleared up the mess a little, removed all the BSD stuff (that >> I can find) and have done a clean installation of 1.1.15 on the Linux >> remote. My backups now work, though I do have to use "--remote-schema >> 'ssh -C %s /home/isbd/bin/rdiff-backup --server' to make it work. I'm >> not quite clear why this should be as my PATH includes /home/isbd/bin >> but it's not a big problem. > > Non-login shells (such as ssh with a command) do not usually read your > profile or bashrc, and therefore normally miss out on any custom > environment variables, aliases, etc. If you need this, run a shell, such as > 'ssh -C %s bash rdiff-backup --server', or write a wrapper script for > rdiff-backup. > At present it's simpler to include the --remote-schema, it's only in two places. If I find it getting cumbersome I will, as you suggest, write a wrapper for rdiff-backup. -- 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
[rdiff-backup-users] Re: "Truncated header string" error, how to diagnose?
On Sun, May 11, 2008 at 10:07:56AM +0100, Chris G wrote: > On Sun, May 11, 2008 at 09:43:36AM +0100, Chris G wrote: > > > > The only thing that *might* be significant is that the rdiff-backup > > 1.1.5 installation on the remote is installed in my account there > > Typo of course, 1.1.15. > > > whereas the 1.0.5 was a root/system installion. > > > I think that's the problem but I can't work out how to fix it, any > rdiff-backup command, e.g.:- > > ssh [EMAIL PROTECTED] rdiff-backup --version > > simply returns with no output. All other commands executed like this > (at least all the ones I've tried) work fine. > Well I finally got it sorted! Much of the problem was of my own doing, the backup that had been working with rdiff-backup 1.0.5 was to a different remote computer! Both the old and new remote destinations are computers on my hosting company's network, my login is identical on both and my home directory is common to both systems. *However* (and this is what caused most of my grief!) the old destination was a BSD system and the new destination is Linux. In addition, to muddy the waters further, I have a user space installation of Python 2.5.2 on the new system. So when I installed rdiff-backup 1.1.15 on the new system and then my cron jobs were still trying to back up to the old system surprisingly enough it didn't work! :-) I've now cleared up the mess a little, removed all the BSD stuff (that I can find) and have done a clean installation of 1.1.15 on the Linux remote. My backups now work, though I do have to use "--remote-schema 'ssh -C %s /home/isbd/bin/rdiff-backup --server' to make it work. I'm not quite clear why this should be as my PATH includes /home/isbd/bin but it's not a big problem. -- 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
[rdiff-backup-users] Re: "Truncated header string" error, how to diagnose?
On Sun, May 11, 2008 at 09:43:36AM +0100, Chris G wrote: > > The only thing that *might* be significant is that the rdiff-backup > 1.1.5 installation on the remote is installed in my account there Typo of course, 1.1.15. > whereas the 1.0.5 was a root/system installion. > I think that's the problem but I can't work out how to fix it, any rdiff-backup command, e.g.:- ssh [EMAIL PROTECTED] rdiff-backup --version simply returns with no output. All other commands executed like this (at least all the ones I've tried) work fine. -- 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
[rdiff-backup-users] "Truncated header string" error, how to diagnose?
I have just upgraded to rdiff-backup 1.1.15 and now a backup to a remote system which used to work is now failing with the following sent from cron by E-Mail:- Fatal Error: Truncated header string (problem probably originated remotely) Couldn't start up the remote connection by executing ssh -C [EMAIL PROTECTED] rdiff-backup --server Remember that, under the default settings, rdiff-backup must be installed in the PATH on the remote system. See the man page for more information on this. This message may also be displayed if the remote version of rdiff-backup is quite different from the local version (1.1.15). And, no, the remote version of rdiff-backup isn't different from the local version - that's what was wrong yesterday and I've fixed it! It was working fine when there was version 1.0.5 at both ends, I had to upgrade 'this' end to 1.1.15 to get rdiff-backup to work to another system that has 1.1.15 and *that* backup is now working OK. If I execute:- ssh -C [EMAIL PROTECTED] rdiff-backup --server it returns immediately but with no errors. If I add a -v I see:- debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering public key: /home/chris/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 277 debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LC_COLLATE = C debug1: Sending env LANG = en_US.UTF-8 debug1: Sending env LC_CTYPE = en_GB.utf8 debug1: Sending command: rdiff-backup --server debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.1 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status -1 debug1: compress outgoing: raw data 1168, compressed 775, factor 0.66 debug1: compress incoming: raw data 409, compressed 397, factor 0.97 If I ssh to the remote for an interactive session and enter "rdiff-backup --server" it does what's expected and sits waiting, it doesn't exit. "rdiff-backup --version" returns "rdiff-backup 1.1.15". So what's wrong? The only thing that *might* be significant is that the rdiff-backup 1.1.5 installation on the remote is installed in my account there whereas the 1.0.5 was a root/system installion. -- 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
[rdiff-backup-users] Re: Re: Some questions/problems about using rdiff-backup to a remote system
On Fri, May 09, 2008 at 03:44:54PM -0400, Sam Hart wrote: > On Fri, May 9, 2008 at 3:28 PM, Chris G <[EMAIL PROTECTED]> wrote: > > I'm working on this, they don't match at the moment. H, that's a > > real pain! On Fedora the only version of rdiff-backup available seems > > to be the current stable version 1.0.5. On Ubuntu 7.10 its version > > 1.1.14, that leaves me in a quandary, I can build a newer version on > > Fedora but how do I get 1.1.14 as the current version is 1.1.15. I > > suppose I can build 1.1.15 on both but it's not very satisfactory. > > Building from source is an option, or obtaining packages from other locations. > > Not sure if this helps, but when I needed rdiff-backup for CentOS, I > actually grabbed it from Dag Wieers: > http://dag.wieers.com/rpm/packages/rdiff-backup/ > > I don't see a recent FC build on there, but one of the RHEL/CentOS > ones might work. > I just downloaded the 1.1.15 tarball from the rdiff-backup site and built it at both ends, apart from having to get a few dependencies on the Ubuntu system that worked OK. All *seems* to be working OK now, I'll just have to see if the cron driven overnight backups work. -- 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
[rdiff-backup-users] Re: Some questions/problems about using rdiff-backup to a remote system
On Fri, May 09, 2008 at 02:38:16PM -0400, Sam Hart wrote: > On Fri, May 9, 2008 at 2:21 PM, Chris G <[EMAIL PROTECTED]> wrote: > > I am trying to use rdiff-backup to backup some files from my desktop > > Fedora 8 system to a remote Ubuntu server 7.10 system and have some > > questions regarding user(s) on the two systems. > > > > On my desktop system I want to run rdiff-backup as root because I'm > > backing up all of /home and thus files belong to many different users. > > However the remote system, being Ubuntu, doesn't have a root user. > > Will this cause any problems? > > Ubuntu does have a root user... it's jut not got a password set by > default. If you wind up running rdiff-backup as root to backup all of > /home, you will have to set it up so that it can authenticate across > the systems. One way of doing this would be using tools like ssh-agent > or ssh-copy-id (but be sure you know what you're doing here... > arbitrarily copying keys between servers is a sure way to make it easy > to compromise your entire network- If you're on a home/private network > that's sufficiently firewalled off, this may not be a concern to you). > Yes, OK, I can set up a root user on the Ubuntu system (in fact I just have). Whether it helps or not I'm not sure yet. > rdiff-backup across distros works fine, I do it all the time (even > across Unixes). The real problems with cross distro and cross Unix > rdiff-backups are: > > 1) You need to ensure the rdiff-backup tools installed on each system > are compatible with eachother. This basically means they need to be > the same version (unless this has changed recently and I didn't notice > :-) > I'm working on this, they don't match at the moment. H, that's a real pain! On Fedora the only version of rdiff-backup available seems to be the current stable version 1.0.5. On Ubuntu 7.10 its version 1.1.14, that leaves me in a quandary, I can build a newer version on Fedora but how do I get 1.1.14 as the current version is 1.1.15. I suppose I can build 1.1.15 on both but it's not very satisfactory. > 2) User IDs will very probably mis-match. You will have to decide for > yourself if this is a problem. In your example, it's very likely that > the user ownerships in /home on one machine (Fedora) will not match > users on the other machine (Ubuntu). > Some do, others simply don't exist on the backup machine. -- 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
[rdiff-backup-users] Some questions/problems about using rdiff-backup to a remote system
I am trying to use rdiff-backup to backup some files from my desktop Fedora 8 system to a remote Ubuntu server 7.10 system and have some questions regarding user(s) on the two systems. On my desktop system I want to run rdiff-backup as root because I'm backing up all of /home and thus files belong to many different users. However the remote system, being Ubuntu, doesn't have a root user. Will this cause any problems? -- 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
[rdiff-backup-users] Re: Can I make rdiff-backup follow symlinks?
On Wed, May 07, 2008 at 11:21:29AM +0100, Chris G wrote: > >> I want it to copy *everything* in /home/chris, including stuff pointed > >> to by symbolic links. Otherwise I'm left with a backup which can have > >> huge holes in it. > > > > And also hoping that no symbolic links will result in a circular > > loop, generate huge amounts of data :-) > > > rsync manages it. > Specifically the --copy-unsafe-links option in rsync does *exactly* what I would like rdiff-backup to be able to do. -- 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
[rdiff-backup-users] Re: Can I make rdiff-backup follow symlinks?
On Wed, May 07, 2008 at 12:07:16PM +0200, Paul Bijnens wrote: > On 2008-05-07 10:55, Chris G wrote: >> Is there an option in rdiff-backup to make it follow symbolic links? >> >> E.g. if I do something like:- >> >> rdiff-backup /home/chris /backup >> >> I want it to copy *everything* in /home/chris, including stuff pointed >> to by symbolic links. Otherwise I'm left with a backup which can have >> huge holes in it. >> > > And also hoping that no symbolic links will result in a circular > loop, generate huge amounts of data :-) > rsync manages it. > > Why not adding the targets of the links to the rdiff-backup include > list? Simple solution but avoiding major problems. > ... because next week I'll change one and the backup won't work again. -- 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
[rdiff-backup-users] Can I make rdiff-backup follow symlinks?
Is there an option in rdiff-backup to make it follow symbolic links? E.g. if I do something like:- rdiff-backup /home/chris /backup I want it to copy *everything* in /home/chris, including stuff pointed to by symbolic links. Otherwise I'm left with a backup which can have huge holes in it. -- 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
[rdiff-backup-users] Basic question about handling backups with symbolic links
I have just discovered that I'm not backing up as much as I thought I was, due to symbolic links. In particular I have some symbolic links in my home directory to areas on old disks which are 'my' files from earlier installations etc. A default rdiff-backup of my home directory just stores the symbolic link on the destination which, of course, is not a backup at all. Is there a simple option to rdiff-backup which will make it 'follow' symbolic links and store everything down my home directory tree as actual files and not as links to other places? -- 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
[rdiff-backup-users] Why doesn't this error ever go away?
I get this error every time I run rdiff-backup:- UpdateError Mail/In/inbox/new/1206493854.22988_0.th-shell-1 File changed from regular file before signature UpdateError Mail/In/inbox/new/1206498391.30151_0.th-shell-1 File changed from regular file before signature I assumed it originally occurred because a file changed while rdiff-backup was running but it would appear that once it has happened the error message never goes away. Is this a bug? Is there something I can do to clear the error so I won't get a mail about it every time rdiff-backup runs? -- 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
[rdiff-backup-users] Re: What do these errors indicate?
On Tue, Mar 25, 2008 at 11:05:35AM +0100, Andreas Olsson wrote: > Den Tuesday 25 March 2008 10.35.22 skrev Chris G: > > I'm getting these errors when I run rdiff-backup:- > > > > UpdateError tmp/filter.log Updated mirror temp file > > /rdiffBackup/gradwell/tmp/rdiff-backup.tmp.11059 does not match source > > UpdateError tmp/mail.log Updated mirror temp file > > /rdiffBackup/gradwell/tmp/rdiff-backup.tmp.11072 does not match source > > > > What do they mean exactly? > > http://wiki.rdiff-backup.org/wiki/index.php/UpdateErrorOne OK, thank you, an excellent explanation. I think it's rarely that this will happen in practice (the log files there changing while rdiff-backup is running), it's only some debug logging of a script that filters my personal incoming mail. I'm not fussed about the log files not being backed up either. -- 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
[rdiff-backup-users] What do these errors indicate?
I'm getting these errors when I run rdiff-backup:- UpdateError tmp/filter.log Updated mirror temp file /rdiffBackup/gradwell/tmp/rdiff-backup.tmp.11059 does not match source UpdateError tmp/mail.log Updated mirror temp file /rdiffBackup/gradwell/tmp/rdiff-backup.tmp.11072 does not match source What do they mean exactly? -- 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
[rdiff-backup-users] That "File changed from regular file before signature" error
I'm still trying to get rid of the following error:- UpdateError sofdev/cprg/utils/fred File changed from regular file before signature It's something in the *destination* causing the problem because I only get the error when doing the overnight 'refresh' of my rdiff-backup. If I do an rdiff-backup to a new destination directory I get no errors. The question is how can I get rid of the error without corrupting the destination? The file in question (fred) is unimportant but can anyone tell me how I can remove it (and all references to it) from the backup? -- 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
[rdiff-backup-users] What does this error from rdiff mean?
I am getting the following error every day from my rdiff-backup :- UpdateError sofdev/cprg/utils/fred File changed from regular file before signature What does it actually mean and how do I get it to go away? When I first got the error I deleted the file sofdev/cprg/utils/fred and I have just checked that it really isn't there any more but I'm still getting the error message every time I do a backup. -- 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
[rdiff-backup-users] Why doesn't this error go away?
I get the following error every day since it started a week or so ago:- UpdateError sofdev/cprg/utils/fred File changed from regular file before signature So why doesn't it clear itself up after happening once? I think it occurred because I deleted the file 'fred' (which was a very large, very sparse, test file) presumably while rdiff-backup was running. -- 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
[rdiff-backup-users] Destination doesn't support hard links, workaround?
I am trying to do some backups to a network disk but I get the following error:- Warning: hard linking not supported by filesystem at /freecom/backup/var/www/rdiff-backup-data Traceback (most recent call last): File "/usr/bin/rdiff-backup", line 23, in rdiff_backup.Main.Main(sys.argv[1:]) File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 285, in Main take_action(rps) File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 255, in take_action elif action == "backup": Backup(rps[0], rps[1]) File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 296, in Backup backup_set_fs_globals(rpin, rpout) File "/usr/lib64/python2.5/site-packages/rdiff_backup/Main.py", line 419, in backup_set_fs_globals 'destination', Globals.rbdir, 1, Globals.chars_to_quote) File "/usr/lib64/python2.5/site-packages/rdiff_backup/fs_abilities.py", line 416, in get_fsabilities_readwrite rb, use_ctq_file = use_ctq_file, override_chars_to_quote = ctq) File "/usr/lib64/python2.5/site-packages/rdiff_backup/fs_abilities.py", line 162, in init_readwrite if override_chars_to_quote is None: self.set_chars_to_quote(subdir) File "/usr/lib64/python2.5/site-packages/rdiff_backup/fs_abilities.py", line 274, in set_chars_to_quote if is_case_sensitive(): File "/usr/lib64/python2.5/site-packages/rdiff_backup/fs_abilities.py", line 245, in is_case_sensitive assert not upper_a.lstat() AssertionError The network disk is essentially a 'black box', i.e. I can't change what it does at all. -- 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
[rdiff-backup-users] Re: Will backing up an rdiff backup cause any problems?
On Thu, Oct 18, 2007 at 07:51:31AM +1000, Dave Kempe wrote: > Chris G wrote: >> Will doing an rdiff-backup of a file hierarchy created by rdiff-backup >> cause any problems? > > nope we do this all the time. > just make sure you rdiff-backup the parent directory of any rdiff-backup > repos. you may need to create an extra directory structure to make this > happen > OK, thank you, just what I needed to know. -- 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
[rdiff-backup-users] Will backing up an rdiff backup cause any problems?
I want to backup some files fairly frequently from one place to another on my system using rdiff-backup and at less frequent intervals copy the backup files off site to a remote system. Since the 'source' of the files I'm backing up is a Vmware guest system the files to be backed up won't always be there, so my strategy is to be:- A half-hourly (or something like that) cron job will run rdiff-backup to backup the files from the vmware guest to a local Linux file system on a different drive. I could maybe also try and do a copy when the vmware guest is started and when it's stopped (though the latter is more difficult). An overnight rdiff-backup of the Linux filesystem copy of the Linux copy of the files to a remote system. I can't run this directly from the vmware guest because that guest may not be running. Will doing an rdiff-backup of a file hierarchy created by rdiff-backup cause any problems? -- 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
