- The AppSec Augury
- Posts
- 0x02: The Importance of Backing Up Your Stuff
0x02: The Importance of Backing Up Your Stuff
It's not just big organizations that need to worry about this.

During the pandemic, I had two of the biggest panic moments of my life related to course work.
Tom Scott described the concept of the onosecond, that moment where you realize something has gone horribly, horribly wrong (though I like to think the concept extends to things you didn’t do yourself as well). I had two of these:
The moment when I realized I had just irrevocably removed the wrong files by specifying the wrong file extension
The moment I realized one of my course VMs (virtual machines) had been corrupted, and all of the work on my project had been lost
Two very big “Oh, no” moments, indeed. How did these happen?
The first was in my data structures and algorithms (DSA) class. I was working with the Java programming language, which when compiled, produces bytecode. These bytecode files, which are what the Java runtime uses, have .class extensions, which are separate from the source code .java files. Whenever I submitted things, due to my limited knowledge of how the CLI zip tool worked at the time, I’d opt to just remove the .class files.
Except, you know how sometimes you mix things up?
Two seconds later, I realized, “Hey, where are all my .java files?”
One onosecond later…
The worst part was that I was using the rm command in Git Bash (a kind of terminal on Windows), which, similar to the “empty recycle bin” action, would unlink the files. With my limited (read: practically nonexistent) forensics knowledge, I couldn’t recover these. Was I doomed to start over?
Luckily, every time I submitted, I saved a zip archive of all my source files. This meant that I could actually recover everything at a point where getting back to where I was was significantly less painful.
The second story wasn’t strictly my fault. One day, I opened up my VM and it started acting funny. As in, wouldn’t let me log in, glitchy screen, bunch of issues funny. At a certain point I could no longer access the VM.
Unfortunately, this time around I never made any backups.
With virtual machines, you can optionally create backups of your machine by taking “snapshots.” These allow you to quickly restore to a previous state. Alternatively, since I was working with code, I could have backed things up to Github, though that would have required me to know how to do that.
Luckily I was able to communicate to my TA and prof and they understood the gravity of the issue. I had enough time that I was able to finish the project on time, but in the interim it was pretty scary.
So, what can you do to avoid being like me? What can you do to make sure that if something gets nuked or goes wrong, you can keep on trucking as if you hadn’t just nuked your dissertation?
TL;DR: Make backups. Redundancy in general is a key part of Availability, one of the three pieces of the CIA triad. Availability in a nutshell is your ability to access things.
Thanks to NetworkChuck I learned the great phrase: Two is one, one is none. It means that you should always assume that something might go wrong, so keeping a spare copy of something might be worth the extra effort.
In order of most applicable to the average person to least:
1. General Files: Cloud Storage
Keeping files in the cloud lets you make sure that not only can you access them from anywhere, but also that you can back things up in case something goes wrong. However you decide to do this, whichever provider you decide on, and any sort of measures you take are up to you.
One possible method is using something like Proton Drive, which has a free gigabyte of storage, and setting one of your local folders on Windows as a synced drive. From there, if anything ever goes wrong with your files, you can restore to a previous version from the web app. Plus, Proton just rolled out photo backups. Of course, you could use Google Drive or OneDrive, but I’m not showing them my hard drive any time soon.
Another possibility is something like Sync.com’s vaults, which allow for secure, dedicated backups in the long run.

2. Code: Git & Github/GitLab
Git is a little annoying to learn, but once you get it, it actually becomes super valuable. Git is a version control system useful for keeping track of revisions. If you have a remote repository (a place to store code, files, revisions, etc.), you can use that as a backup: Github and GitLab are two popular options. Even handier, if for some reason some of your new code doesn’t work, if you have a revision (AKA a commit) just before you made that revision, you can restore it and get back to a state where everything worked (hopefully).
3. Everything: NAS
Okay, wait, I just mentioned a cloud, why do you need a NAS? Great question.
A NAS (or Network Attached Storage) is essentially a hard drive (or 2, or 4, or 10) that you hook up to your network. The benefit of this is that if one of those hard drives fails, you still have several other working hard drives that can compensate. This is due to technology known as RAID, which employs the exact principle of redundancy. This video can help explain a little better.
The reason why this isn’t higher on the list is because buying the gear you need to build a NAS can get pricey, even if it’s just a Raspberry PI and some hard drives.
4. Virtual Machines: Snapshots & Backups
If you’re working with VMs day to day, chances are you’re doing some potentially risky stuff. Even if you’re not, hard drive corruption can really mess up your day.
Many VM software suites (VirtualBox, VMWare, KVM) allow you to take snapshots of your VM’s state. This way, if you ever run into issues and need to fall back, you can just restore the snapshot, maybe update the system time, and then you’re good to go back to where you were. Procedures vary from suite to suite, but the overall concept is the same.
Alternatively, you might need to store something more long-term. This is where backups come in. These allow you to store copies of data pretty much anywhere for as long as you need: files, file systems, heck even the entire VM. This prevents that single point of failure problem like we mentioned before.
This article goes a little deeper into the similarities, differences, use cases, and methods of the two.
Conclusion
If you’re not already backing up your data, doing so is a great way to avoid a massive headache down the line. Deleted source code, corrupted VMs, or a family member nuking your dissertation are all things that very well could happen, but don’t worry: so long as you have a backup somewhere safe, you’re in a good spot.
Reply