On Wed, 1 Aug 2018 at 17:31, Bill Harris <bill_har...@facilitatedsystems.com> wrote:
> On Tue, Jul 31, 2018 at 10:30 AM Dominic Raferd <domi...@timedicer.co.uk> > wrote: > >> On Tue, 31 Jul 2018 at 16:53, Bill Harris <wsharri...@gmail.com> wrote: >> >> > I've used rdiff-backup for years, and I'm mostly very happy with it. >> There >> > is one problem that crops up occasionally; and I haven't found a way >> around >> > it yet. >> > >> > AFAICT, rdiff-backup likes running as root. On rare occasion, I forget >> and >> > start it as myself. rdiff-backup complains, and, as I recall, offers to >> > sudo itself (I'm running Debian Stable, which is not normally set up as >> a >> > sudo system). >> > >> > If I enter a password (and perhaps even if I don't) and then hit Ctrl-c >> > because I realize I messed up, I get the "it appears the last backup >> > failed" message, and then I'm in for a long (about a day), full backup >> > instead of the usual 15-45 minute incremental backup. >> > >> > Is there a way to recover in such a situation so that I don't have to >> wait >> > for such a long backup to complete? I presume rdiff-backup won't react >> > well to my changing files during the backup. >> > >> > Is there a secure way to keep this from happening? I could learn how >> > setuid works, but I think that's an insecure approach. >> > >> >> Unless you are backing up system files, rdiff-backup doesn't have to run >> as >> root, but in my experience it is wise always to run it as the same user >> for >> a given repository. For instance I think if you run a backup as root once, >> then any subsequent run as another user to or from the same repository may >> hit problems - because the user may be denied the necessary access to >> certain rdiff-backup control files (in the rdiff-backup-data >> subdirectory). >> >> The delay must be because after you break a backup run, rdiff-backup has >> to >> regress the backup to a consistent state. For it to take a day to do so >> suggests you have a very large backup dataset and/or a very slow computer. >> If possible, can you break down the dataset into smaller components, then >> if you make the same mistake again, the regression will be much quicker? I >> realise this means starting a load of new backup repositories (which TBH >> is >> why I haven't done it in one case where I have an unwieldy repository). >> > > Thanks, Dominic. I didn't realize it could run as me; I do backup a few files from, I think, /etc perhaps another system directory, so that's why I got in that mode. > >My repo doesn't seem that huge; my entire /home is about 60 GiB. Perhaps I should check the speed of the drive I've got; it may be a 5400 RPM. I should perhaps profile rdiff-backup's operation, at least informally. > >What I hear you say is that a) there's no faster way to recover quickly if I abort or if I try to run as the wrong user. Is it possible for rdiff-backup to detect and respond better to selecting the wrong user? It asks me for a > >password as if it's a sudo system, but I think it fails after I enter the password. Perhaps I always hit Ctrl-c and cause the failure myself, but I thought I had gotten the "regressing" message even without pressing Ctrl-C. Ed's idea of changing the permissions on rdiff-backup so that it can only be executed by root seems a pretty neat fix to prevent you accidentally trying to run as someone else. Something like: sudo chown root:root /usr/bin/rdiff-backup sudo chmod 744 /usr/bin/rdiff-backup _______________________________________________ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki