Docker compose backup mongo

Community Support
,
1

Description

this is an issue that I really don’t understand what’s causing it

first, I created a backup of the mongo using the following command:

docker exec db sh -c "mongodump --archive" > db.dump

to make sure this is working, i deleted the containers I already had, then ran a new mongo container, and restored the mongoDB using:

docker exec -i bd sh -c "mongorestore --archive" < db.dump

and it worked, when opening rocket chat all the messages, the custom settings are still the same.

the problem is when moving to docker-compose, this doesn’t seem to work the same way. I created three containers of Mongo, one for the main DB, one that initializes the replica sets, and the third one restores the data into the first one, the docker-compose file is looks like this:

services:
  #this is the main mongo database that rocket chat container will be communicating with
  db:
    restart: unless-stopped
    image: mongo:4.4
    ports:
      - "27017:27017"
    command: mongod --oplogSize 128 --replSet rs0
    container_name: db
  # this container's job is just run the command to initialize the replica set. it will run the command and remove himself
  mongo-init-replica:
    image: mongo:4.4
    volumes:
      - ./db.dump:/db.dump:chmod=600
      - ./init-replica.sh:/init-replica.sh
    command: /init-replica.sh
    depends_on:
      - db
    container_name: mongo-init-replica
  # container that restores the data from a db.dump file
  mongo-restore:
    image: mongo:4.4
    volumes:
      - ./db.dump:/db.dump:chmod=600
      - ./mongo-restore.sh:/mongo-restore.sh
    command: /mongo-restore.sh
    depends_on:
      - db
    container_name: mongo-restore
    # this container is the rocket chat container that uses the mongo service as its mongo database
  rocketchat:
    restart: unless-stopped
    container_name: rocketchat
    image: rocket.chat:5.2.0
    volumes:
      - ./rocket-chat.sh:/rocket-chat.sh
    command: /rocket-chat.sh
    ports:
      - "80:3000"
    depends_on:
      - db
    environment:
      - ROOT_URL=https://localhost
      - MONGO_URL=mongodb://db:27017/rocketchat?replicaSet=rs0&directConnection=true
      - MONGO_OPLOG_URL=mongodb://db:27017/local?replicaSet=rs0&directConnection=true

as per the scripts involved, they look something like this :
init-replica.sh

#!/bin/bash

# Loop for 20 times
for i in $(seq 1 20); do
    # Initialize MongoDB replica set
    mongo db/rocketchat --eval 'rs.initiate({ _id: "rs0", members: [ { _id: 0, host: "localhost:27017" } ]})'
    s=$?
    # If successful, break out of the loop
    if [ $s -eq 0 ]; then
        break
    else
        echo "Tried $i times. Waiting 5 secs..."
        sleep 5
    fi
done

# exit container
exit $s

mongo-restore.sh

#!/bin/bash

# Sleep for 10 seconds, then restore MongoDB from dump
echo 'waiting for database to be initialized'
sleep 10

# Mongo restore data into our mongo container
mongorestore --archive=/db.dump --host db

# Store the exit status of mongorestore command
s=$?

# Stop container and exit
exit $s

rocket-chat.sh

#!/bin/bash

# Sleep for 30 seconds
echo 'rocket chat waiting to start'
sleep 30

# Loop for 30 times
for i in $(seq 1 30); do
    # Run main.js using node
    node main.js
    s=$?
    # If successful, break out of the loop
    if [ $s -eq 0 ]; then
        break
    else
        echo "Tried $i times. Waiting 5 secs..."
        sleep 5
    fi
done

# Exit with the status code of the last executed command
exit $s

when running docker-compose up, the logs of mongo-restore show that the operation was successful (as the following image shows), however when launching rocket chat, it takes me to the initial wizard setup, with all the configurations back to the default ones. it basically behaves as if there is no data in the mongo containers, but i double-checked that there is

image
image1482×823 72.8 KB

Server Setup Information

image

2

Hi! :hugs:

When restoring the mongodb at the new server, you’ll want to add --drop, like so:

docker exec -i bd sh -c "mongorestore --archive --drop" < db.dump

this will drop any existing collection and restore it with the the ones from your backup.

let me know if this helps :slight_smile:

2 Likes
3

Hello! :smile:

I figured out what was causing the issue

turns out that with docker-compose, the pseudo-tty allocation needs to be desactivated when dumping the MongoDB into a db.dump file

in other words, if i can explain it accurately, the db.dump file was the backup of a rocket chat server running on docker that i created using this command docker exec db sh -c "mongodump --archive" > db.dump, and it had compatibility issues with the docker-compose server, even tho the data is already there but it couldn’t read it, if this makes sense.

so what i did is, I created a new rocket chat server using docker-compose, added the custom css and the members and the channels to the server, then backed up all this data using the following command:

docker-compose exec -T mongo sh -c 'mongodump --archive' > db.dump

when I ran docker-compose up using the db.dump that was generated this time, it worked as expected

thanks for the support! :smiley: