Backups

Requires Pro (CreateBackup). See Plans and Pro features.

TableCore writes backups with the MongoDB driver rather than by running mongodump. A desktop application cannot assume the MongoDB command-line tools are installed on your machine.

#The archive is a mongodump archive

This is worth saying loudly, because it is worth more to you than hiding it would be: a TableCore backup can be restored with mongorestore, and TableCore can restore a dump made with mongodump.

<archive>/backup.json                            TableCore's manifest
<archive>/<database>/<collection>.bson           documents, raw BSON, one after another
<archive>/<database>/<collection>.metadata.json  collection options and indexes

The .bson file is exactly what mongodump writes. The .metadata.json file is Canonical Extended JSON holding the collection's options and its indexes. backup.json is ours and mongorestore ignores it.

#Compression

Compression is optional, with three levels: fastest, balanced, smallest.

A compressed backup is one .zip for the whole database, not a file per collection. Inside it is exactly the layout above, so unzipping gives you a directory mongorestore reads with no conversion at all. Gzipping each file individually — what mongodump --gzip does — would give you N files instead of one, so TableCore does not write that.

Zip rather than tar.gz for a practical reason: restoring reads individual entries (the manifest, one collection) without unpacking everything, and listing your backups only needs to read backup.json.

An uncompressed backup stays a directory. Without a container there is no way to have one file, and a directory is what the MongoDB tools read directly.

TableCore reads all of these back: a plain directory, a directory of .gz files from mongodump --gzip, its own .zip, and even a --gzip dump that somebody zipped.

#What is in it, and what is not

In: every document of every collection in scope, each collection's options (capped, validator and the rest), and its indexes.

Not in: users and roles, server configuration, the oplog, and anything else that belongs to the server rather than to the database. A TableCore backup restores your data and the shape of your collections. It is not a disaster recovery plan for a MongoDB deployment.

The manifest describes the source, the moment and the document counts. An archive with no manifest is described from its directory layout and is still restorable — the document count is then reported as unknown, because counting would mean reading every file.

#Scope

A backup covers a database or a single collection. The archive layout is the same either way, so both restore through the same path.

Both are on the context menu: Back up database and Back up collection.

#Where backups go

The default is the backup directory in Settings, and when that is empty, %LOCALAPPDATA%\TableCore\backups.

Nothing stops you pointing it at a network share or an external disk, and for anything you actually care about you should. A backup on the same disk as the database survives roughly the failures that were not going to be a problem.

#What it costs

Backing up reads every document of every collection in scope, over your connection to the server. On a large collection that is:

• time proportional to the data, not to the number of collections,
• disk roughly the size of the data uncompressed, less with compression,
• load on the server, which is doing the reading.

Backups report into the same status channel as every other operation counted in minutes, so the status bar shows progress and lets you cancel.

#Next

Restoring a backup — including how to check that a restore actually worked, which is the half people skip.