For many DBA’s, copy-only backups introduced in SQL Server 2005 are a little-known and little-used feature of SQL Server. However, they can be mightily useful whenever you need ad hoc backups and do not want to interrupt and mess up your existing backup schedule. Read on to find out more.
A central tenet of Disaster Recovery (DR) is that you should always maintain an offsite or off-premises copy of your critical database backups. The logic behind this is simple – if you don’t have access to your premises, for example in case of a natural disaster affecting your area, your offsite backups mean that you can restore them and still have access to your critical data. Let’s take a more in-depth look at cloud-based storage for your SQL Server backups. Continue reading How to set up Cloud-based Storage for SQL Server Backup
Microsoft’s own Windows Azure cloud is one of the most popular backup options for storage of SQL Server backups. It is especially attractive as an offsite storage medium for SQL Server backups because it is a Microsoft product and is already has tie-ins with the latest versions of SQL Server, beginning with 2012 Service Pack 1, Cumulative Update 2. Let’s take a closer look at how to save your SQL Server backups to Azure. Continue reading How to save SQL Server backups to Azure in SQLBackupAndFTP
For any SQL Server DBA who’s been in the field for a long time, you know that the exercise of restoring backups taken in SQL Server 2000 (and even SQL Server 2005 without using the CHECKSUM option) was many times a sweat-filled lottery. You usually gambled and/ or prayed to your respective deity that your backups would actually work. Why? Because you knew that restore failures were all too common. Despite SQL Server’s assurance that all was well because you had already verified your backups with the RESTORE VERIFYONLY option. So why was this the case? Why did restore operations fail so frequently? Let’s delve a bit more into the innards of the RESTORE VERIFYONLY and CHECKSUM options to find out.
If you have a database in the OFFLINE state and these databases are scheduled to be backed up, their backup will fail and the whole backup job will be shown as Failed. Same when you use Database Mirroring, you may have databases in Restoring state and they can’t be backed up either. If you have such databases included in your backup job, you may want to skip them if they are in an Offline or Restore state and show the whole job as Success, not Failure. Continue reading How to skip databases in Offline state in SQLBackupAndFTP
SQLBackupAndFTP has an option to backup all non-system databases. This is useful as it would automatically add all the new databases added after the backup job was created. Continue reading How to exclude databases from a backup job in SQLBackupAndFTP
If you have limited access to SQL Server’s file system, getting the .bak file back may be an issue. In this case, you can send database backup to some network folder if both you and the SQL Server have access to it.
We will show how to do it with SQLBackupAndFTP. Continue reading How to backup SQL Server to UNC Path