Reset the database

It is often useful to restart RadGrad with a new database. This involves:

  1. Stopping the current RadGrad service.
  2. Dropping the MongoDB RadGrad database.
  3. Edit the settings.json file to point to the new database to load on startup.
  4. Update the settings in mup and restart the RadGrad service.

1. Stop RadGrad

First, stop the RadGrad service:

mup stop

Sample invocation and results:

app/.deploy $ mup stop
Started TaskList: Stop Meteor
[] - Stop Meteor
[] - Stop Meteor: SUCCESS

2. Make backup of current database


The following command, although taken straight from the meteor up documentation (, did not work for me:

ssh root@host "docker exec mongodb mongodump -d meteor --archive --gzip" > dump.gz

Where "root@host" is replaced by the one appropriate for your instance, such as "" or "".

So, to make a backup, you should login as an administration and use the "dump database" option.

3. Drop database

Next, drop the database by invoking this command:

ssh 'docker exec mongodb mongo radgrad --eval "db.dropDatabase();"'

If you are not deploying the ICS instance of RadGrad, then you need to substitute a different user for in the above command.

For example, in the case of the Computer Engineering instance, the user is

In either case, you will be prompted for the associated password in order to complete the ssh login process and execute the drop database command.

Sample invocation and results:

app/.deploy $ ssh 'docker exec mongodb mongo radgrad --eval "db.dropDatabase();"'
MongoDB shell version v3.4.1
connecting to: mongodb://
MongoDB server version: 3.4.1
{ "dropped" : "radgrad", "ok" : 1 }

4. Edit settings

Presumably you are dropping the current database in order to load a new snapshot of the database.

To do this, edit the app/.deploy/settings.json file to specify the new database.

This usually involves changing the value of the field "databaseRestoreFileName".

5. Deploy with updated settings

Next, invoke mup deploy to rebuild and redeploy RadGrad.

mup deploy

Sample invocation and results:

app/.deploy $ $ mup deploy
Building App Bundle Locally
Started TaskList: Pushing Meteor App
[] - Pushing Meteor App Bundle to the Server
[] - Pushing Meteor App Bundle to the Server: SUCCESS
[] - Prepare Bundle
[] - Prepare Bundle: SUCCESS
Started TaskList: Configuring App
[] - Pushing the Startup Script
[] - Pushing the Startup Script: SUCCESS
[] - Sending Environment Variables
[] - Sending Environment Variables: SUCCESS
Started TaskList: Start Meteor
[] - Start Meteor
[] - Start Meteor: SUCCESS
[] - Verifying Deployment
[] - Verifying Deployment: SUCCESS
app/.deploy $

6. Check status of deployment through logs

To ensure that what you wanted to have happen actually happened, check the logs with mup logs:

mup logs

Sample invocation and results:

mup logs
[]=> Starting meteor app on port:3000
[]Monti APM: completed instrumenting the app
[]Beginning startup.
[]Invoking defineAdminUser
[]Defining admin with password JZiOl550tBtMuHz0UzNGZEC
[]Invoking loadDatabase
[]Monti APM: Successfully connected

7. Run mup logs, record new admin password!

Record new admin password!

Note that when you start up the system with a new database, a new admin password will be generated and the log file will be the only place it is made available. The log is only available until the next deploy of the system, so be sure to invoke mup logs, find the log message with the new admin password, and record it someplace safe.

Last updated on by Philip Johnson