Permissions causing full backups?

Link McGinnis link2 at cschristian.com
Wed May 3 21:43:53 GMT 2006


Matt,

> No, you had mounted an area on the Linux server as U:, which is to
> say /cygdrive/u, on the Windows machine, presumably using Samba.  You
> had rsync doing what appeared to be a local copy from one area of the
> local Cygwin filesystem to another: /cygdrive/c to /cygdrive/u.  The
> only network traffic was related to reads and writes on /cygdrive/u, and
> no additional processes were executed on the Linux server.
> 
> "Rsync over SSH" is used when you give a source or destination with a
> hostname and a single colon.  Rsync logs you in to the Linux server
> using SSH and executes another rsync process there.  The two rsync
> processes talk to each other over the SSH connection.  Rsync over SSH
> involves pipes between rsync and SSH, and the Cygwin implementation of
> those pipes was at one point buggy, causing rsync to hang.

I'm not trying to dispute this - I assure you I know enough only to cause
problems.  But, looking back at the script that I was using, I established
the rsync command with a "destination" variable of
"remote_location="link at 192.168.1.111:home/".  This supports your "one colon"
requirement for ssh.  Before I setup the ssh key, this command forced me to
supply a password.  Then, once the key was established (ssh-keygen -t rsa),
no password was needed.  I assume that this meant that ssh was getting
involved but I have not investigated logs or seen other evidence of it.

Deciding on a method...
My requirements for making this decision are:
1.  User's shouldn't even know their PC is being backed up.  These user's
(mostly product buyers) don't understand technology and don't want to (I
don't want them to either).  Their backups have to be automatically
scheduled through Window's "Scheduled Tasks" to run at night.  This means
the script that runs has to handle everything that a user may have needed to
provide (paths, passwords, etc).

2.  The backups could be placed either in the users' home directory as:
1.  	/home/link/bkup/daily.0
				/daily.1, etc.
Or in a centralized location as:
2.	/samba/bkups/link/daily.0
				/daily.1
I don't care either way.

Responses to "Cons" within...
> Global daemon:
> + Daemon rotates the backups automatically
	This is a big PRO.
> - No encryption
	ok since these PCs are all on a private network (crossed fingers).  
> - Port might be blocked by firewalls
	I can modify the firewall to allow port access.  
> + User's command line is simple (especially if the daemon listens on the
> privileged port 873, in which case the user can omit --port)
> - Has to be started and stopped
	On the server side?  Is the user responsible for this?  They don't
even log into this server (knowingly) so this could be a deal-breaker.
> +/- Daemon accounts are used and must be maintained separately from
> system ones
	Not a problem (as far as I can tell)
> + Only one daemon is needed
> +/- Centralized; backups most naturally kept in a single directory,
> configurably owned by individual system users or by a single user
	As in "/samba/bkups/<USER>/daily.0 ??? -> Good!
 
> Single-use personal daemons over SSH:
Is this "single-use daemon" running on the server?  And the user's PC starts
the rsync communication?

> + Daemon rotates the backups automatically
> + Encryption (SSH)
> + Uses well-known port 22
> + Requires no starting and stopping
> - User has to pass rsync "-e ssh"
	Can this be automated at the beginning of the backup?  
	Does it require user-intervention?

> - "rsyncd.conf" has to be in user's home directory on server _or_ user
> has to pass "--rsync-path 'cd <dir> && rsync'" where <dir> is the
> daemon's install directory
	OK if it can be added to the automated script...

> +/- Only system accounts are used
	This seems OK to me unless I don't understand the implications...
> - A separate daemon-and-rsnapshot setup is needed for each user, but you
> can write a script to create them quickly
	That is OK

> +/- Each user owns his/her own setup and backups, but you can still keep
> all backups in a single directory and/or provide centralized
> configuration files
> 


> Plain rsync over SSH:
> - User must rotate backups by passing rsync
> "--rsync-path ./rsync-and-kick-rsnapshot" _or_ running "ssh
> backupmachine kick-rsnapshot" after each successful transfer
	This sounds like a deal-breaker.  Can it be part of the script?
> + Encryption (SSH)
> + Uses well-known port 22
> + Requires no starting and stopping
> +/- Only system accounts are used

This seems to be the simplest setup but may require user-intervention.  Or
can this also be included in the automated script?

I'm sorry I haven't been able to stay with this continually, but I wear a
lot of hats.  I hope this time is productive for you and that others will
benefit from this discussion and setup.  I'm documenting every forward
progress and can provide that when the project is completed.

Thanks again for all of your help.  

Link McGinnis


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.5.2/329 - Release Date: 5/2/2006
 



More information about the rsync mailing list