Need a Backup Strategy

[Ahr Aitch]

I created an SMF forum on my localhost webserver.  I have not yet hosted it with my Internet webhost.

Today, I managed to step on my localhost MySQL database.  No, of course I hadn't backed it up.  I've had the joy of trying to recover it for the last several hours.  Fortunately, it only had test posts and gallery pics but it's a pain to have to reinstall.

So, before I step on the database again - and I surely shall because I'm new to MySQL - I thought I should learn how to back up the forum (all of it) and how to restore it from a backup.

My plan is to create a daily backup routine, maybe using batch files.  Before I dive into that cesspool, I thought I'd ask here what others do and maybe even find an article or wiki that will help.

TIA

[CRM 114]

I thought I'd ask here what others do

My solution:
Cronjobs (via PHP scripts)
Database dump every 12 hours.
Create a tar.gz of the complete SMF folder every 7 days (we don't use attachments on the fourm, so it's not that big).

The files are stored outside of the webroot. Database dumps are kept 28 days, tar.gz 180 days, and automatically deleted, if older. All files are mirrored to another system.

Manually, once in a month
I do a restore check of the database dump on my PC via Bash script, it shows a little summary (member count, postings count and so on, like the forum stats).
I copy one database dump and one tar.gz to a longtime archive.

[Doug Heffernan]

My plan is to create a daily backup routine, maybe using batch files.  Before I dive into that cesspool

A word of advice, if I may, always check the backup files done through automated scripts to make sure that they aren't corrupted/incomplete.

maybe even find an article or wiki that will help.

Have a look at this wiki.

https://wiki.simplemachines.org/smf/Backup

[Sir Osis of Liver]

My host uses Jetbackup to create full account backups that are saved for 25 days.  I'm also running cron jobs to back up important databases and save them for 30 days.  You can never have too many backups.