Amazon Backup Options
When it comes to backup, using Amazon
S3 is (in my opinion) one of the more difficult methods. It's not as bad as Amazon Glacier or some of the others
, but still not easy. It's hassle because you can't just FTP or sFTP to it. You have to use it's proprietary methods (SOAP). So it's not straight-forward, though it can be cost effective and "easy" once you setup all the non-easy aspects of it.
When it comes to cPanel -- the control panel of you dedicated server -- the best choice is to use one of the cPanel plugins.
All of the plugins (and feedback!) can be found on the cPanel site: http://applications.cpanel.net/categ...kup-utilities/
And this one looks to be best: http://s3backupwhm.com
Here's another one: http://www.cpanelbackupscript.com/
For example, this is nice:
Incremental backups Our script only updates files which have changed on S3, saving your bandwidth costs and vital server resources. Optionally retain up to 7 recent copies of your backups on S3. Support for files larger than 5GB in size also included.
Of course, that also has it's fair share of issues.
The Ugly Side of Server Backup Methods
That particular S3 plugin requires root access to setup, which can be an issue if you're not the server admin. (Even when a server is "dedicated", the users aren't necessarily the server admin, nor should they be. That's a whole different can of worms, when users are forced to admin servers, or when techies are required to create content. Few have both skill sets.) Many of the other plugins have not such requirement, be it the FTP ones or the "incremental" systems like R1Soft.
Second, remember that all these methods "push" a backup, not "pull". So if a hacker gets into the main server, you can kiss the backups goodbye too. Files are hard to pull, but the databases are not.
And finally, simply having a backup method that auto-update file changes (incremental backups) can be useless. If a file is hacked or corrupted, and then that one overwrites what's on a single backup, the backup becomes worthless. So the Amazon method suggested in the first post is not an ideal scenario. One backup is not a backup.
What so many hosts fail to tell customers is truly how inferior these backups method are. In my experience. at least 25% of all sever backup are corrupt, while others can be DAYS slow to recover anything. I'd especially mention R1Soft (rsync) as getting a lot of poor user feedback.
What Other (Shared) Hosts Do
- R1Soft is CDP at a number of shared hosts I use. (CrocWeb, DowntownHost, Ninjalion)
- StoreGrid is alright, but it's slow too. (Veerotech
is probably one of the better ones, with $120 owned individual licenses. (48-14)
- CodeGuard is an added option from one host, but it's $99 per month! (Namecheap
Probably half of the shared hosts I use don't provide a backup method. None of the dedicated or VPS hosts do. Some used to, but dropped it because if the headaches it caused. Incremental backup is nice, but it scales poorly for whole servers. That's the same concept as Apple's Time Machine, which also has it supporters and detractors. The best method is grabbing the whole, when needed (and ONLY when needed!), using a simple (normal!) method.
I can get extra backup space for a reasonable cost from my dedicated/VPS server providers -- same host, same place, etc -- but that's still not an ideal backup.
How Often to Backup
What a lot of folks forget is that (1) the backup is only as fast as the slowest server, and (2) that it takes up quite a few resources on both ends. It hits disk I/O, bandwidth, CPU and RAM in the process. Your big fancy server can quickly become a slow fancy server. For this reason, when it concerns the file system (not databases), try to backup as least often as is possible.
These days, in the era of CMS, most everything is stored in databases. Backup those up daily or weekly ... match the backup frequency to the content addition frequency. Most user-generated content sites should be daily (forums, mostly). So keep this in mind.
How to Find Database Size in cPanel
Finding out how much is files, and how much is databases, is really important. That could impact the entire backup plan. On the cPanel main page, find the MySQL Databases icon, click it:
And the locate the current databases:
|You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community.|
Although this is the cached size on disk, you can use it to at least make an estimate. Add those up, and subtract them from the 66 total GB. You'll arrive at the file system. Furthermore, you'll know what the database size or each, and if there's any reason to be concerned.
One things to note for forum owners is that you should never store binaries (attached files) in the database, as it's makes it huge, and potentially unstable. Files go in the file system, posts (text) go in the databases. As an example, a forum with 100,000 posts should only be 100MB as an SQL dump -- less if the SQL dumped is gzipped on backup. The database on disk in often larger than the backup of it, so remember that.
Isn't it funny how a "simple" pair of questions can results in such a long answer!
Before you can proceed to outline a plan, you really need to know the db sizes, and the overall % of disk space it uses.