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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to