Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Aug 2009 17:41:30 +0200
From:      Erik Norgaard <norgaard@locolomo.org>
To:        John Almberg <jalmberg@identry.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: What should be backed up?
Message-ID:  <4A92B4AA.3070605@locolomo.org>
In-Reply-To: <559375B5-3DCB-42E0-B233-B0916C6FBD9C@identry.com>
References:  <9F9B85A9-CC10-4793-B38D-4F1E1929BAF6@identry.com>	<5A8F63C4-7244-410A-B115-9681709855B5@goldmark.org>	<4A8FF981.7020707@locolomo.org> <559375B5-3DCB-42E0-B233-B0916C6FBD9C@identry.com>

next in thread | previous in thread | raw e-mail | index | archive | help
John Almberg wrote:
>> If you have any databases or ldap service, then you want to add  
>> those as well, but it is recommended to dump these rather than  
>> backup the files themselves.
> 
> I'm learning a lot from this thread. Thanks for all the suggestions.
> 
> The paragraph above raises one more question... how to use the  
> backup_script feature of rsnapshot.

I don't know your backup_script, but you can just add to it. It is 
usually possible to give read only remote access, with or without 
password, from the server where you store your backups. Then all you 
need is to add a few lines to your script.

For ldap, you'll want to create an ldif format dump. For sql, check out 
the various dump formats. The more sql standard the more secure you are, 
but it comes at the price of time when recovering data.

For sql, you may also consider whether to include statements for 
dropping existing tables and databases as well as include create 
statements. It really depends on which disaster you're preparing for. It 
may be possible to create one dump with drop/create statements to 
recover database structure, and another dump with data.

The reason you'll want to dump ldap/sql data is that you ensure data 
integrity if your backup coincide with some update of the database. 
Also, you can use the backup when upgrading or even if you change 
database say from mysql to postgresql - for this you need as strict sql 
backup as possible, both allow some shortcuts that are faster for 
recovery but may be incompatible with other databases. Make the backup 
verbose, ensure that things like default character set is included in 
the dump, make sure that binary blobs are dumped in base64 etc...

You _can_ do file backup of your databases, it is certainly faster to 
recover from a file backup, but you run the risk of inconsistencies.

The same problem of data inconsistencies can happen with any other file 
backup:

you may wish to temporarily stop local maildelivery while you backup 
user's mail boxes. Mail will remain in the queue till backup terminates 
and local mail delivery is reenabled.

you may consider not to backup log files, or only files after they have 
been rotated so they are no longer written to.

you may consider locking down user access while home directories are 
backed up, etc.

It all depends on the time required to complete the backup and the 
normal activity on the systems while you backup.

And - don't forget - now that you have everything nicely backed up, you 
need a data destruction policy to ensure that you don't accidentally 
keep personal data from old users.

BR, Erik

-- 
Erik Nørgaard
Ph: +34.666334818/+34.915211157                  http://www.locolomo.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A92B4AA.3070605>