[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Wed, 6 Dec 2017 18:51:24 +0000
mr meowski <mr.meowski@xxxxxxxx> wrote:
> My money is on your system having changed some permissions or group
> info locally which is why your unchanged script has only just started
> throwing errors. Sometimes package updates change umasks on
> directories to unexpected values for example. Run rsnyc with extra
> verbosity and log to a file, grep out the troublesome permissions and
> then either investigate and fix them or lazily dump them to the
> excludes list and call it a day.
Thanks for the tips, I'll certainly include them in the plan of attack!
My problem with this rsync script is that it is not backing up 'a'
system, but a four-way dialogue between 5 users on 7 machines at 4
different locations and 11 different backup operations (some of the
machines act as internal backups for the others). So what was issued by
the backup script as a simple
rsync -azcP --delete -e ssh
is locked down in the rsa key as
"rsync --server --sender
-vvlogDtprcze.iLsfx . /home/user1/Desktop/"
and even increasing verbosity by a single -v will cause the
remote host to reject the login. This is compounded by the need to
strip the UID from the files when backing up to my machine so that I
can scp 'lost' files to any of the users on any of the machines without
changing its permissions. Nightmare. It took me two days just to get
those rsa keys into shape. I assumed that I had broken the rsync
command structures in the keys for the machines whose backup operations
were failing, and I'm rather tempted by the idea of rogue umasks, but
my experience tells me that it is usually me wot dun it.
But yes, thanks again for the tips.
Best wishes
fraser
--
The Mailing List for the Devon & Cornwall LUG
https://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq