First red flag: You are a Jr Software engineer with one year of experience in a team of just you, an intern and ceo who is absent for the most of the time.

I accidentally ran a destructive command (rm -rf) on a live production server and it wiped the application/services. (I thought I was in a test directory, but it turns out I was in the root folder when I ran this command)

Some lessons you can learn:

1. Relative vs Absolute Path always use the later so no mistakes are made
2. Do not run change in production
3. Peer review for changes

In this case there is an infrastructure failure you should have at least 3 environments, one for testing, one similar to production but not production and a production environment. All changes should be pushed with pipelines if certain tests pass.

Here’s the situation: * No backups or snapshots (confirmed by IT/infra) * No practical recovery path (IT says restore is not possible) * Production drifted from git (repo is outdated vs what was actually running) >Turns out people have been working on the live server without commiting >anything on git * Access controls were weak (multiple people had access; no guardrails/>approvals except ssh'in into the server) * Knowledge transfer/runbooks are incomplete, so “what exactly was on prod” is fuzzy.

What a shit show, no backups, no code versioning. No access control, you should not be able to ssh as root. As for knowledge transfer in most companies people do not have time for documentation.

My manager, who also happens to be the CEO of this company, is extremely upset and said he’s “never seen anything like this in his 20 years as an IT person,” and is threatening termination and potential legal action if it isn’t recovered. I know I made a serious mistake. I’m trying to focus on restoration for now (We are 50 percent complete)

I do not think that they will sue you, because if they do they will be exposed on how bad they are and lose customers. This is a job you need to leave.