From owner-freebsd-questions@FreeBSD.ORG Wed May 27 23:19:23 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4973106564A for ; Wed, 27 May 2009 23:19:23 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.ORG [206.117.18.8]) by mx1.freebsd.org (Postfix) with ESMTP id 99CDA8FC20 for ; Wed, 27 May 2009 23:19:21 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from [10.0.1.4] (pool-71-109-162-173.lsanca.dsl-w.verizon.net [71.109.162.173]) (authenticated bits=0) by zoom.lafn.org (8.14.3/8.14.2) with ESMTP id n4RN0PiQ017016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 May 2009 16:00:25 -0700 (PDT) (envelope-from bc979@lafn.org) Message-Id: <6E1B947C-F0D6-4458-BAED-5932BB168183@lafn.org> From: Doug Hardie To: prad In-Reply-To: <20090527150330.448cdd7a@gom> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 27 May 2009 16:00:24 -0700 References: <20090527150330.448cdd7a@gom> X-Mailer: Apple Mail (2.935.3) X-Virus-Scanned: clamav-milter 0.95.1 at zoom.lafn.org X-Virus-Status: Clean Cc: freebsd-questions Subject: Re: rsync approach X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 23:19:24 -0000 On 27 May 2009, at 15:03, prad wrote: > we have 2 static ip addresses with a machine running 7.2 connected to > each. > > one is the primary server, while the other does only dns and receives > bkp dumps from the first. > > we want to set things up so the 2nd can be brought on line at a > moment's > notice. > > therefore, we are thinking of rsync to duplicate 1st > 2nd (with the > exception of rc.conf and a few other files of course because we don't > want them to be absolutely identical). > > we plan to allow root login and have disabled all password access so > that rsync can preserve permissions. > > is this a good way to accomplish the bkp job? It might be, but its difficult to say without knowing a lot more about what going on in the system. For example, rsync of large files that change real often can be an issue. You may get an inconsistent copy of the file if it is changing during the update of that file. Rsync does one file at a time. Hence if you have multiple files that need to be consistent between them it might not happen. If transactions changing a file occur between the rsync of the first file and the rsync of the second file, they will not be consistent. I use rsync for basically the same thing you are considering. However, in my situation, the real dynamic files are database files. I don't rsync them. Those are exported every evening and those files are rsync'd. During the day, every application that updates a database file also adds a copy of the new record to the end of a log file. That log file is also rsync'd about every 5 minutes. In this way I can recover to within 5 minutes quite easily. The last 5 minutes might be a bit more work, but the information would be available from the original sources at that point. Allowing root login is generally not a great approach. Rsync will retain permissions (use -p) if the user id's and group ids are the same on both systems. You may have to modify some of the pam files to permit rsync to function easily. The easy test is to rsh date If that works and you get the date, then rsync will function properly. If not you need to track down why in the various log files. I had to make the following change: pam.d/rsh: -auth required pam_rhosts.so no_warn +auth required pam_rhosts.so no_warn allow_root This was first done quite a few years ago and has been propagated to the current systems so I don't know if its still required or not. Our systems only have 3 users (the administrators) so we have passwords working fine. It has not interfered with rsync.