When using SqlBackupAndFtp you may have come across this SQL Server error when saving a database backup: Cannot open backup device ‘<Path\Filename>’. Operating system error 3 (The system cannot find the path specified). Continue reading How to solve Operating system error 3
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.