I have a confession to make

It was three 'o clock in the morning, and I had been coding since three in the afternoon - I was doing all the regular quick moves around the terminal as usual and went to delete all the files within a certain directory using the very useful rm -rf * command. But once I had hit that command, I noticed after a few seconds that the command was taking a bit longer to execute than usual - I took a look at which directory I was currently inside, and my heart sank to the bottom of my chest. I finally did it, after 7 years of using Unix machines... I did rm -rf * from within my home folder. This happened a month ago, and I've since boiled the reason down to me being too tired and being too locked in the zone.

I had let the command execute for 2-3 seconds before noticing - once I had cancelled the command I immediately looked around the various folders of my computer to assess the damage. And from what I could tell, nothing immediately critical had been hit, but it did manage to delete my entire desktop folder... That desktop folder was home to the archive of my 14-year long music career as well as current projects I've got with active clients.

Did I keep a backup? Yes! I had Google Drive synced to my entire computer. "Perfect" I thought, and so I just downloaded all my files again from the cloud, back to my computer. But there was a giant issue; all of my files were completely jumbled and thrown together. A full terabyte of data, hundreds of music projects where each project could have 100-300 audio, project- and cache-files bound to it, completely jumbled like a big soup. And so while I could recover my data, I needed to manually piece everything back together.

Two lessons I learned

It's a month later now. I have yet to re-organize my music archive, and it will probably never be done. I have succumbed to the reality that I might never recover a lot of my files.

There are two lessons I learned from this:

1. Never trust Google Drive ever again - I promptly stopped subscribing and am keeping physical backups of my computers SSD on three different computers/drives for now (as a temporary solution) through rsync and scp.
2. Unix tools such as rm are extremely powerful, but with that power comes great responsibility.

With these lessons learned I came up with a better solution for the rm command: overriding it with a safer wrapper.

# safe rm command
rm() {
  local cwd
  cwd="$(pwd -P)"

  if [[ "$cwd" == "/" || "$cwd" == "$HOME" ]]; then
    echo "'rm' blocked: inside home dir"
    echo "use command 'permanent' instead"
    return 1
  fi

  trash "$@"
}

# safe rm command override
permanent() {
  echo "delete permanently: $*"
  read -p "type DELETE to continue: " confirm
  [[ "$confirm" != "DELETE" ]] && return 1

  /bin/rm "$@"
}

With these overrides I am forced to confirm each time I want to delete something from within the home/root directory - and the usual rm command will be redirected to the MacOS trash command which will move any files to trash instead of deleting them permanently.

A better backup solution

My issue now is that I'm in need of a secure, stable and predictable backup solution - preferably one that is directly controlled by me, and built on top of open-source software.

If I were having this issue 10 years ago, I would build two separate NAS servers and keep one at my home, and another one at a friends home, both being set up to synchronize to each other - this way I could get some redundancy. But I'm not a home-lab guru, so I don't know whether an idea like this is naive or unrealistic or not. Either way - today the server hardware market looks very different, and I don't have a ton of money - with the RAM shortage and everything, building a backup solution of that caliber would be very expensive.

As I mentioned earlier, my current backup solution is temporary, but it works. I use my Macbooks built-in TimeMachine functionality to sync to an external harddrive, as well as periodically syncing the contents of my macbook to a couple other linux machines I have through scp and rsync. This works for now, but if anyone reading this has any better recommendation, feel free to contact me.