← Back to branch summary

~themue/clouddocs/010-getting-charms

« back to all changes in this revision

Viewing changes to Backup-and-Recovery-OpenStack.md

  • Committer: evilnick
  • Date: 2014-04-02 16:56:29 UTC
  • mfrom: (9.1.1 trunk)
  • Revision ID: nick.veitch@canonical.com-20140402165629-dz05kuzoyojlgwzc
split out admin docs

Show diffs side-by-side

added added

removed removed

Lines of Context:
Backup-and-Recovery-OpenStack.md
 
1
Title: Backup and Recovery - OpenStack
 
2
Status: In Progress
 
3
 
 
4
# Backup and Recovery - OpenStack
 
5
 
 
6
## Introduction
 
7
 
 
8
The OpenStack flexibility makes backup and restore to a very individual process
 
9
depending on the used components. This section describes how the critical parts
 
10
like the configuration files and databases OpenStack needs to run are saved. As
 
11
before for Juju it doesn't describe ho to back up the objects inside the Object 
 
12
Storage or the data inside the Block Storage.
 
13
 
 
14
## Scope
 
15
 
 
16
**TODO**
 
17
 
 
18
## Backup Cloud Controller Database
 
19
 
 
20
Like Juju the OpenStack cloud controller uses a database server which stores the
 
21
central databases for Nova, Glance, Keystone, Cinder, and Switft. You can backup
 
22
the five databases into one common dump:
 
23
 
 
24
````
 
25
$ mysqldump --opt --all-databases > openstack.sql
 
26
````
 
27
 
 
28
Alternatively you can backup the database for each component individually:
 
29
 
 
30
````
 
31
$ mysqldump --opt nova > nova.sql
 
32
$ mysqldump --opt glance > glance.sql
 
33
$ mysqldump --opt keystone > keystone.sql
 
34
$ mysqldump --opt cinder > cinder.sql
 
35
$ mysqldump --opt swift > swift.sql
 
36
````
 
37
 
 
38
## Backup File Systems
 
39
 
 
40
Beside the databases OpenStack uses different directories for its configuration,
 
41
runtime files, and logging. Like the databases they are grouped individually per
 
42
component. This way also the backup can be done per component.
 
43
 
 
44
### Nova
 
45
 
 
46
You'll find the configuration directory `/etc/nova` on the cloud controller and 
 
47
each compute node. It should be regularly backed up.
 
48
 
 
49
Another directory to backup is `/var/lib/nova`. But here you have to be careful
 
50
with the `instances` subdirectory on the compute nodes. It contains the KVM images
 
51
of the running instances. If you want to maintain backup copies of those instances
 
52
you can do a backup here too. In this case make sure to not save a live KVM instance
 
53
because it may not boot properly after restoring the backup.
 
54
 
 
55
Third directory for the compute component is `/var/log/nova`. In case of a central
 
56
logging server this directory does not need to be backed up. So we suggest you to
 
57
run your environment with this kind of logging.
 
58
 
 
59
### Glance
 
60
 
 
61
Like for Nova you'll find the directories `/etc/glance` and `/var/log/glance`, the
 
62
handling should be the same here too.
 
63
 
 
64
Glance also uses the directory named `/var/lib/glance` which also should be backed
 
65
up.
 
66
 
 
67
### Keystone
 
68
 
 
69
Keystone is using the directories `/etc/keystone`, `/var/lib/keystone`, and
 
70
`/var/log/keystone`. They follow the same rules as Nova and Glance. Even if
 
71
the `lib` directory should not contain any data being used, can also be backed 
 
72
up just in case.
 
73
 
 
74
### Cinder
 
75
 
 
76
Like before you'll find the directories `/etc/cinder`, `/var/log/cinder`,
 
77
and `/var/lib/cinder`. And also here the handling should be the same. Opposite
 
78
to Nova abd Glance there's no special handling of `/var/lib/cinder` needed.
 
79
 
 
80
### Swift
 
81
 
 
82
Beside the Swift configuration the directory `/etc/swift` contains the ring files
 
83
and the ring builder files. If those get lest the data on your data gets inaccessable.
 
84
So you can easily imagine how important it is to backup this directory. Best practise
 
85
is to copy the builder files to the storage nodes along with the ring files. So
 
86
multiple copies are spread throughout the cluster.
 
87
 
 
88
**TODO(mue)** Really needed when we use Ceph for storage?
 
89
 
 
90
## Restore
 
91
 
 
92
The restore based on the backups is a step-by-step process restoring the components
 
93
databases and all their directories. It's important that the component to restore is 
 
94
currently not running. So always start the restoring with stopping all components.
 
95
 
 
96
Let's take Nova as an example. First execute
 
97
 
 
98
````
 
99
$ stop nova-api
 
100
$ stop nova-cert
 
101
$ stop nova-consoleauth
 
102
$ stop nova-novncproxy
 
103
$ stop nova-objectstore
 
104
$ stop nova-scheduler
 
105
````
 
106
 
 
107
on the cloud controller to savely stop the processes of the component. Next step is the
 
108
restore of the database. By using the `--opt` option during backup we ensured that all
 
109
tables are initially dropped and there's no conflict with currently existing data in
 
110
the databases.
 
111
 
 
112
````
 
113
$ mysql nova < nova.sql
 
114
````
 
115
 
 
116
Before restoring the directories you should move at least the configuration directoy,
 
117
here `/etc/nova`, into a secure location in case you need to roll it back.
 
118
 
 
119
After the database and the files are restored you can start MySQL and Nova again.
 
120
 
 
121
````
 
122
$ start mysql
 
123
$ start nova-api
 
124
$ start nova-cert
 
125
$ start nova-consoleauth
 
126
$ start nova-novncproxy
 
127
$ start nova-objectstore
 
128
$ start nova-scheduler
 
129
````
 
130
 
 
131
The process for the other components look similar.