Automated File Backup Project

Have you ever lost hundreds of files and pictures on your computer because you forgot to create a backup?

Fortunately, this has never happened to me. But, unfortunately, it can happen to me because I don’t back up anything. Not my personal laptop. Not my iPhone. Not even my work laptop. The only backups I have are from whatever cloud-based applications I use (like Notion, Google Drive, and Webflow). The applications themselves create and store backups, however. So, I do nothing.

I always assume a personal, technological disaster is unlikely. But unlikely does not equate to impossible. So, while the odds seem slim that one of my laptops or phone breaks, there’s always a chance it happens. And, currently, I am unprepared for that.

Part of me has always wanted to back up my files and save them to the cloud. However, it always seemed too much work. And I’m lazy. So, instead of spending a few hours manually moving files from my laptop to some cloud storage, I spent a few weeks building a tool to do it for me. Gotta love the irony.

I’m no longer making myself vulnerable to a technological disaster. I recently finished building an Automated Backup tool (see the code on my GitHub here), so I now feel safe(r).

Why did I build this?

The one sentence version is this: I built this tool to automate my currently nonexistant file backup process.

The longer version goes like this…

I recently began programming again because I like building things and know I have the intellectual capacity to do so. I have programmed with Python in the past, so my foundation is strong. This time around, however, I didn’t want to build some run-of-the-mill project like a snake game, a calculator, a useless web crawler, or a lame version of Tic-Tac-Toe. Instead, I wanted to build something that delivers real world value to at least one person.

And since I couldn’t identify something others needed, I looked at my own life and questioned what tool I wish I had. That’s when I came across this idea.

See, at work, I have hundreds (possibly thousands) of Excel and SQL files stored locally. My company is generous enough to give all associates a personal ShareFile folder. But I never save my work there. I remember trying to back up files there once at the beginning of 2024, but that was a cumbersome effort that resulted in less than 10% of my work backed up. Manually moving the files was annoying, so I decided not to do it again. Living life on the edge.

While brainstorming project ideas, I realized I could bulid a Python script to move select files from my local storage to the cloud-based ShareFile storage. That realization birthed this project.

How does the tool work

The simple version of how the tool works is that it automatically backs up files for me.

But there’s more complexity in the backend of the tool. Here’s my best attempt at giving a simple rundown on how the tool functions:

I identify the destination directory to back up files to. In my work example, this would be my personal ShareFile folder.
I identify which directories I want to backup on my laptop and add them to a list stored within the tool’s config file.
The tool parses through each directory from step two. Based on the last execution time, the tool determines which files to back up.
The tool copies files from the source directories to the destination directory.
It logs all info and errors to log files, so I can review executions if needed.

Even this is a fairly simple explanation.

Each step I identified could be broken down into further steps, which could also break down into further steps. For example, the logging feature I built doesn’t only log info and errors to log files. It also detects when the log files do not exist, such as during the tool’s first execution, and builds the files before parsing through the source directories.

I like paying attention to little details like this. But for the sake of being concise here, I won’t dig into all the minute details.

If you’re really interested in how the code works, go to my GitHub, clone the repository, and play with the code yourself.

Things I learned

There’s a long list of things I learned building this project. Some I already learned from past programming efforts (years ago) and relearned now. Other lessons were brand new. I don’t feel like writing deep explanations on everything, so I’ll list a few interesting things I learned:

How to output text to the console with different font colors
How to write PowerShell functions
How to make custom PowerShell functions built-in so you can execute them from any directory
How to manipulate date formatting
How to build and work with recursive functions
How to use try/except for error-handling
How to read and manipulate json files with Python
How to create and use virtual environments

And so on…

I could list more, but I think you get the idea.

Most of what I listed are fairly basic concepts that most beginners should probably experience early in their programming journies (at least, that’s what I would assume). Even though I had some experience programming with Python in the past, being out of practice for over 1.5 years made me forget a lot.

So, I’m happy to work with these concepts again. Based on what I learned in this list alone, I already know the project was a success.

Sacrifices I made

Although I’m not the best programmer, I am good at problem solving and conceptualizing ideas. So, there were a few features I wanted to build into this project because they would have made the tool easier for me to use.

The problem, however, is that some of those ideas forced me to spend a lot of time debugging code and hitting dead end after dead end. I could have continued to working on the issues to make the feature work, but that would have wasted time I didn’t want to waste. Even though the project was about learning, I had to draw the line somewhere to actually finish the project.

From the first line of code I wrote to the last, nearly a month had passed. I didn’t work on this every day, but I spent enough time on it to realize I hit a point where I needed to ship something functional instead of something perfect.

Below are two features I sacrificed because they gave me too much trouble:

Making my AddAsSourcePath PowerShell function take multiple parameters: Parsing through parameters with PowerShell is annoying, and I couldn’t get my function to properly add the correct directory to my config file. This feature would have slightly improved the way I add directories to my source list, but what I finished with works well enough to please me.
Making my LocalizePowershellfunctions.ps1 script handle all setup for me: The script automates about 95% of the setup (which includes creating the PowerShell function and adding them to my Windows $Profile file). But there is one small thing I have to manually do after running the script. I tried including this step in the script, but I ended up spending too much time trying to build a feature that wasn’t critical to the tool.

I now realize that the “nice-to-have” features I sacrificed concern PowerShell scripts, not Python. Since this project was intended to improve my Python skills, not my PowerShell scripting skills, I don’t regret these sacrifices. They still leave me with a functional tool. That’s all I need.

Final thoughts

Overall, I’m extremely happy with the project. As of writing this, I have not tested it out with my work laptop yet, but I’m looking forward that adventure.

This project was fairly straightforward, but it made me realize that I am capable of building cool things. I always believed in the past that I wasn’t cut out to become a software developer or programmer because I didn’t have what it takes to execute on complex topics. But between this project and my experience supporting developers at work, I realize that I am more than smart enough to build things with code from scratch.

So, whether I actually use this tool consistently in the future or not, this project has reignited my interest in programming. That alone makes this project feel like a success.

On to the next project…