First Question: In order for this communication to be secure, would it be a better idea to use HTTPS port 443 instead of that basic TCP port 27077 , then disable the HTTP interface in the mongo.conf file? Is that enough to make the communication secured?
--yes enough.As port and ip security is there apart from that you can use iptables for more security. As currently you are just preventing mongo attack only.
What would be the best way to always make sure the mongo server is always responsive or running? (for example if the server was rebooted, I need to make sure that the mongo is still running) or (to avoid mongodb.lock file) because I had that issue before.
-- if you are running it as service then lock file issue will not be there.in case you are using directly from bin then put it in rc.d simple.
advised you to create a script to check your server status and configure alerts accordingly.
BACKUP: As you are not using replica then simply mongodump will be advisable but you can also start your single machine as replica means without any secondary you will have oplog for incremental backup.
You can start instance with replset option or change in config file.
then below command.
>rs.initiate()
it will give you something like :
{
"info2" : "no configuration specified. Using a default configuration for the set",
"me" : "machine:27017",
"ok" : 1
}
check one oplog.rs will be there in local database.
Best Answer
As per MongoDB documentation here The Ops Manager Backup Agent provides scheduled snapshots and point-in-time recovery of your MongoDB replica sets and sharded clusters.
How it Works
A lightweight Backup Agent runs within your infrastructure and backs up data from the MongoDB processes you have specified.
Backup Data
When you start backing up a MongoDB deployment, the agent performs an initial sync of the deployment's data as if it were creating a new,
invisiblemember of a replica set. For a sharded cluster, the agent syncs each shard’s primary member and each config server. The agent sends the initial sync and oplog data over HTTPS back to Ops Manager.The Backup Agent then tails each replica set's oplog to maintain on disk a standalone database, called a head database. Ops Manager maintains one head database for each backed-up replica set. The head database is consistent with the original primary up to the last oplog supplied by the agent.
The Backup Agent executes the initial sync and the tailing of the oplog using standard MongoDB queries. The cluster being backed up is unaware of the additional copy of the backup data.
The Backup Agent uses a MongoDB instance version equal to or greater than the version of the replica set it backs up.
The Backup Agent takes and stores snapshots based on a user-defined snapshot retention policy. Sharded cluster snapshots temporarily stop the balancer so that they can insert a marker token into all shards and config servers in the cluster. Ops Manager takes a snapshot when the marker tokens appear in the snapshot data.
For further your ref here , here and here