Steves & Sons Automates 16 GB SQL Server Backups With Files.com—Without Changing Its Backup Process

Steves & Sons has been making doors since 1866. The U.S. manufacturer and distributor sells doors and related building products through retail and B2B channels.

An operation of that size runs on its data. Orders arrive from retail accounts over EDI, and the SQL Server databases behind the business are backed up in full every night because they hold what the company would need to restore. A nightly backup only counts as ransomware protection, though, if a copy leaves the environment and lands somewhere an attacker who has reached the network cannot also reach. Steves & Sons wanted to automate that offsite copy without changing the existing SQL Server backup process or its variable, timestamped filenames.

The Offsite Copy Depended on Someone Doing It Every Night

Until Steves & Sons brought the workload to Files.com, that offsite leg was manual. SQL Server wrote a full backup each night, and a person uploaded it offsite by hand.

That put the company's last line of defense on a nightly chore. A copy that only leaves the building when someone moves it is only as current as the last time someone moved it. The recovery point depended on discipline rather than on a system, and the task claimed IT time seven nights a week, every week of the year.

The Backup Process Itself Was Off Limits

Automating the upload sounds trivial until the filenames get involved. Each night's backup file carries the date and time of its creation in its name, down to the second, and the seconds vary from run to run. A script pointed at an exact filename works once and fails the next night.

The obvious fix, changing the backup job to write predictable names, was off the table. The SQL Server backup process worked, and the company wanted it kept exactly as it was, naming convention included. The files were also large, with single backups approaching 16 GB.

So the automation had a specification before it had any code: run unattended every night, find whatever filename the backup job produced, move a 16 GB file reliably, expire old copies on a schedule, and leave the SQL Server side completely untouched. Steves & Sons made Files.com the offsite destination and built the automation around the Files.com CLI.

PowerShell, the Files.com CLI, and a Wildcard for the Timestamp

The workflow the company's CIO built was short and durable. A PowerShell script ran each night and called the Files.com CLI to push the new backup into the Files.com site. Instead of naming the file exactly, the script matched it with a wildcard pattern that absorbed the variable portion of the timestamp, so it picked up whatever file the backup job wrote, whenever it finished, with nobody renaming anything.

Retention belongs to the platform rather than to the script. The backup folders on Files.com carry a 90-day expiration, so each copy ages out on schedule and old backups never need to be deleted by hand.

Nothing upstream changed. The automation wrapped around the existing backup process instead of replacing it.

An Offsite Copy Every Night, With Nobody in the Loop

With the scripted workflow in production, Steves & Sons replaced a nightly manual upload with a pattern that runs whether or not anyone is thinking about it.

• The offsite, ransomware-resilient copy is uploaded nightly without a person in the loop. The recovery point no longer depends on anyone remembering.
• Retention enforces itself. Copies expire on schedule, and pruning old backups stopped being a task.
• The workload runs at production scale, with single uploads approaching 16 GB going through the CLI.
• The SQL Server side is untouched: same tooling, same schedule, same filenames.

A Working Backup Process, Minus Its Weakest Link

The offsite copy used to be the product of a chore; now it is a property of the system.