Data is the business world’s fuel, and few things are more terrifying than the prospect of losing it—especially if you’re running mission-critical workloads on Linux instances. Automated snapshots are a fantastic safeguard, but sometimes you need a pinch of customization. Enter: backup scripts.
In this guide, we’ll pull back the curtain on running custom Linux backup scripts with N2W, walking you through setup, script types, and pro-tips.
The Why (and When) of Custom Backup Scripts
Automated backups are great, but sometimes your data has special requirements. Maybe you need to quiesce an application before the snapshot to ensure consistency, dump a database, or perhaps send a notification (yes, even that “All Clear” Slack message counts). This is where custom scripts make all the difference—they bridge the gap between raw snapshots and a backup process that truly fits your needs.
Gearing Up: Accessing Your N2WS Server Like a Pro
Your journey begins with an SSH connection to your N2W server. Once connected, navigate over to the scripts directory—the home base for all your custom backup scripts.
Here’s a delicious twist: scripts can be written in any programming language you like. Bash, Python, Perl, you name it—the choice is yours. The only catch? Stick to the right naming convention so N2W knows exactly when and how to run your masterpiece.
Anatomy of a Backup Script: Types and Naming Conventions
Not all scripts are created equal. In fact, N2W lets you run three flavors of scripts for maximum flexibility:
- Before Scripts
These run before your policy’s snapshots start. Think of them as the warm-up act—great for pausing services, dumping databases, or prepping your filesystems for that perfect capture. - After Scripts
These execute after snapshot processes have been triggered, but while the policy is still running. Ideal for post-snapshot cleanup or notifying other systems about the snapshot’s progress. - Complete Scripts
These take the stage after all snapshots are finished, signaling the grand finale. Use them to resume any paused services, clear temporary files, or send a triumphant “backup successful” email.
Now, to make sure your scripts sync up with your backup policy, follow this format:
<type>-<PolicyName>.<file extension>So, if your policy is called “LinuxServers,” and you’re feeling bashy, your script might be before-LinuxServers.sh, after-LinuxServers.sh, or complete-LinuxServers.sh.
Installing and Testing: The Smart Backup Admin’s Checklist
Don’t be the person who deploys untested scripts. Craft your scripts, then test them thoroughly—ideally in a safe sandbox. Confirm that each script does exactly what you expect, and doesn’t inadvertently cause chaos in your backups.
Once you’re confident, drop your scripts in the right directory on your N2W server. Bonus points for double-checking permissions and syntax. (After all, even the best script can be defeated by a missing chmod +x.)
Enabling Scripts in the N2W Console
With your scripts in place, head over to your N2W console. Navigate to the Policies area and select the lucky policy that’s about to become smarter. In the “More Options” tab, simply tick the “Activate Linux Backup Scripts” box. You can customize script timeouts if you like—but the defaults work for most cases. Want to keep an eye on what your scripts are doing? Check “Collect Scripts Output” for easy monitoring (or choose “Ignore” if you’re the trusting type).
The Takeaway: Automated Backups, Personalized Perfection
With just a bit of scripting know-how and a few strategic clicks, you can tailor your backup routine to fit your unique environment. Your Linux instances, and your sanity, will thank you. Happy scripting—and may your backups always be pristine, recoverable, and uniquely yours!
