Lost all my data ? Help please
-
Just bind redis to localhost. Then it's won't be accessible from the outside world.
By default redis listens to all interfaces which means all external ips (unless you have some firewall in place)./etc/redis/redis.conf:add
bind 127.0.0.1Edit: Damn @julian you beat me.
-
@julian If this doesn't happen can we atleast add a warning to the NodeBB documentation for this?
-
Please if we supposed the backup was actived by default, how can I find the dump.rdb ? or maybe how can I check if it's activated ? I just want to be sure that there is no hope to get back my website. That's mean I lost nine months of work and now I will give up and stop hosting it...
-
@kacemlight said:
Please if we supposed the backup was actived by default, how can I find the dump.rdb ? or maybe how can I check if it's activated ? I just want to be sure that there is no hope to get back my website. That's mean I lost nine months of work and now I will give up and stop hosting it...
What backup would that be? if you didn't set it up, there is no backup. If you did, you would likely know where it was.
Do this...
find / -name dump.rdbDoubt that you are going to find anything, but only takes a minute to be sure.
-
You have to create your own redis backup script that rotates/saves dump files. By default redis does not make any incremental and or multiple save files.
So if someone connect to your redis instance and do ```flushall`` your database will be gone again. Because the empty db get saved to disk in a few minutes (overwriting your old save-file).
-
@kacemlight I'm sad to say that if you didn't provide your own backup solution. The database will be lost forever. I hope you can still see something in your hosting though.
-
@scottalanmiller Its that or having more people complain about lost databases, either way it looks bad for NodeBB as a whole. There is nothing wrong with the software, and we are a supportive community. So adding a warning for this bug or exploit or however you want to call it is the least we can do.
-
@Kowlin said:
@scottalanmiller Its that or having more people complain about lost databases, either way it looks bad for NodeBB as a whole. There is nothing wrong with the software, and we are a supportive community. So adding a warning for this bug or exploit or however you want to call it is the least we can do.
I suppose. It seems a bit over the top. We would need to put in mentions of backups, good passwords, firewalls, etc.
-
That reminds me, I was thinking that what we need is a knowledge base. Though this forum largely serves that purpose, a purpose-built knowledge base made to answer questions via a multiple of keywords would really be great.
The community could submit articles and edit them. There are open source wiki engines and knowledge base systems that could be used. The docs were created some time ago and are not living documents as much as wikis are. The docs should not go away, but a wiki could be added to by approved members in an adhoc fashion.
Everyone here knows important things from using the software. However, answering the same questions repeatedly will cause fatigue.
-
Not a bad idea. A wiki would be especially useful.
-
I do not see a lot of sense into a Wiki. The current doc system can be updated over GitHub as well and actually has a better implementation of code/command elements.
@scottalanmiller , it is everything else than extreme to use a firewall. In general it is "suicide" for the server to allow all connections. Ubuntu, CentOS and Co. don't feature these tools just for fun. It is somehow like leaving Port 22 open, disabling SSH Protocol 2 and then hoping that no one will access the server.
-
@bitspook there's already a documentation repository, (at docs.nodebb.org) specifically for this purpose, open source and everything (though it could use some maintenance).
Including tutorials on how to secure your instance would be overkill, but a reference for people who are doing this for the first time would probably be good
I was thinking of doing this actually when I got some time, but if someone else gets to it, it should at least include the basics like- ssh access
- using keys instead of passwords
- disallow login as sudo
- changing the default port
- firewalls
- setting up a new user (so as only to sudo when you need to)
- importance of enabling 2FA for your DO account (one of our members had his instances wiped because someone broke into his login)
If you haven't been keeping up on the security breaches as of late, you won't be as mindful of these things
- ssh access
-
I second this. A keyword based community Wiki would be a great idea. A process like configuring or securing redis is definitely something everyone should know, and being able to locate it, without work from other users is a good idea, that will educate many, and inconvenience few, as there will be there duplicate posts and questions.
-
just found this in the syslog of my server:
Nov 11 11:26:05 web02 redis[3992]: WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.It seems that virtual machines need an additional setting to get redis working securely...
-
Redis does require roughly 2x the dataset size in memory in order to persist to disk properly. If you have a large forum (e.g. 300mb dataset) on a small machine (e.g. 512mb memory), it is possible that the database will not be persisted because Redis can't properly make a copy of the db in-memory.
This was the main reason we switched to MongoDB, but Redis datasets are fairly small anyhow.
-
@Kowlin said:
Well am I the only one a bit troubled about the fact that the default Redis security is so easy to avoid. I opened my Redis port from my router and connected to it without any single problem...
What do you mean? ... any database is quite easy to get in if the guy that has set it up is not taking any security measures...
use IP tables and block the port, boom noone can connect apart from your localhost... and put a password on the config file(just for additional security)... thats all it needs
My get would be that any db you use u'd want to do the same unless you want to have remote access to that db, which makes no sense in the modern world we live in cause exposing your db to the public is just BAD. A db nowadays should be clearly set to be accessed on a localhost level only and then you can use an api to access its data from another connection.
