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
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.
Ph: +34.666334818/+34.915211157 http://www.locolomo.org
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"