Trying to migrate from Docker to Snap. Database stays empty after successful restore

Community Support
1

Description

I’m tasked with moving a RC Server from Docker to Snap. After some headaches with getting the Snap Instance to accept the archive file in the first place i finally got that to run through seemingly successful. I had to rename the db folder to “parties” and put it inside another folder called “dump” before tarballing it.

The rocketchat-server.restoredb process finishes successfully without any errors. I tried to log in with my test user but that didn’t work, so i checked the users collection in mongo db and it was entirely empty, except for the standard rocket.cat bot user. All other collections seem to be empty as well, except for default data.

What am i missing here or what did i do wrong?

Server Setup Information

  • Version of Rocket.Chat Server: 3.18
  • Operating System: Ubuntu Server 18.04
  • Deployment Method: snap
  • Number of Running Instances: 1

Any additional Information

Console output from the restore process:

[*] Extracting backup file...
[*] Restoring data...
[*] Preparing database...
[+] Restore completed! Please with 'sudo systemctl restart snap.rocketchat-server.rocketchat-server' to verify.

The entire users collection in the database, after restore (should have around 75 users):

rs0:PRIMARY> db.users.find().pretty()
{
        "_id" : "rocket.cat",
        "createdAt" : ISODate("2021-12-28T15:56:53.377Z"),
        "avatarOrigin" : "local",
        "name" : "Rocket.Cat",
        "username" : "rocket.cat",
        "status" : "online",
        "statusDefault" : "online",
        "utcOffset" : 0,
        "active" : true,
        "type" : "bot",
        "_updatedAt" : ISODate("2021-12-28T15:56:53.637Z"),
        "roles" : [
                "bot"
        ],
        "avatarETag" : null
}

edit:
I figured out that the Docker DB runs on version4.0.19 and te Snap Version runs on 3.6.14. So that must be the root cause here. Is there any way i can get around this?

edit2: it’s skipping every single bson file because they aren’t properly unpacked.

2

Hi!

I always suggest docker instead of snap. Docker is easy to maintain and to scale.

Any particular reason to going to snap?

Also, is a good idea to keep versions the same.

1 Like
3

My client wants to get away from Docker. His requirements are that it needs to be as dead simple as possible to update as well as to backup and restore data. Snap seems most fitting for the job. Scalability isn’t much of an issue either.

I managed to resolve the issues with the db dump itself, by the way. And it’s now applied as expected, however now the different versions between Docker and Snap are now causing me headaches.

I switched to the 4.x/stable track, because the Docker Installation runs on V4 as well. But now when i try to apply the dump it says “no reachable servers found”.

“rocketchat-server.mongo” also failes because the permission to connect gets denied.

Failed to connect to 127.0.0.1:27017, in(socket), reason: Permission denied
4

Ditto here. Can’t think of a valid enough reason why docker would not be simple to update and with ease to back up and restore data. That is kind of the whole point of containerization.

If this is a situation where the client wants easy commands to update, or perform backup tasks, a couple of simple wrappers could be written to allow for this and still leverage the advantages of docker.

But to each its own.

5

I appreciate your feedback on Snap and Docker. How ever i’m still looking for a technical solution on my problem with mongodb. I will make a new post for the isolated problem.