Backing up the backup server

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Backing up the backup server

Brian C-2
Hi,

I have a backup server running OpenSUSE, call it 'backup-server' and a
dns server running Debian, call it 'dns-server'. They are on the same
subnet. Last night I got rdiff-backup 1.0.4 installed on both so that
backup-server backs up dns-server via a cron job, basically following
the instructions at http://www.howtoforge.com/linux_rdiff_backup.

However, I cannot similarly get backup-server to backup itself via the
backup user's cron job. Instead I have to let root run the cron job.
Every time the backup user runs rdiff-backup it requests a password
rather than running without requiring interaction.

Question 1: For a purely local backup such as this, is there any reason
(security concerns, for instance) to prefer that it not run as root, and
instead to have it run as the backup user?

If the answer to question 1 is yes, then:

Question 2: Why does rdiff-backup keep asking me for a password, instead
of working without interaction as it does when it backs up dns-server?
What are the things I should check?

I already looked at /home/backup/.ssh/config and
/root/.ssh/authorized_keys and /etc/ssh/sshd_config and everything looks
just as good as it did for the server that works.

I also tried the sudoers method described here:
http://www.arctic.org/~dean/rdiff-backup/unattended.html

and I also get asked for a password by sudo! Aack!?!

Thanks for any help.

Brian


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Backing up the backup server

finnarne
Brian C wrote:

> Hi,
>
> I have a backup server running OpenSUSE, call it 'backup-server' and a
> dns server running Debian, call it 'dns-server'. They are on the same
> subnet. Last night I got rdiff-backup 1.0.4 installed on both so that
> backup-server backs up dns-server via a cron job, basically following
> the instructions at http://www.howtoforge.com/linux_rdiff_backup.
>
> However, I cannot similarly get backup-server to backup itself via the
> backup user's cron job. Instead I have to let root run the cron job.
> Every time the backup user runs rdiff-backup it requests a password
> rather than running without requiring interaction.

What is the command-line you are using ?

> Question 1: For a purely local backup such as this, is there any reason
> (security concerns, for instance) to prefer that it not run as root, and
> instead to have it run as the backup user?
>
> If the answer to question 1 is yes, then:
>
> Question 2: Why does rdiff-backup keep asking me for a password, instead
> of working without interaction as it does when it backs up dns-server?
> What are the things I should check?

I guess we need to see you command line.

when using localhost for backup, you dont need to specify a
hostname-part of the destination

>
> I already looked at /home/backup/.ssh/config and
> /root/.ssh/authorized_keys and /etc/ssh/sshd_config and everything looks
> just as good as it did for the server that works.

No need to use keys to authenticate for a localhost, as ssh should not
be used ( but it should work)

> I also tried the sudoers method described here:
> http://www.arctic.org/~dean/rdiff-backup/unattended.html
>
> and I also get asked for a password by sudo! Aack!?!

That depends on the sudo-rights.

--
Finn-Arne Johansen
[hidden email] http://bzz.no/
Debian-edu developer and Solution provider
EE2A71C6403A3D191FCDC043006F1215062E6642 062E6642



_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Backing up the backup server

Keith Edmunds
In reply to this post by Brian C-2
> Question 1: For a purely local backup such as this, is there any reason
> (security concerns, for instance) to prefer that it not run as root, and
> instead to have it run as the backup user?

The requirement is only that the backup user has read access to all data
files, and execute access to all directories. In many cases this does
mandate the use of root, but you may judge that not to be the case here.

> Question 2: Why does rdiff-backup keep asking me for a password, instead
> of working without interaction as it does when it backs up dns-server?
> What are the things I should check?

rdiff-backup uses ssh, and if ssh requires a password then so will
rdiff-backup. The solution is passphraseless keys, which it sounds as if
you have setup. In my (reasonably extensive) experience, the problem is
95% certain to be on the system which is receiving the login rather than
the system which is doing the logging in (hope that makes sense). As
you're backing up on the same system, you could just specify a local
directory on the rdiff-backup command line rather than a network
connection (a network connection has a double colon in the command).
Things to check if an ssh connection seems to insist on a password
despite setting up keys (check these things on the server which you are
try to log into):

- is the account enabled? 'passwd -S username' should _not_ show a "L"
in the status field

- make sure that the ~/.ssh directory is owned by the account concerned
and that is it not group or world writable. For choice, chmod 600.

- make sure ~/.ssh/authorized_keys is owned by the account concerned and
is not group or world writable

- if all else fails, set 'LogLevel' to 'DEBUG' in /etc/ssh/sshd_config,
restart the sshd daemon and post the results of a failed login from
/var/log/auth (or maybe 'syslog', depending on your setup).

HTH,
Keith

--
Keith Edmunds

+---------------------------------------------------------------------+
|  Tiger Computing Ltd  |  Helping businesses make the most of Linux  |
|  "The Linux Company"  |       http://www.tiger-computing.co.uk      |
+---------------------------------------------------------------------+


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Backing up the backup server

Maarten Bezemer
In reply to this post by Brian C-2
Hi,

If you need the backup to have correct ownership of the files,
rdiff-backup needs to run as root at the backup side. For most
installations I know, this is not the case.
At the backed-up side however, rdiff-backup usually needs to run as root
to have access to all files in the backed-up tree.

For local backup, you could also use the TCP/IP loopback to split backup
and backup-up userid's.

Regarding your second question:
- Does it work when you run `ssh root@backup-server' when logged in as the
  backup user? If not, maybe /root/.ssh has wrong permissions?
- Do you use the same rsa/dsa key for both backup-server and
  dns-server? If not, maybe the private or public keys are mixed up?


Regards,
 Maarten


On Thu, 19 Jan 2006, Brian C wrote:

> Hi,
>
> I have a backup server running OpenSUSE, call it 'backup-server' and a
> dns server running Debian, call it 'dns-server'. They are on the same
> subnet. Last night I got rdiff-backup 1.0.4 installed on both so that
> backup-server backs up dns-server via a cron job, basically following
> the instructions at http://www.howtoforge.com/linux_rdiff_backup.
>
> However, I cannot similarly get backup-server to backup itself via the
> backup user's cron job. Instead I have to let root run the cron job.
> Every time the backup user runs rdiff-backup it requests a password
> rather than running without requiring interaction.
>
> Question 1: For a purely local backup such as this, is there any reason
> (security concerns, for instance) to prefer that it not run as root, and
> instead to have it run as the backup user?
>
> If the answer to question 1 is yes, then:
>
> Question 2: Why does rdiff-backup keep asking me for a password, instead
> of working without interaction as it does when it backs up dns-server?
> What are the things I should check?
>
> I already looked at /home/backup/.ssh/config and
> /root/.ssh/authorized_keys and /etc/ssh/sshd_config and everything looks
> just as good as it did for the server that works.
>
> I also tried the sudoers method described here:
> http://www.arctic.org/~dean/rdiff-backup/unattended.html
>
> and I also get asked for a password by sudo! Aack!?!
>
> Thanks for any help.
>
> Brian
>
>
> _______________________________________________
> rdiff-backup-users mailing list at [hidden email]
> http://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 [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Backing up the backup server [SOLVED]

Brian C-2
In reply to this post by Keith Edmunds
Thanks Keith!

Keith Edmunds wrote:
[snip]
> - if all else fails, set 'LogLevel' to 'DEBUG' in /etc/ssh/sshd_config,
> restart the sshd daemon and post the results of a failed login from
> /var/log/auth (or maybe 'syslog', depending on your setup).

This idea showed the problem. Even though when contacting the remote
server I needed the "from" portion of /root/.ssh/authorized_keys to be
the bizarre result of dig -x my.ip.add.res (which comes back as
node-########.sfo.onnet.us.uu.net which I presume is what my DSL
provider calls my static IP despite it resolving via DNS to something
totally different) when connecting locally the "from" portion needed to
be my regular hostname.domainname.tld.

I can now accomplish unattended backups via the backup user for both
remote servers and the backup server itself. Thanks to everyone for
their help and to the developers for this great software!

Brian


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Backing up the backup server [SOLVED]

dean gaudet-4
On Thu, 19 Jan 2006, Brian C wrote:

> Thanks Keith!
>
> Keith Edmunds wrote:
> [snip]
> > - if all else fails, set 'LogLevel' to 'DEBUG' in /etc/ssh/sshd_config,
> > restart the sshd daemon and post the results of a failed login from
> > /var/log/auth (or maybe 'syslog', depending on your setup).
>
> This idea showed the problem. Even though when contacting the remote server I
> needed the "from" portion of /root/.ssh/authorized_keys to be the bizarre
> result of dig -x my.ip.add.res (which comes back as
> node-########.sfo.onnet.us.uu.net which I presume is what my DSL provider
> calls my static IP despite it resolving via DNS to something totally
> different) when connecting locally the "from" portion needed to be my regular
> hostname.domainname.tld.

this is because you probably have an entry for your local address in
/etc/hosts which overrides the dns... in my docs i actually recommend just
using localhost when backing up the localhost...

as for the sudo problems you had you should make sure that you got the
exact same command line in /etc/sudoers as you specify as the fake
hostname for rdiff-backup... if you have any difference at all sudo
silently fails by asking you for your password and logging an error (check
your /var/log/secure or /var/log/auth or something depending on your
setup).

if the command is identical then maybe look at whether your sudo somehow
has NOPASSWD disabled... there's probably some way to increase sudo
logging verbosity as well.

fwiw sudo is higher performance for localhost because it avoids
encryption.

-dean


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

backup error due to different versions of rdiff-backup

Dr. Scott S. Jones
I am experiencing a strange backup problem, as described below:

scott@fyrenice:~$ rdiff-backup --test-server
[hidden email]::/usr/archive/ [hidden email]::/home/scott/rdb
Password:
Warning: Local version 1.1.5 does not match remote version 0.13.4.
Testing server started by:  ssh -C [hidden email] rdiff-backup --server
Server OK
Testing server started by:  ssh -C [hidden email] rdiff-backup --server
Server may work, but there is a version mismatch:
Local version: 1.1.5
Remote version: 0.13.4

In general, an attempt is made to guarantee compatibility only between
different minor versions of the same stable series.  For instance, you
should expect 0.12.4 and 0.12.7 to be compatible, but not 0.12.7
and 0.13.3, nor 0.13.2 and 0.13.4.

My questions:

How do I get both to be the same versions? I run Debian 3.1 on both machines
and keep things updated with apt-get update/upgrade.

Scott



_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: backup error due to different versions of rdiff-backup

dean gaudet-4
On Fri, 20 Jan 2006, Dr. Scott S. Jones wrote:

> How do I get both to be the same versions? I run Debian 3.1 on both machines
> and keep things updated with apt-get update/upgrade.

i'm guessing one of your boxes is stable and the other unstable...
unstable has 1.1.5 in it now... and the stable tree probably froze before
1.0.x release so it has 0.13.x in it.

anyhow you want to set up one or the other box so that it can cherry-pick
from the other release...  i'll just assume here you want to set up the
stable box so it can cherry-pick packages from unstable.

add this to /etc/apt/apt.conf:

APT::Default-Release "stable";

add this to /etc/apt/sources.list:

deb http://http.us.debian.org/debian unstable main non-free contrib

then "apt-get update" ... now you have access to the unstable versions of
all the packages in addition to the stable versions... but apt won't
choose the unstable package ever unless you ask for it specifically (or
somehow a stable dependency exists for a package which doesn't exist in
stable but does in unstable...)

anyhow do this:  apt-get install rdiff-backup=1.1.5-1

that'll try to install the 1.1.5-1 package... hopefully it won't haul in a
lot of unstable packages to support dependencies... if it does then you
want to give up and rebuild it yourself... or rearrange all the above
instructions so your unstable box can cherry-pick the 0.13.4 release from
stable.

-dean


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: backup error due to different versions of rdiff-backup

Wolfgang Dautermann
In reply to this post by Dr. Scott S. Jones
Dr. Scott S. Jones wrote:
> In general, an attempt is made to guarantee compatibility only between
> different minor versions of the same stable series.

Bye the way: What about upgrades on the server-side? E.g. I am running
currently 1.0.0, but there are newer versions (1.0.4, 1.1.5) - can one
expect that one can re-use the existing backups? Or should one 'backup
the backups' and start with an empty directory for new backups?

And I have some additional feature-requests:

(1) As far as I saw, there is no 'ls'-Feature, e.g.
rdiff-backup --ls-at-time 2006-01-19 /backups/daute
should output something like "ls -la /backups/daute" at a previous time.

(2) rdiff-Backup should be able to parse the date-formats from the own
output. E.g. rdiff-backup --list-increment-sizes outputs something like
"Sun Jan 22 00:05:04 2006     4.08 GB     4.08 GB   (current mirror)", then
rdiff-backup --list-at-time "Sun Jan 22 00:05:04 2006" /path/to/backup
should work...

Bye. Wolfgang

--
FH JOANNEUM / Fahrzeugtechnik
Automotive Engineering & Railway Engineering
Austria, 8010 Graz, Alte Poststrasse 149, Tel: ++43/(0)316/5453-8418
http://www.fh-joanneum.at/fzt/


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: backup error due to different versions of rdiff-backup

Ben Escoto
>>>>> Wolfgang Dautermann <[hidden email]>
>>>>> wrote the following on Sun, 22 Jan 2006 17:13:54 +0100
> Dr. Scott S. Jones wrote:
> > In general, an attempt is made to guarantee compatibility only between
> > different minor versions of the same stable series.
>
> Bye the way: What about upgrades on the server-side? E.g. I am running
> currently 1.0.0, but there are newer versions (1.0.4, 1.1.5) - can one
> expect that one can re-use the existing backups? Or should one 'backup
> the backups' and start with an empty directory for new backups?

Old repositories are always forwards compatible---you (should) never
need to erase your backup directory because you want to use a new
version.

> And I have some additional feature-requests:
>
> (1) As far as I saw, there is no 'ls'-Feature, e.g.
> rdiff-backup --ls-at-time 2006-01-19 /backups/daute
> should output something like "ls -la /backups/daute" at a previous time.

Yes, good point.  I wonder if I add this though, then someone will
want various sorting options, someone will think -la displays too much
information, etc.  Personally I'm happy with -la output.  Can anyone
think of a better display/format, or of a more flexible way to do
this?

> (2) rdiff-Backup should be able to parse the date-formats from the own
> output. E.g. rdiff-backup --list-increment-sizes outputs something like
> "Sun Jan 22 00:05:04 2006     4.08 GB     4.08 GB   (current mirror)", then
> rdiff-backup --list-at-time "Sun Jan 22 00:05:04 2006" /path/to/backup
> should work...

Ok, patch at

http://cvs.savannah.nongnu.org/viewcvs/rdiff-backup/rdiff_backup/Time.py?root=rdiff-backup&r1=1.12&r2=1.13&makepatch=1&diff_format=u


--
Ben Escoto

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backup error due to different versions of rdiff-backup

Wolfgang Dautermann
Ben Escoto wrote:
> Yes, good point.  I wonder if I add this though, then someone will
> want various sorting options, someone will think -la displays too much
> information, etc.  Personally I'm happy with -la output.  Can anyone
> think of a better display/format, or of a more flexible way to do
> this?

Too much information should not be a problem, one can easy remove
unneeded information (for example with some shell tools (grep, sed,
...). various sorting options might also be done by external programs.

I see two main uses for such a feature:

- enable the user to check, when a (modified, accidently removed) file
or directory was still there. For that, especially the timestamp and the
size of a file is important, a "ls -la" like output is probably exactly
that, what a user wants...

- simplify the programming of tools like web based restore utilities,
GUIs, ... For such tools one should provide as much as information as
possible, a program can always ignore unneeded information.

>>(2) rdiff-Backup should be able to parse the date-formats from the own
>>output.
> Ok, patch at
>
> http://cvs.savannah.nongnu.org/viewcvs/rdiff-backup/rdiff_backup/Time.py?root=rdiff-backup&r1=1.12&r2=1.13&makepatch=1&diff_format=u

Thanks.

Bye, Wolfgang

--
FH JOANNEUM / Fahrzeugtechnik
Automotive Engineering & Railway Engineering
Austria, 8010 Graz, Alte Poststrasse 149, Tel: ++43/(0)316/5453-8418
http://www.fh-joanneum.at/fzt/


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki