Skip to content
This repository has been archived by the owner on Mar 22, 2018. It is now read-only.

Backup strategy

Jan Paul Posma edited this page May 15, 2014 · 1 revision

In this document we describe the backup strategy we want to use. The measures that are already implemented are checked with a [DONE].

#Assumptions

We assume the following things won't happen (for now)

  • All servers die at once

#Data

We have to backup data from the following services/databases.

Mongo

Mongo doesn't really need to be actively backed up, you only need to ensure that you run mongo replicasets. To ensure we're save we want a replicaset of each mongo instance (testserver, staging, beta), on each physical machine (bd1,2,3).

However, since we'd still have a problem if a programmatical error leads to a DROP DATABASE situation, we'd want to backup Mongo just as much as we want with Redis.

Redis

Redis writes its data to a file (a log). We will rsync this file to other locations (other bigdudes, and maybe to the office).

  • todo: check if we can rsync a 'live' file.

Restoring data

We want to be able to restore Redis and mongo in such a way that the application can handle it.

Recovery procedure

We want a new server running the 4 applications (web-proxy, jslib, chrome-extension and core) up and running in 30 minutes.