SharePoint 2010 Backups - Use SharePoint Backup or SQL Backup, or both?

There are lots of point to discuss before coming to a conclusion here. But I will just explain the different possible ways you could do backup in SharePoint in an order of good to best.

    Central Admin Backup - This is a default UI option that comes within Central Administration. It allows to take full and differential backups. You have the additional flexibility to backup and restore Search functionality. This is not a full proof backup plan though due to limitations in scheduling, backing up config db, config settings in the farm and failure of timer jobs.

    Powershell or Stsadm Backup - Powershell gives you high amount of flexibility in taking full or differential backups. Windows task scheduler helps in scheduling the scripts. It also takes backup of content dbs and search index files and is much more reliable than Central Admin Backup. This also has limitations like lack of backup of config and IIS settings.

    SQL Server Backup - As we know, SQL full and differential backups, enable us to bring back the SharePoint sites and config db almost 100 percent. This is comparatively the fastest backup and restore method, with more reliability than the above methods. But lacks backup of farm, IIS settings and search crawl indexes, which will have to be done manually.

    Microsoft Data Protection Manager - aka DPM, this is the tool that promises to give you the best shot for SharePoint backups. You can backup and restore literally everything related to SharePoint using this single tool.
        All DBs whether content or config
        Farm settings, IIS settings and system state settings.
        Backup and restore of 14 hive or other file directories.
        Farm level backup even if the farm is in running state.
        Removes the processing burden in the farm during backups and increase in performance.

    The only limitation would be the additional funding required to buy this tool.

If you need more detailed understanding about backup and restore, go through this Technet article or check out the detailed SharePoint Backup and Recovery slides from Joel Oleson

Hope this will help you

Hi, both of those links deal with SharePoint 2007 and SQL 2003, but as I stated I am using SharePoint 2010 and SQL 2008.

No.  When you run a full farm backup from SharePoint, it's running SQL backups.  The only issue is, you need to run backups on your transaction logs (through SQL) to prevent them from growing out of control.

Ok, so after looking at the Technet article for SharePoint 2010 it looks like the Central Admin Backup gets exactly what a SQL backup would, with the exception of SQL Server Reporting Services databases.

So I think the answer to my question is:

A Central Admin Farm Backup, plus a SQL Server Reporting Services databases backup, plus a SQL Server Transaction Logs Backup to keep the log files from growing seems to be what I need at a minimum.

I would also consider backing up all of the databases with SQL, because it will never hurt to have some additional backup to the Central Admin backup.

I also see that neither of those methods gets Customizations not deployed as solution packages, Changes to Web.config not made by using Central administration or an API or IIS configurations not set through SharePoint, which would all requitre a file backup. I honestly don't know if we have any of those, but if so a file backup is in order.

Thoughts and suggestions?

Well in order to have your files system backup, regarding customizations and others, you seen your server backup. If you hosting this on a VM then just need a VM backup or snapshots whenever you need a back up.

Combined with your SQL backup and Server backup you should have a good backup solution

Why aren't points split on this answer?