-
Notifications
You must be signed in to change notification settings - Fork 10
Backup strategy
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 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 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.
We want to be able to restore Redis and mongo in such a way that the application can handle it.
We want a new server running the 4 applications (web-proxy, jslib, chrome-extension and core) up and running in 30 minutes.