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
As a DBA, automating your various jobs on SQL Server – taking backups, truncating logs, updating statistics, etc – is a good idea because it makes sure you don’t have to depend on your feeble memory for these important tasks. And it leaves you free for more vital tasks such as sleeping and bingeing on whatever new Netflix series is out. But to make sure your automated tasks are still running, you need a good notification method, and it should also be automated. And foolproof. So how do you do this? Continue reading How to set up SQL Server Email Job Notifications
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
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.
Click to read the article and to find out how to resolve this!