[rdiff-backup-users] rdiff-backup on Ubuntu stopped working, gave Errno 95

[Bill Harris]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've got two Ubuntu systems on which I had been using rdiff-backup
successfully for some time (perhaps 2+ months).  Sometime after December
13, my last successful backup, backups have consistently failed, as you
can see at
http://ubuntuforums.org/showthread.php?t=981340highlight=rdiff-backup
(see the response from me for the results I get to the terminal when I
run it).

While I'll be glad to share the simple script that created that error,
it simply calls rdiff-backup three times on different directories.  I
have been backing up another Linux box using an sshfs mount to this
computer using a simple script with two lines, one to run dpkg
- --get-selections and one to run rdiff-backup.

I'm running rdiff-backup 1.1.16 and Ubuntu Intrepid (2.6.27-9-generic).

Thoughts?  I've searched on the Web in general and on the Ubuntu Forums
and the rdiff-backup site to no avail.  It would really be nice to run a
backup again soon.

Bill
- -- 
Bill Harris  http://facilitatedsystems.com/weblog/
Facilitated Systems  Everett, WA 98208 USA
http://facilitatedsystems.com/  phone: +1 425 337-5541
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklMPDIACgkQ3J3HaQTDvd/5swCfTcgnTdm79g+W9lTCkFftm/JE
I5gAn2K0VIb7NHvnHoPmmR5Pktqm9Ahf
=Zmmp
-END PGP SIGNATURE-


___
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] rdiff-backup on Ubuntu stopped working, gave Errno 95

[Bill Harris]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Ferguson adfergu...@gmail.com writes:

 On Dec 19, 2008, at 7:28 PM, Bill Harris wrote:

 Based on your traceback, it looks like your sshfs setup is broken.
 Either sshfs has changed, or your kernel, or the server from which you
 are mounting the fs ...

Andrew,

In trying to be complete, I think I was confusing.  The traceback I gave
came from backing up the local system -- no sshfs involved.  I plug in
my external drive and run three rdiff-backup commands to backup three
different directories:

,[ script with comments removed ]
| #!/bin/bash
| sudo -b rdiff-backup /etc /media/Ext\ 
Drive/backups/rdiff-backup-moenchweiler-etc
| sudo -b rdiff-backup /usr/local /media/Ext\ 
Drive/backups/rdiff-backup-moenchweiler-usr-local
| dpkg --get-selections | grep -v deinstall  ~/.dpkg-query
| rdiff-backup --exclude /home/bill/Documents/one/long/path --exclude 
/home/bill/Documents/another/long/path -b /home/bill /media/Ext\ 
Drive/backups/rdiff-backup-moenchweiler-home-bill
`

It asks for my password and then gives the traceback I shared.

I also back up another system using this computer and this external
drive.  When I do that, I mount the other computer's drive with sshfs,
and that gives me the same error.  I was mentioning the sshfs mount
simply to say I get the same thing in two different cases, but the
primary case involves only the local mount of that external drive.

 The traceback says that rdiff-backup received Operation not
 supported (EOPNOTSUPP) when it tried to do:

 mkdir /media/Ext Drive/backups/rdiff-backup-moenchweiler-etc/rdiff- 
 backup-data/rdiff-backup.tmp.0

 if you can do that, as the user which rdiff-backup runs as, then there
 *could* be a bug in rdiff-backup, but based on what you have posted, I
 would say there is definitely a bug in sshfs or your setup. Given that
 it got an error while executing that simple command, I'm sure you
 agree that the problem is related to your sshfs setup. :-)

Well, not quite, since the main problem is on a system where sshfs isn't
used, but I agree that I probably confused the issue a bit. :-)

I tried running that command as me, and it failed:

,
| $ sudo mkdir /media/Ext\ 
Drive/backups/rdiff-backup-moenchweiler-etc/rdiff-backup-data/rdiff-backup.tmp.0
| [sudo] password for bill: 
| mkdir: cannot create directory `/media/Ext 
Drive/backups/rdiff-backup-moenchweiler-etc/rdiff-backup-data/rdiff-backup.tmp.0':
 Operation not supported
`

Needless to say, it also failed when I ran it as me.

Now I'm perplexed.  Permissions on the external drive seem to be 777 all
the way up to /media/Ext\ Drive.

As best as I can recall, I haven't changed the script (except for
testing purposes, and then I put it back the way it was) in a couple of
months, and it's worked every day or two over that time frame with no
complaints.  

Any clues?

 If you cannot determine where the bug is in this setup, I would
 recommend that you *not* use sshfs. Instead, you should install rdiff- 
 backup on the destination system, and then run the backup as `rdiff- 
 backup /my/files m...@other-host::/my/backup`. It is much more reliable,
 you will get better performance due to the rsync algorithm, and rdiff- 
 backup will intelligently avoid problematic filesystem issues.

Thanks; I'll try that if I need to.  However, I suspect my inability to
run mkdir on that directory with no sshfs involves means something -- I
just don't yet know what.  

Ideas?

Thanks for your quick response.

Bill
- -- 
Bill Harris  http://facilitatedsystems.com/weblog/
Facilitated Systems  Everett, WA 98208 USA
http://facilitatedsystems.com/  phone: +1 425 337-5541
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklMUZEACgkQ3J3HaQTDvd8wQgCfVJAdb6kaKg8/3ZeQUbB676Qh
aGEAn2v3yfj6CAxFLElWweQKu52Hxg4I
=HGvm
-END PGP SIGNATURE-


___
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] rdiff-backup on Ubuntu stopped working, gave Errno 95

[Bill Harris]

 complaints of
problems with current usage, so I'm guessing something got updated,
perhaps with fuse or ntfs-3g, that made this not work.  I'm guessing all
starting over means is that I lose whatever history I had.
- -- 
Bill Harris  http://facilitatedsystems.com/weblog/
Facilitated Systems  Everett, WA 98208 USA
http://facilitatedsystems.com/  phone: +1 425 337-5541
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklNKeUACgkQ3J3HaQTDvd9nbACfVYDc+sFPKUQrVkgiGfBCekaP
+/UAniJMCgpQBch9Ls848CQ0noZn3LHF
=r1MU
-END PGP SIGNATURE-


___
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] rdiff-backup on Ubuntu stopped working, gave Errno 95

[Bill Harris]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bill Harris bill_har...@facilitatedsystems.com writes:

 PS: If worse comes to worst, does it sound reasonable to find a new
 place on my external drive, perhaps on an ext3 partition this time, and
 to start over with rdiff-backup?  I'm not seeing massive complaints of
 problems with current usage, so I'm guessing something got updated,
 perhaps with fuse or ntfs-3g, that made this not work.  I'm guessing all
 starting over means is that I lose whatever history I had.

I circumvented the problem: I found a bit of space on an ext3 partition
and started over there, and rdiff-backup worked nicely, so I guess it
was an ntfs thing.  

I was going to copy the old files over, but they seemed to be owned by
root, at least at the top levels, and that made me suspicious.

If anyone knows how to make ntfs-3g write to filesystems in this case,
I'm listening, because I could want to recover data from old backups
sometime.  That said, I'm probably okay.

Bill
- -- 
Bill Harris  http://facilitatedsystems.com/weblog/
Facilitated Systems  Everett, WA 98208 USA
http://facilitatedsystems.com/  phone: +1 425 337-5541
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklNZlsACgkQ3J3HaQTDvd8aDwCdHmhOAmRNOyXhf2VpX6+Pjn0f
Sn0An0YSOz1cbMXNjp/QB+WQDpsA8xsH
=SGEc
-END PGP SIGNATURE-


___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

Re: [rdiff-backup-users] Re: rdiff-backup on Ubuntu stopped working, gave Errno 95

[Bill Harris]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Szabolcs Szakacsits sz...@ntfs-3g.org writes:

 You seem to use an old version of NTFS-3G (EOPNOTSUPP error 
 message) which didn't support yet all file type creation scenarios: 
 http://ntfs-3g.org/support.html#filecreate
 http://ntfs-3g.org/releases.html

Szaka,

Thanks for the pointer.  Yes, I'm running 1.2506, which is rather far
behind 1.5012, the version that fixes that problem, or the current
1.5130.  1.2506 is the current Ubuntu Intrepid version.  I see that
Jaunty will use 1.2531, and there are no backports for Intrepid.

If I hadn't gotten around the problem by moving to an ext3 partition, I
might see if I could build ntfs-3g.  As it is, I think I'll take the
easy way out and know that it will eventually get fixed (or is it rather
trivial to build ntfs-3g from source on Ubuntu?).

I wonder (rhetorical question) what could have changed to make it fail.

Thanks,

Bill
- -- 
Bill Harris  http://facilitatedsystems.com/weblog/
Facilitated Systems  Everett, WA 98208 USA
http://facilitatedsystems.com/  phone: +1 425 337-5541
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklOdxsACgkQ3J3HaQTDvd/LvQCdEUI6+lZklKoDnOIBgNKSSCIq
lRYAnjDzGjY+oO3zt8Iui/c/uTUuCkjw
=OM7I
-END PGP SIGNATURE-


___
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] Still maintained?

[Bill Harris]

I have routinely used rdiff-backup for years. I appreciate that it just
works. I appreciate that it stores the backup uncompressed so that I don't
have to have access to rdiff-backup to restore the data if worse comes to
worst.  I appreciate that you are working carefully on useful enhancements.

More list traffic is okay, but I appreciate both that I don't have to read
a lot to use this routinely and that it seems like there are plenty of
people here who can help if there are questions.  As a result, I'm also
okay if the list is relatively quiet.

Bill

On Wed, Feb 7, 2018 at 8:03 PM, Wes Cilldhaire  wrote:

> > Also wrote this: https://eugenemakerspace.com/
> wiki/Sites/Rdiff-backup-delete
> > would be nice if that functionality could be folded back in to
> Rdiff-backup.
> :-)
> >   Clif Cox
>
> Hi, sorry we haven't been able to give rdiff-backup the attention it
> deserves
> before now but we have been familiarizing ourselves with the open issues as
> well as the state of the inherited codebase and unreleased changes from the
> original repo before we start making new changes and deploying.  As I'm
> sure
> you can all understand it's something that should be done delicately - I'd
> hate to push a previously undeployed change without analyzing and testing
> it
> only to find it corrupts people's backups, or likewise not deploying a
> pending
> change people have been waiting for that fixes some critical issue.
>
> I just wanted to let you know that we have included the functionality from
> rdiff-backup-delete into the github repository as a python script already:
> https://github.com/sol1/rdiff-backup/blob/master/rdiff-
> backup/misc/rdiff-backup-delete.py
>
> There's more work to be done with it though - at the moment it's a pretty
> slow
> algorithm that operates on supplied filenames sequentially and there is
> plenty
> of opportunity to optimize it for better performance.
>
> Also, people are free to submit PR's if they have bug fixes or new features
> that they feel will benefit the rdiff-backup user community and we will
> consider all submissions.  At this stage, momentum is slow but building
> and we
> will address open issues in turn.  I've started to triage them internally
> so
> we can address some low hanging fruit that won't involve drastic code
> changes
> and hope to get some time to push these through soon.
>
> Thanks,
> Wes Cilldhaire
> Sol1
>
>
>
> ___
> rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
> Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.
> php/RdiffBackupWiki
>
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

[rdiff-backup-users] Forgetting to run as root: how to recover quickly

[Bill Harris]

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.

Thanks,

Bill
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

Re: [rdiff-backup-users] Future of rdiff-backup: Python 3 migration and project maintainership in general

[Bill Harris]

Hello, Otto.

I have used rdiff-backup for quite a few years, and I find it largely does
what I want.

I would like to see it updated and key issues fixed or improved.  While I
can't say that rdiff-backup is completely irreplaceable, I wouldn't want to
see it disappear, I do like many of its features, and I haven't seen a
solution I like better yet.

So I support in general what you and others have described here. I don't
feel qualified at this point to vote on who ought to be doing what on the
project. From the way you described them, I have no issues with your
credentials for doing this sort of thing.

Bill
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

Re: [rdiff-backup-users] Future of rdiff-backup: Python 3 migration and project maintainership in general

[Bill Harris]

As for an indicator of the popularity of rdiff-backup, does
https://qa.debian.org/popcon.php?package=rdiff-backup help?

I don't know how this compares to other packages, especially other backup
packages, I don't know how many Debian users use popcon, and I don't even
know the popularity of Debian compared to other distros (is this popcon
database limited to Debian?).  I'm guessing I first started using
rdiff-backup in the 2006-2008-ish time frame.

Thanks to those of you who have expressed interest in reinvigorating this
tool.

Bill

On Sat, Jul 27, 2019 at 6:57 AM Tobias Leupold 
wrote:

> Hi,
>
> I've been an rdiff-backup user for years now (I'm not so fit with Python,
> so I
> think this project is a bit above my skills when it comes to development
> ...),
> and I also use it in a productive enviroment. I really like it. It's
> exactly
> what I need. And I would really appreciate it not to be abandoned.
>
> It's very nice that apparently, some guys out there want to bring it back
> to
> life. Some years ago, Gentoo marked rdiff-backup for removal, but gladly,
> at
> least some development was done by some folks so that they finally kept it.
>
> Please do it! Please arrange on what fork and which commits to use, merge
> it
> into some reasonable code base and start over. What Eric wrote sounded
> reasonable tome. Additionally I I think a full-time Debian developer who
> wants
> to adopt rdiff-backup can't be the worst case, can it?! ;-)
>
> Thanks for putting effort in this nice project and make it going on!
>
> Cheers, Tobias
>
> Am Samstag, 27. Juli 2019, 08:37:15 CEST schrieb Eric L.:
> > Hello again (in the morning for me),
> >
> > in more length and with a fresh mind, and after having gone through all
> > thread answers, let me give a lengthy position:
> >
> > 0. I'm the EricZolf referenced elsewhere, who has a branch finished for
> > Linux with the migration to Python 3. I'll post a note after this e-mail
> > into the PR 40 to prove it.
> >
> > 1. it's great to see that there is still a community of users, I didn't
> > realise, else I'd have communicated earlier. I'm now on the mailing list
> > so all is good.
> >
> > 2. I started the migration effort because I didn't want to lose my
> > backup tool once Python 2 is out of support, else I'm an IT guy with
> > quite a lot of Ansible background (Python!), one wife, 2 children, a
> > consulting job and little time, but making the best out of it.
> >
> > 3. Initially, I didn't want to create my own definitive fork but wanted
> > to give sol1 a chance to become active and take their job as maintainer
> > seriously. As Otto noticed, I wasn't very successful till now. I would
> > have given them the Summer to react and then I'd have gone my own way,
> > without a clear idea how to create a community.
> >
> > 4. Knowing now that there is still such a community alive (thanks to
> > Otto!), I'd suggest following approach:
> >
> > a. I'll ping a last time sol1 and ask for their position.
> > b. In the meantime, review my PR, it's huge, no chance to merge anything
> > else before it's merged back into master.
> > c. I merge back into my master based on your feedback.
> > d. A last task is required before others can start and I would ask your
> > patience a last time: I want the whole code to be PEP8 conform before
> > others contribute to it, and I think (but open to discussion) that it's
> > best done if one person does it in one go.
> > e. Once this is done, I would second Patrick's suggestion and create an
> > rdiff-backup project, open it to the community and push my repository to
> > there for further common work (I wouldn't like to lose my repository
> > because I have 30+ issues I've created as I went through the code).
> >
> > A few more side notes:
> >
> > A. my PR isn't tested against Windows and Mac, feel free to test and
> > push fix PR against my branch on my repo and I'll merge (it should work,
> > never tried, else I'll merge manually). Please focus on regression bugs
> > that we get quickly this huge branch merged.
> > B. I'm fully with Patrick regarding CI/CD, if you know tox, you'll see
> > that I have a good start and one of my next moves would probably have
> > been to integrate tox with GitHub's pipeline.
> > C. This and anything else like web page, a mailing list we own, release
> > process, and pending issues, we can discuss together once we've agreed
> > on the big plan.
> >
> > Let the discussion roll, happy to be here, happy to hear there are
> > others who care about rdiff-backup, thanks to Otto for kicking this!
> > Eric
>
>
>
>
> ___
> rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
> Wiki URL:
> http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
___
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org

Long-time rdiff-backup user confused on new installation: permissions

[Bill Harris]

I've been using rdiff-backup for 10+ years.  I developed a simple bash
script that did what I wanted, and then I just ran it.  My OS is and has
been Debian Stable.

My script

   - checks to make sure I'm running as root (I forget why I did that 10+
   years ago)
   - for each of  4 rdiff-backup commands, it
  - prints a  header saying what is being backed up
  - backs up /etc, /usr/local (probably intended to capture a GNU MCSim
  custom installation;  I should be able to rebuild that. This may be the
  reason for running as root, too.)
  - runs dpkg to get a list of installed packages
  - backs up my  /home with three exceptions
  - backs up another /home from this machine
   - prints a closing comment

Two things happened this summer: my backup disk failed :-(, and I realized
that Debian 9 was becoming untenable, so I upgraded to Debian 11.

I just got a new WD Blue 4T SATA HDD  and installed it in a UGREEN
chassis.  I plugged the drive into a USB 3.0 port.  I then formatted the
disk with 2 ext4 partitions and created a backups directory in  the desired
partition.  I revised my script to point to the new directory.  I verified
I could write to it, I cleaned off any files I had written, and then I ran
my newly-modified script.

Here is my script, absent the #!/bin/bash, the check for EUID, and the echo
commands and with names obscured and generally shortened. I run it as root:

rdiff-backup /etc
/media/MyUserName/PartitionName/backups/rdiff-backup-MachineName-etc
rdiff-backup /usr/local
/media/MyUserName/PartitionName/backups/rdiff-backup-MachineName-usr-local
dpkg --get-selections | grep -v deinstall > ~/.dpkg-query
rdiff-backup --exclude /home/MyUserName/Documents/RemainingDirectoryPath1
--exclude /home/MyUserName/Documents/RemainingDirectoryPath2 --exclude
/home/MyUserName/Documents/RemainingDirectoryPath3 -b /home/MyUserName
/media/MyUserName/PartitionName/backups/rdiff-backup-MachineName-home-MyUserName
rdiff-backup -b /home/AnotherUserName
/media/MyUserName/PartitionName/backups/rdiff-backup-MachineName-home-AnotherUserName

In the process, I discovered that my old script had permission problems,
and I made some ad hoc and probably incorrect choices.   Here's what I see
now:

  /media/MyUserName/PartitionName:
  total used in directory 28 available 1.6 TiB
  drwxrwxrwx  4 MyUserName MyUserName   4096 Nov  5 20:18 .
  drwxr-x---+ 4 root   root 4096 Nov  5 20:07 ..
  drwxr-xr-x  6 MyUserName MyUserName   4096 Nov  6 10:02 backups
  drwx--  2 root   root16384 Nov  3 11:56 lost+found

  /media/MyUserName/PartitionName/backups:
  total used in directory 48 available 1.6 TiB
  drwxr-xr-x   6 MyUserName MyUserName   4096 Nov  6 10:02 .
  drwxrwxrwx   4 MyUserName MyUserName   4096 Nov  5 20:18
..
  drwxr-xr-x 148 root   root12288 Nov  5 19:11
rdiff-backup-MachineName-etc
  drwxr-xr-x 226 MyUserName MyUserName  20480 Nov  5 09:26
rdiff-backup-MachineName-home-MyUserName
  drwxr-xr-x  36 AnotherUserNameAnotherUserName  4096 Sep  1 14:25
rdiff-backup-MachineName-home-AnotherUserFirstName
  drwxr-xr-x  11 root   root 4096 Sep 25 12:07
rdiff-backup-MachineName-usr-local

I think rdiff-backup-MachineName-home-MyUserName started off as 700 and I
changed it to 755 to be able to see it more readily--or maybe it was
PartitionName as 700 and I changed it to 777?

What should I have for permissions?  Can I simply chmod these existing
directories or should I start over from the beginning?  Should I have to
run this script as root?  Is there a reason to avoid running it as root?  I
see the examples don't run with elevated permissions; perhaps that would be
better.

A quick random scan of those four directories gives what I would expect:
MyUserName is the owner and group of the top-level contents of one
directory, AnotherUserName is of the other directory, and root is for the
other two.  An even more cursory scan suggests permissions match between
the source and backup files.

Thanks,

Bill

PS: For a  really rough benchmark, creating that initial backup of ca. 66
GiB took about 14 hours. I hibernated it overnight, which I think should
subtract ca. 9-10 hours from the real time, giving an overall rate of ca.
13-17 GiB/hour real time.  user + sys was almost exactly 30 minutes.

-- 
Bill Harris

Re: Long-time rdiff-backup user confused on new installation: permissions

[Bill Harris]

All, thanks!

Nope, I wouldn't think of changing anything inside a backup repo.  Since it
seems to work with the right permissions and ownership in repos, my only
real question is whether the 777 on the owned-by-me partition and the 755
on the owned-by-me backups directory  would get me in trouble at some point.

I get the point about saving /home as its owner, but that would have
required me to figure out how to suid better and how to do it without
saving passwords in cleartext or asking for password entry at various
times.  This seems to work, and I haven't heard a showstopper objection yet.

Bill

On Mon, Nov 8, 2021 at 9:50 AM  wrote:

> Hi,
>
> basically the difference lies mainly in what you can read (as root
> everything) not so much in what is written, because, as Patrik wrote, the
> access rights are saved as metadata even if the user can't create the file
> as read.
> I would use a normal user to save their own home, root for everything
> else. And foremost I wouldn't change the approach once started! And not
> change the access rights directly in a backup repository.
>
> Hope this helps, Eric
>
> On 7 November 2021 16:35:41 CET, Patrik Dufresne 
> wrote:
> >To my knowledge permission and ownership may be reflected to the target
> >destination but extra care need to be taken care of to make it happen. Man
> >page explains most of it.
> >
> >Otherwise, Most of the time permission are not reflected to the target
> >destination and are simply stored in metadata. Then everything is owned by
> >the users running the script and 0700 for permissions.
> >
> >Running the script as root might help. But would need to look at man page
> >to make sure.
> >
> >On Sun., Nov. 7, 2021, 10:19 a.m. Bill Harris, <
> >bill_har...@facilitatedsystems.com> wrote:
> >
> >> Do the permissions and owners listed near the end seem reasonable?
> >>  Looking at it again this morning, I guess they do.
> >>
> >> I guess I need to run this script as root, because I'm backing up files
> >> from two different users.
> >>
> >> Bill
> >>
> >> On Sun, Nov 7, 2021 at 1:11 AM Dominic Raferd 
> >> wrote:
> >>
> >> > On 06/11/2021 18:45, Bill Harris wrote:
> >> > > I've been using rdiff-backup for 10+ years...
> >> > What is the problem?
> >> >
> >> >
> >>
>

Re: Long-time rdiff-backup user confused on new installation: permissions

[Bill Harris]

Do the permissions and owners listed near the end seem reasonable?
 Looking at it again this morning, I guess they do.

I guess I need to run this script as root, because I'm backing up files
from two different users.

Bill

On Sun, Nov 7, 2021 at 1:11 AM Dominic Raferd 
wrote:

> On 06/11/2021 18:45, Bill Harris wrote:
> > I've been using rdiff-backup for 10+ years...
> What is the problem?
>
>