I did a bit of research about site backups, a while ago, when I was building a platform for the most cost effective site proactive security.
> Site backup is not that simple as it sounds. Your backup is no good, if you are not able to easily restore.
I used to think the same, till I started questioning several things, while building the platform.
The real question is how easy it is to do a restore from a backup.
Writing scripts and cron jobs are not the ideal way to backup sites. Why?
- Do you get notified if there is a change in site file?
- Do you know if backup job is even running?
- Does your backup job notify you on failures?
- How easy is it to restore your site?
- What if your oldest site backup has a malware, that was never detected? Your oldest backup is of no use. You cannot rely on Hosting provider backups either. You can never revert to pristine version. Your site will have to be taken offline and you will have to spend money to remove malware, remove blacklisting and host elsewhere. So backup with rotation strategy is no good.
- Backups ought to be offsite. Cannot rely on local machine.
- Backups should not take much hosting server resources
- Backups should allow to keep multiple redundant backup copies, with notification
- Backups should be done quickly
Forgot to mention, that inotify is also a good way to trigger backups. Inotify records file events and you can program on catching an event.
So, you can look for write events in your site docroot folder, and trigger incremental backup. You will have instant backup on site file change.