Call it Disaster/Recovery and then the database or application backup will find its place in the bigger picture.
When it comes to databases or applications, it is always a good idea to do a backup of the database or the application files using internal tools (e.g. dump command) before doing a backup at the operating system level such as volume snapshot. This way your databases remain consistent, otherwise whatever transactions not committed to disk are lost and the databases or application structures risk corrupting their integrity. For business continuity in case of unfortunate events, replication is always preferable as first line of defence to a restore from a previous clean backup - less time and work lost. If tuned and configured correctly, the replication mechanism (where available) should have little or no impact on production performance. HTH Adrian On Fri, 2010-03-12 at 18:19 +1300, Jim Cheetham wrote: > On Fri, Mar 12, 2010 at 1:34 PM, Steve Holdoway <[email protected]> > wrote: > > I wouldn't do that with the backups personally. If you're after backing > > up important production databases, then I'd look at replicating them > > ( to another machine preferably ) as a frist line of defence. > > Replication gives you defence from hardware failure, the same way that > RAID does. But it has nothing whatsoever to do with being a "backup" > in the data sense. Except ... > > > whilst over there, cold backups have no effect on live systems > > performance... > > The only effect that they have is to push back on your replication > system :-) As long as the primary doesn't get excess load while > waiting for the replicant to come back up, you're in business. > > > and no matter how cumbersome they are, I reckon they > > should always be a part of your backup strategy (: > > Sure, but effectively that's what a snapshot is; if a full cold backup > takes say 1 hour, with LVM snapshotting you can reduce that to a > couple of seconds. Surely that's worth investigating? If you can grab > a snapshot that quickly (it'll still take an hour to actually back up > from there, but the DB doesn't have to know), and your production > system can handle being read-only for a second or so, you can dispense > with the need for a replicant in the first place. > > -jim
