prm灾难恢复工具_防止灾难性删除的新工具，如GitLab的

prm灾难恢复工具

by Alan Chen

通过陈艾伦

防止灾难性删除的新工具，如GitLab的 (A new tool to prevent catastrophic deletions like GitLab’s)

Basically: I found most of the existing tools not very helpful and made a new open source tool called rm-protection, which you can download from GitHub.

基本上：我发现大多数现有工具不是很有用，并开发了一个名为rm-protection的新开源工具，您可以从GitHub下载该工具。

I was riding a bus back to my dorm and I almost fell asleep. Suddenly one of my friends sent me a message on Telegram: “GitLab deleted its production database and they are now live streaming database recovery on YouTube!”

我当时正坐公共汽车回到宿舍，差点睡着了。 突然，我的一个朋友在Telegram上给我发了一条消息：“ GitLab删除了其生产数据库，现在他们正在YouTube上进行实时流数据库恢复！”

My head bumped into the seat in front of me. I couldn’t feel the pain but felt sorry for the ops and wanted to #hugops while reading their incident log.

我的头撞到我前面的座位上。 我无法感到痛苦，但为操作人员感到抱歉，并希望在阅读他们的事件日志时#hugops。

Aren’t we all humans who make mistakes? But some data are just too important to lose. For example, production database and photos with families and friends.

我们不是所有人都犯错误吗？ 但是有些数据太重要而不能丢失。 例如，生产数据库以及与家人和朋友的照片。

I have a deeply ingrained fear of losing data. I started playing around with Linux in primary school, and I had only a PC with a single hard drive at that time. As a child and a Linux newbie, I was more careless than most sophisticated users. Once, I accidentally deleted a whole partition — not only the system files, but also my home directory.

我对丢失数据深有根深蒂固的恐惧。 我从小就开始使用Linux玩耍，那时我只有一台装有单个硬盘的PC。 小时候还是Linux的新手，我比大多数老练用户更粗心。 一次，我不小心删除了整个分区，不仅删除了系统文件，还删除了我的主目录。

I still remember the horror when everything crashed and I realized that I had just deleted all my photos. Then I cried tears of happiness when photorec got some of them back.

我仍然记得所有事件崩溃时的恐怖，我意识到我刚刚删除了所有照片。 然后当photorec收回其中一些时，我哭了幸福的眼泪。

快速预防当前这种情况的工具 (A quick survey of current tools for preventing this)

I got off the bus, walked back to my room and started searching for prevention methods. I’ve heard some before: rm -i, Safe-rm and trash-cli.

我下车，回到房间，开始寻找预防方法。 我之前听说过： rm -i ， Safe-rm和trash-cli 。

rm -i (rm -i)

rm -i requires an additional confirmation for each single file and directory. It is tedious to confirm everything that you surely want to remove. It reminds me of the story of The Boy Who Cried Wolf.

rm -i需要对每个文件和目录进行另外的确认。 确认您确实要删除的所有内容很繁琐。 这让我想起了《狼来了的男孩》的故事。

Warning about everything is like warning about nothing. What's worse, some users have developed a habit of using rm -rf regularly, where -f option will override the -i protection.

警告一切就像警告什么都没有。 更糟糕的是，一些用户养成了定期使用rm -rf的习惯，其中-f选项将覆盖-i保护。

In the case of GitLab’s incident, rm -i would not have helped: the ops knew which directory he was going to delete, but forgot about which machine he was on. He could have typed “yes” and hit the “return”.

对于GitLab事件， rm -i不会有所帮助：ops知道他要删除哪个目录，但忘记了他所在的机器。 他本可以键入“是”，然后单击“返回”。

Safe-rm (Safe-rm)

Similarly, Safe-rm wouldn’t have helped, either. Safe-rm has a configuration file that contains a list of paths you want to protect. It comes with some default paths such as /usr/lib. Users can also create their own lists of paths. What Safe-rm does is providing an extra warning beforehand, which gives no extra information about why it is stopping you.

同样， Safe-rm也无济于事。 Safe-rm有一个配置文件，其中包含要保护的路径列表。 它带有一些默认路径，例如/usr/lib 。 用户还可以创建自己的路径列表。 Safe-rm所做的事是事先提供一个额外的警告，它没有提供任何有关阻止它的原因的信息。

Think about the GitLab’s situation: ops could have just hit “y” (he would have thought it was not a production database, why not hit “y”?). Plus, Safe-rm does not provide symbolic link and recursion protection.

考虑一下GitLab的情况：ops可能只是打“ y”(他会以为这不是生产数据库，为什么不打“ y”？)。 另外， Safe-rm不提供符号链接和递归保护。

Sorry, Safe-rm. (Another tool is called rmfd, a fork from GNU coreutils with similar protection mechanism)

对不起， Safe-rm 。 (另一个工具称为rmfd ，它是来自GNU coreutils的具有类似保护机制的fork)

trash-cli (trash-cli)

The only tool I found useful for GitLab’s situation is trash-cli. So far it’s the best solution I know. It brings trashcan to the command line. trash-cli surely can prevent about 90% of the accidents (including GitLab’s).

我发现对GitLab情况有用的唯一工具是rash trash-cli 。 到目前为止，这是我所知道的最好的解决方案。 它将垃圾桶带到命令行。 当然， trash-cli可以防止大约90％的事故(包括GitLab事故)。

But what if you realize something’s missing long after emptying the trash.

但是，如果您在清空垃圾桶很久之后才发现某些东西丢失了，该怎么办。

Or imagine you are running out of space, but you have tons of data to write on the disk. You’re in rush to free up space (like removing the database filled with spam messages). Would you still carefully check the trash?

或假设您的空间不足，但磁盘上有大量数据要写入。 您急于释放空间(例如删除填充有垃圾邮件的数据库)。 您还会仔细检查垃圾桶吗？

So trash-cli wasn’t the ultimate solution I was searching for.

因此， trash-cli并不是我正在寻找的最终解决方案。

寻找灵感 (Searching for Inspiration)

The bathroom has always been a great place for eureka.

浴室一直是尤里卡的好地方。

It was 11 pm. I took a shower and I kept talking to myself through a solution for preventing GitLab’s incident.

是晚上11点。 我冲了个澡，然后通过防止GitLab事件的解决方案不断与自己对话。

“What exactly causes accidents like the one happened in GitLab?”

“到底是什么导致像GitLab那样的事故发生的呢？”

“Not knowing what you’re doing.”

“不知道你在做什么。”

It was still in the middle of spring break, and there was nobody around at my university. So I could talk to myself in the bathroom without people thinking I was crazy.

那时还处于春假的中期，我的大学里没人。 这样我就可以在洗手间和自己聊天，而不会有人认为我发疯了。

“How do you let users know clearly what they are doing?”

“如何让用户清楚地知道他们在做什么？”

“Hmmm, maybe by making them say it out loud?”

“嗯，也许是让他们大声说出来？”

I rushed out of the bathroom.

我冲出浴室。

发明工具 (Inventing the Tool)

I immediately messaged my friends about my idea: users “protect” important files and directories during the deployment period. The protection is done by setting a safety question and an answer.

我立即向朋友们传达了我的想法：用户在部署期间“保护”了重要的文件和目录。 通过设置安全问题和答案来完成保护。

Imagine this: when GitLab ops deploys databases to the production server, they also “protect” the directories of databases by setting up a question “What database are you deleting? (db1/db2)” and an answer “db1”.

想象一下：当GitLab ops将数据库部署到生产服务器时，它们还会通过设置问题“您要删除哪个数据库？”来“保护”数据库目录。 (db1 / db2)”和答案“ db1”。

Afterwards, upon any attempt to remove these directories, a modified version of rm will ask you the question. Unless you know the answer right, you won’t be able to proceed.

然后，在尝试删除这些目录时， rm的修改版本将询问您问题。 除非您知道正确的答案，否则您将无法继续。

GitLab’s ops couldn’t possibly enter “db1” when he thought it was “db2”. By making sure he knew what he was doing, GitLab’s database could have been saved.

当GitLab的操作程序认为它是“ db2”时，可能无法输入“ db1”。 通过确保他知道自己在做什么，可以保存GitLab的数据库。

So I wrote a Python script named “rm-p.py”. It’s a wrapper for rm that checks if a corresponding .<filename>.rm-protection (which I call a “protection file”). The prompt asks the question defined in the protection file when it can be found.

因此，我编写了一个名为“ rm-p.py”的Python脚本。 它是rm的包装程序，用于检查是否有相应的.<filename>.rm-prot (我称为“保护文件”)。 提示会询问何时可以在保护文件中定义的问题。

If you get the answer right, rm-p.py will pass your argument to rm. If you don’t, it doesn’t. Of course, it will still pass non-protected files to rm.

如果您得到正确的答案， rm-p.py会将您的参数传递给rm 。 如果您不这样做，那就不会。 当然，它将仍然将不受保护的文件传递给rm 。

I called this little script rm-protection and made a logo for it.

我称这个小脚本为rm-protection并为其制作了徽标。

Now the package rm-protection is available on PyPi and the source code is on GitHub.

现在rm-protection软件包在PyPi上可用，源代码在GitHub上 。

最终保护您的是什么？ (What ultimately protects you?)

For companies and teams, backup are surely the most important protection for data loss. It not only shields you from fat-fingerings, but also natural disasters.

对于公司和团队而言，备份无疑是防止数据丢失的最重要保护。 它不仅可以保护您免受胖手指的伤害，还可以保护您免受自然灾害的伤害。

But for individuals, comprehensive backups aren’t always economical or convenient.

但是对于个人而言，全面备份并不总是经济或方便的。

Putting a lack of backup aside, bad habits are almost always the source of these fat-fingerings.

除了缺乏备份，不良习惯几乎总是这些胖手指的根源。

We invented so many tools to deal with these bad habits, yet they may cause users to form new bad habits.

我们发明了许多工具来应对这些不良习惯，但它们可能会导致用户形成新的不良习惯。

“The best and the only right way to double check what you are going to delete.”

“最好的，唯一的正确方法是再次检查要删除的内容。”

Or so some may say. But few can live with having to confirm every single deletion. Thus, rm -rf is their new bad habit.

也许有人会说。 但是很少有人必须确认每个删除。 因此， rm -rf是他们的新坏习惯。

Current tools either protect you before (like rm -i or safe-rm) or after (trash-cli) accidental deletions. The former ones often bring more troubles than expected in daily operations.

当前的工具在意外删除之前(例如rm -i或safe-rm )或之后(( trash-cli ))为您提供保护。 前者通常带来比日常操作更多的麻烦。

The latter ones like trash-cli does not provide protection upfront. Chances are, you’ll still lose the important file.

后者(例如， trash-cli不会预先提供保护。 很有可能，您仍然会丢失重要文件。

After putting some thought into the issue, I realized that there’s no such thing as ultimate solution.rm-protection is just another layer of protection. It is not the most vital part of the protection, but it can save you tons of time for recovering your data from backups.

在对问题进行思考之后，我意识到没有最终解决方案。 rm-protection只是另一层保护。 它不是保护中最重要的部分，但可以为您节省大量时间来从备份中恢复数据。

rm-protection does not bother you when it is not necessary, so you still have the flexibility and efficiency for daily operations. When it is truly important that you should not delete something, it asks you a question set by you.

rm-protection 不需要时不会打扰您 ，因此您仍具有日常操作的灵活性和效率。 当您不应该删除某些东西确实很重要时，它会问您一个问题。

To be 99% safe, what you need is a combination of good habit, careful and clear mind, working backups, a good protection method, and luck.

为了达到99％的安全，您需要的是良好的习惯，谨慎而清晰的头脑，有效的备份，良好的保护方法以及好运的组合。

最佳实践 (The Best Practice)

To sum up, you should do the following to ensure the safety of your data:

综上所述，您应该执行以下操作以确保数据的安全性：

1. Do backups.

   做备份 。

2. Check backups regularly.

   定期检查备份 。

3. Keep a clear head. Don’t use rm -rf.

   保持头脑清醒。 不要使用rm -rf 。

4. Add an additional protection layer: choose rm-protection, trash-cli or whichever tool you like.

   添加额外的保护层：选择rm-protection ， trash-cli或您喜欢的任何工具。

And you should be 99% safe.

而且您应该安全99％。

翻译自: https://www.freecodecamp.org/news/why-and-how-i-created-a-new-wheel-to-prevent-gitlabs-disaster-b8cd5bea6e1/

prm灾难恢复工具