What’s new in BOSH — March Issue
Is two already a series? Why not.
As the PM of the Bosh OpenStack CPI I get to play around with Bosh a lot and have fun with its quirks and subtleties. The learning curve is quite interesting, as pointed out by smarter people before me, so I’d like to compile a few things that hopefully can make your life easier.
This is the second post in a series. Find the first one here.
Everything below works with v255.3 of Bosh and the corresponding CLI v1.3202.0. If you’re on an older version, things may or may not work.
Backup/restore of the Director Database
For quite some time the Bosh CLI offered a command to backup your Director.
$ bosh backup
Acting as user ‘admin’ on ‘inner-bosh’
Director task 269
Started backing up director
Started backing up director > Backing up database. Done (00:00:01)
Task 269 done
Started 2016–03–01 13:03:37 UTC
Finished 2016–03–01 13:03:38 UTC
Backup of BOSH director was put in `/Users/vcap/deployments/bosh /bosh_backup_inner-bosh_1456837413.tgz’.
It creates a file containing unix timestamp in UTC, in this case 1456837413 means Tue, 01 Mar 2016 13:03:33 GMT. Note that this file is quite small, as it only is a snapshot of the database and does not contain the blobstore or anything else.
So now we have a backup, but what about restore? Be sure to use the same Director version where the backup was taken from!
$ bosh restore bosh_backup_inner-bosh_1456837413.tgz
You are going to restore the director’s database.
THIS IS A VERY DESTRUCTIVE OPERATION WHICH WILL DROP CURRENT DATABASE.
IT CANNOT BE UNDONE!
Now your database reports a bunch of releases
$ bosh releases
| Name | Versions | Commit Hash |
| dummy | 0+dev.2 | e1ffce69+ |
However, if you don’t have an external blobstore, you don’t have the blobs anymore. So go ahead and re-upload them with the `fix` parameter
$ bosh upload release <release name> --fix
And also re-upload your stemcells
$ bosh upload stemcell <stemcell name> --fix
And then you can deploy as usual.
If you’re like us and update your Director pretty aggressively, this now allows for rolling back the Director’s version. Simply downgrading doesn’t work most of the time, due to database migrations in the Director’s schema. With this process at hand, you can do a backup every time before an upgrade and simply roll back if it doesn’t work out!
At some point in time, a script might come in handy, which automates all the re-uploading, so you don’t have to think when things go belly-up.
Did you know?
You can use URLs in the `releases` and `stemcells` sections of your manifest:
- name: bosh-openstack-cpi
And you’ll see something like this before the usual manifest diff and deploy:
Checking whether release bosh-openstack-cpi/ already exists…NO
Using remote release `https://bosh.io/d/github.com/cloudfoundry-incubator/bosh-openstack-cpi-release?v=23'
Using remote stemcell `https://bosh.io/d/stemcells/bosh-openstack-kvm-ubuntu-trusty-go_agent?v=3202'
No need to manually `bosh upload release <url>` or `bosh upload stemcell <url>` before deploying!