[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [cobalt-users] SSH connection slow after restore



> >
> > The only thing I have on my list of 'wonder why that is', 
> is now when 
> > connecting using SSH it takes several minutes for prompt to appear, 
> > like 10 or 15 minutes. Does anyone know where I can look to 
> see what 
> > may be causing this after the restore of /etc, /home, 
> /usr/local? The 
> > connection speed was fine before the restore.
> >
> You maybe want to give some instructions on how you did all 
> the following. I think what you did could be of benefit for 
> others on the list including myself.
>

Sure, right now it is just a shell script that uses rsync over SSH to
transfer the data from the Cobalt RaQ4r to a RedHat 7.3 server off-site
here at my house. That part is working great with the exception of a
PostgreSQL version problem I am working out with the Pg guys on that
mailing list. It is really that simple, all you need to do is establish
your SSH login to not need a password using authorized_keys and then use
a command similar to this (from the backup server, can be done in either
direction):

  rsync -aze ssh --delete --force --recursive --stats --perms
user@xxxxxxxxxx:/path/to/synchronize /local/path/to/backup
1>>/path/to/logs/output-config.log 2>/path/to/logs/errors-config.log

This will delete anything not on the source, force the deletions,
recursive into directories, print stats and maintain file permissions. I
have added logging to files for output and errors.

Right now, there are just a series of these commands in a shell script
for each path I want to backup (/etc, /home and /usr/local). Once I work
out the PostgreSQL dumping issue and test everything to perfection, I
will place it all in a Perl script where I know better how to loop, etc.
and get rid of some redundant commands. I'll also build backup versions
into the Perl script by date.

As far as the RaQ4r to restore to, you just alter the paths to
synchronize the backed up files right into place (no tar needed, etc.):

  rsync -aze ssh --recursive --stats --perms /local/path/to/backup
user@xxxxxxxxxxxxxxx:/path/to/synchronize
1>>/path/to/logs/output-config.log 2>/path/to/logs/errors-config.log

You would need to read up on rsync and ssh to establish the automated
backups without prompting for a password
(http://rsync.samba.org/fom-serve/cache/12.html). I'll be happy to share
once this is done, but you'll still need to establish that authorization
over SSH if you want to run it unattended in a cron job like I'm doing.
The restore works fine and all comes right up. The PostgreSQL issue is
about the different versions of psql I have on the RaQ versus the RedHat
7.3 with PostgreSQL 7.3.3. The RaQ has 7.0.2 and the dump from 7.3.3 is
running on the 7.0.2 properly. I know that I could use the dump utility
on the RaQ, but I am trying to get all the commands for backup off the
backup server where I backup many server from their location to here. I
also have plans to add the mysqldump.

> But as for you question take a look at your reverse dns 
> record for your host you are connecting to.  Make sure they match.
> 

Yours and Andreas' tips got rid of this problem. After the restore, the
RaQ was using the same DNS servers as the RaQ I backed up and there was
no gateway. This test restoration RaQ I'm using is behind a firewall, I
just entered the DNS for my LAN and the gateway, everything is
responding quickly now.

--
Robert