That’s the name, but I’ll break it up for you: SQL Backup and FTP. If you guessed that you will be able to back up your SQL database and move it to a secondary system via the File Transfer Protocol, FTP, then you are correct!

This is one of my greatest tools to use. A few years ago I had a dba (database administrator (shout out to Vanco)) refer it to me after our campus suffered from repetitive power strikes causing the primary system and the secondary system (backup) to be corrupted. We had a copy of the database, but not the actual copy we wanted…

Anyways, let us get into the functionality and features.

Just one Note #

SQLBackupAndFTP is a powerful, free/paid, tool that truly relieved me from years of stress.

You cannot get an easier dB (database) backup tool than this one. Download, select the source (dB), select the destination (cloud/NAS), schedule the job, and walk away.

Setup #

Before we get too far ahead, remember, that it’s always smart to plan ahead. Take a look at the features. For me, I only need to backup 2 databases, so I can use the free tier. I’m also okay with backing up my copy to Google Drive, which is supported on all paid feature plans, so I’ll need to upgrade to lite (BUT WAIT, I HAVE A WORKAROUND!). What about you?

Step 1. #

A. Download the Software

SQLBackupAndFTP – Just in case you already forgot the name.

B. Install

I’m okay with the default installation path, so I’m not changing anything. SPAM “NEXT”!

C. Launch

Step 2. Set the Source #

A. Connect to Database Server and Select the dB to be backed up

Step 3. Set the Destination #

A. Store backups in selected destinations

Remember, I want to backup to Google Drive, but it’s locked for the “lite” feature set and up… With Google, you can mount a virtual disk, but you will need to do this on the actual server/workstation running SQLBackupAndFTP. Typically, their backup will go directly to Google Drive via API. With my workaround, the system thinks the “G:\” drive is a local disk. Aka, I qualify for the free tier.

B. Mount Google Drive on the local machine and select its virtual disk.

C. Select the virtual disk (typically “G:\”) as the destination.

Step 4. Schedule #

The most important part of this is automation.

A. Automate the backup processing with their built-in scheduling!

I have a lot of thoughts on the schedule, but for most of you, nightly backups will be enough, maybe even a mid-day backup around lunchtime. I prefer backups both an hour before the start of the workday and an hour after the workday ends, with a nightly backup.

On top of that, I use the Grandfather, Father, Son model to age backup rotations for as many as 1-5 years. Remember, we have to retain data for 5-10 years at times. Some business professionals forget that and “clean” up too often. At least you’ll have a 5-year-old copy of the data, from 5 years ago when they originally had the data… Anyways – make your schedule based on the RPO and RTO business objectives; aka., let management help you make this decision.

–> I’ll reference my RTO/RPO document at a later date, but if I don’t REMIND ME!

Step 5. Walk away #

Okay, the final step, walk away. I don’t mean to truly forget about this application now that it’s completed because I’ve seen instances where Google Drive updated but didn’t cache the credentials for an auto-login… I went about 19 days without a dB backup 🙁

Check the application or the Google Drive destination for the backup – DAILY!

Powered by BetterDocs

Leave a Reply

Your email address will not be published.