Base de Conhecimento

We recently added the ability to use a remote MongoDB database with JetBackup v5.4.0 and above. Due to this new addition, there is risk for improperly configured or misconfigured systems to return slow MongoDB responses, delayed JetBackup operations, or intermittent connectivity issues when communicating with MongoDB instances.

JetBackup relies on consistent and fast communication with MongoDB for indexing, job tracking, and internal operations. If connectivity between the server and MongoDB is slow or unstable, backup jobs may take longer than expected or encounter timeouts.

If you experience performance or connectivity issues, please review the recommendations below based on your configuration.

Installing a Remote MongoDB Server

Please note that the installation links referenced in this section will become publicly accessible once JetBackup v5.4 is officially released.

To prepare a server for use as a remote MongoDB instance for JetBackup, run the following commands on the remote server before installing JetBackup.

These scripts install and configure the required MongoDB components automatically.

After the installation completes, the server will be configured to function as a remote MongoDB backend for JetBackup.
Once completed, proceed with installing JetBackup on your backup server and configure it to use the remote MongoDB instance.

To install JB5 please run the command, replace PANEL with the panel you wish to use (ie. cpanel)

jetapps --install jetbackup5-cpanel release

For more info visit our install guide here: https://docs.jetbackup.com/v5.3/adminpanel/generalInformation.html

Remote MongoDB Installation Prompts Explained

During the jetmongo-remote-install process, you will be prompted for several configuration values. Below is a brief explanation of each field.

Authentication Database

Typically set to admin. This is the database MongoDB uses to verify the username and password during login. In most deployments, authentication is handled through the admin database.

MongoDB Host

The address MongoDB listens on for connections. Use the server’s IP address when configuring a remote MongoDB server.

If using the local jetmongod service, do not run the jetmongo-remote-install script. The local jetmongod instance is automatically configured during JetBackup installation.

MongoDB Port

The port MongoDB uses for communication. The default port for remote MongoDB installations is 27017.

MongoDB Username

The database user JetBackup will use to authenticate and perform database operations. Ensure that the database user has full read and write access to the configured database.

MongoDB Password

The password associated with the MongoDB user above.

MongoDB Database Name

The database where JetBackup stores its internal data. If the database does not already exist, it will be created automatically during setup.

Use a name that clearly identifies the server, for example:

Remote MongoDB Configuration

When using a remote MongoDB server, most issues are related to networking, routing, firewall rules, or DNS configuration between the JetBackup server and the database host.

Verify MongoDB and Server Geographic Location

MongoDB performs best when hosted within the same geographic region or datacenter as the JetBackup server. Hosting MongoDB far from the backup server increases latency and may slow database queries.

Whenever possible, keep both systems within the same provider network or geographic region.

Check Network Route Using traceroute or MTR

Network routing problems between servers can introduce latency or instability.

Run the following commands from the JetBackup server.

traceroute: This command shows each network hop between your server and the MongoDB host and helps identify where delays occur along the route.

traceroute <mongodb-hostname>

mtr --report: This command combines ping and traceroute results to provide a summary showing latency and packet loss across all network hops.

mtr --report <mongodb-hostname>

Look for:

• High response times between hops

• Packet loss

• Unstable routing paths

Check for Packet Loss or High Latency

High latency or packet loss can significantly impact MongoDB's responsiveness. Even relatively small values such as 1–5% packet loss can cause noticeable delays or intermittent database issues.

The tools above can help identify connection instability between the JetBackup server and MongoDB.

When reviewing MTR results:

• Latency should remain low and consistent

• Packet loss should be 0%

Latency spikes or packet loss usually indicate network congestion or routing issues between the JetBackup server and the MongoDB host. If packet loss is observed, we recommend reaching out to your datacenter or remote MongoDB service provider so they can investigate routing or connectivity problems further.

Verify DNS Resolution

Slow or incorrect DNS resolution may delay database connections.

Use one of the following commands to test hostname resolution.

dig: Queries DNS servers directly and shows how quickly the hostname resolves along with returned records.

dig <mongodb-hostname>

nslookup: Performs a DNS lookup to confirm the hostname resolves to the expected IP address.

nslookup <mongodb-hostname>

Verify that:

• The hostname resolves quickly

• The returned IP address is correct

• No noticeable lookup delay occurs

Verify Firewall or CSF Rules

Firewalls or CSF configurations may block MongoDB communication or prevent access to cluster members.

MongoDB clusters may redirect connections between multiple nodes. If some nodes are blocked, connections may timeout or become slow.

Ensure:

• Outgoing connections are allowed

• MongoDB hosts are not blocked

• All cluster members are reachable

Verify Outgoing Connectivity to the Configured MongoDB Port

MongoDB communication requires outbound connectivity to the configured MongoDB port. Standard MongoDB installations typically use port 27017, while the local JetBackup The jetmongod service uses port 27217 by default.

Use the commands below to confirm the port is reachable.

telnet: Attempts a direct TCP connection to verify the destination port is accessible.

telnet <mongodb-hostname> <port>

nc (netcat): Performs a quick connectivity test to confirm the port is open without starting an interactive session.

nc -zv <mongodb-hostname> <port>

A successful connection confirms the configured MongoDB port is reachable and not blocked by firewall or network restrictions.

Local MongoDB (Default jetmongod Service)

By default, JetBackup installs and uses a local MongoDB instance (jetmongod). When MongoDB runs locally, issues are typically related to server resource usage rather than networking.

Verify Jetmongod Service Status

Ensure the MongoDB service is running properly.

systemctl status: Displays the current state of the jetmongod service and whether it is active or failed.

systemctl status jetmongod

If necessary, restart the service.

service restart: Restarts the MongoDB service to clear temporary issues or stalled processes.

service jetmongod restart

Check Server Load

High system load may delay database responses.

uptime: Displays system uptime along with current load averages.

uptime

Verify that load averages are reasonable relative to the number of CPU cores.

Check CPU and I/O Wait

Disk bottlenecks can slow MongoDB operations.

top: Provides a real-time view of CPU usage, running processes, and I/O wait statistics.

top 

Review the wa (IOWait) value:

• Low values are expected

• Consistently high IOWait may indicate disk performance issues

Verify Available Disk Space

Low disk space can impact MongoDB performance or prevent normal operation.

df -h: Displays filesystem disk usage in a human-readable format.

df -h

Ensure sufficient free space exists on the filesystem where JetBackup data is stored.

If issues persist after performing the checks above, please open a support ticket and include relevant logs and test results so our support team can assist with further troubleshooting.