Awful tutorial for telling us how to secure our database and so that MongoDB doesn’t delete our data (!).
Clearly, it is not intended for novice people who want to use MongoDB along with their apps.
When a beginner understands and knows how to configure MongoDB only with your tutorial, then your doc is OK; meanwhile, you should improve to be understandable and human readable for beginner people.
I’m sorry to hear your deployment was not properly secured. Can you provide some more information on the specific version of MongoDB server you installed and a link to the tutorial you followed?
MongoDB 3.6+ only binds to localhost by default and there are multiple reminders about securing your deployment including:
Startup warning every time you connect to an unsecured deployment using the mongo shell:
[initandlisten] ** WARNING: Access control is not enabled for the database.
[initandlisten] ** Read and write access to data and configuration is unrestricted.
Enabling remote access to a deployment requires additional manual steps such as binding to non-localhost IP addresses. Defaults have been improved since earlier versions of the MongoDB server, but if you are installing on-premises software there is always some responsibility for fully securing your environment including exposure to remote network access.
MongoDB is a distributed database, so security configuration needs to be coordinated with all of the members of a cluster. There are multiple security mechanisms for administrators to choose from, and they have different configurations. This is more straightforward to configure using a managed service (for example MongoDB Atlas) where the management software has control over deploying and configuring the cluster and can enforce best practices like access control, network encryption, and firewall restrictions.
It is also important to note that security is only one aspect of production deployments. Backup, monitoring, and environment tuning should also be considered. The Operations Checklist and Production Notes in the MongoDB documentation include some considerations to avoid issues with your production MongoDB deployment.
If you have suggestions on how we can further improve the default server configuration to avoid missteps, any ideas would be appreciated. We have a public Feedback site for feature suggestions and product ideas, and you can also share thoughts in forum discussion.
Without a doubt, I understand that MongoDB, Inc.? is a big company full of brilliant minds available to think how to improve this product.
I understand you highlight the importance of my suggestions in order to improve your product and make money with them.
My ideas will make better your product. Feel free to reward them. Thanks.
My data were deleted because your fault and on top of that you want to receive a goodness.
I should at least be paid for my ideas, isn’t it?
Sorry for my rudeness but I need money to pay my bills. If you consider to pay my ideas to improve your product, you will always be welcome. It’s a win-win strategy.
If you wrote it, then you must know for sure. We can help you be sure if you share the code. On which media do you store the data. If on tmpfs or RAM disk then it may be normal that you lose the data at reboot. You need to share more details before you can blame MongoDB. Post a screenshot of Compass and before and after the delete. Sharing the configuration file you use for your service will also be helpful help you figure what went wrong with your installation.