OK, having said that, backups are also an absolutely hu...uge subject and many will have different idea's or views to mine. My methodologies are based on Large Corporate "Enterprise" backups from 20GB upto 30TB per cycle, including Host, OLTP, DBase, Flat Files covering Windows, Unix, Linux and Mainframe and might be considered overkill by many. But <crossing-fingers and everything else that doesn't hurt too much at my age..> combined with other methods of Information Protection, such as syncronous and a-syncronous mirroring/replication and using snapshot technologies, we have so far, not had any serious instances of data loss or extended information outages on the customers I work with or in our own Enterprise.


On the whole there are three traditional backup types; Full,  Cumulative and  Differential...

FULL Pretty obvious, a complete backup of all associated files at a known point in time (in this case, including DBase)

Both of these are considered Incremental backups, they can be used independantly of each other or in conjunction with each other but always relate back to a FULL backup.

Cumulative This is a backup of the differences since the last FULL backup, so each cumulative backup gets bigger each cycle as it is also backing up data previously backup, since the last FULL backup.

Differential This is a backup of the differences, but only since the last backup of any type, not necessarily a FULL.

If you site is not too large, then obviously FULL backups are the way to go, once a week at least. If your content changes quite regularly or more importantly, is either un-recreatable or too costly to recreate, once a night or more may be more effective.

If time, server resources or if the rate of data change is too high to successfully obtain a FULL backup every night, then the Incremental backups come in to their own right.

If you choose to use a cumuluative backup following a weekly full, the backups each night will run quicker than a FULL, however, as the week progresses, each nightly cumulative backup will increase in size and time to take, due to not only backing up the changes since last nights backup, but it will be backuping up all changes each night and previous nights since the last FULL was taken. The benefit of this type of backup, in conjunction with Fulls, is the speed of restoration. To restore, I now only need to recover the FULL and "last" cumulative backup to fully recover my information.

If again, time or server resources are paramount or change data becomes too much for cumulatives, you can turn to differential backups, this style of backup when used in conjunction with a Full will provide a very similar level of protection, but restoration will be slower. Differential backups will only backup change data since the last backup (of any type), in this case, last nights differential backup, (not since the last Full, as with Cumulatives) Thus, when restoring my data, I will need to recover the Full, then each Differential in turn (oldest first) in order to fully recover my information. This method also has the drawback of also recovering any "legitimately" deleted files, potentially "over-filling" the file-system.

Data Protection Best Practice say's;

1. You should be able to "completely" from a catastrophic failure, from at least two previous Full backups. Just in case the last is damaged, lost, corrupt etc etc....

2. A "Good" backup regime should contain at least one Full backup within a chosen cycle, normally weekly.

3. A "Good" backup practice is to store backups away from the current data location, preferably offsite.

4. Dynamic data should be backup "offline" or "hot" to avoid "fuzzy" backups (data is changing as you backup it up, potentially leading to related information not being in sync when backed up.


Now, having thrown all of that at you... For the average website, a "Daily" or "Weekly" Full of both site and database is normally more than enough and more than possible within the server capabilities, resources and timeframes. Keeping a number of backups for a period of time is always a good plan, maybe keep each weekly backup for one month. This allows you to recover at least an old site, in the case of emergencies or if for some reason you have local backup file corruption, but should not become too combersome or time (or space) consuming to manage.

There are many PHP and Perl scripts available on the web that can be automated through CRONTAB and can either EMail (if small enough) or FTP the backups to an off- or cross- server location.  also remember, that to some degree, with Joomla! you already have an "Instant" Backup of the core files, if you haven't modified core, the Joomla! distribution files can be easily restored. Then you need only worry about backuping actually changed files and the database, thus reducing the time to take the backup or the size of the backup, no point in backing up unchanged duplicate files all the time, but obviusly, this takes a little more planning and organisation.