All,

Beyond a couple of partially answered questions on the mailing lists, I've
been unable to find any documentation / guidance on backup and disaster
recovery with / of BOSH.

Please could you help me create some
at https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery

I'm assuming an inception server created
with https://github.com/cloudfoundry-community/inception-server and a
MicroBOSH created
with https://github.com/cloudfoundry-community/bosh-bootstrap

Disaster recovery for the inception server is pretty straight forward -
see https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#inception-server

I'm stuck with disaster recovery for the MicoBOSH
- https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#backup-procedure-1

I can see how bosh backup will make a .tgz of the director's data to
/var/vcap/store

However, I can't figure out how one would restore this data in the case of
your MicroBOSH instance being terminated.

Guidance? Advise?

Thanks!

;D

To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.

Search Discussions

  • Dr Nic Williams at Nov 3, 2013 at 5:57 pm
    Tammer/James/MattK/etc - how are Pivotal doing backup/restore of your
    microbosh?

    For any Pivots or people not using bosh-bootstrap, please still consider
    answering David - it does nothing special other than generate a functioning
    micro_bosh.yml and determine which stemcell/AMI to use.

    Backup/restore of microbosh is a critical part of living with Cloud Foundry.

    On Sun, Nov 3, 2013 at 9:35 AM, wrote:

    All,

    Beyond a couple of partially answered questions on the mailing lists, I've
    been unable to find any documentation / guidance on backup and disaster
    recovery with / of BOSH.

    Please could you help me create some at
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery

    I'm assuming an inception server created with
    https://github.com/cloudfoundry-community/inception-server and a
    MicroBOSH created with
    https://github.com/cloudfoundry-community/bosh-bootstrap

    Disaster recovery for the inception server is pretty straight forward -
    see
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#inception-server

    I'm stuck with disaster recovery for the MicoBOSH -
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#backup-procedure-1

    I can see how bosh backup will make a .tgz of the director's data to
    /var/vcap/store

    However, I can't figure out how one would restore this data in the case of
    your MicroBOSH instance being terminated.

    Guidance? Advise?

    Thanks!

    ;D

    To unsubscribe from this group and stop receiving emails from it, send an
    email to bosh-users+unsubscribe@cloudfoundry.org.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic

    To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.
  • David Laing at Nov 3, 2013 at 8:25 pm
    Totally agree with Dr Nic's request - any info on how to restore in a BOSH
    context would be most welcome.

    I think the core issue is that BOSH maps /var/vcap/data/ to ephemeral
    storage for BOSHes own VMs.

    For a none BOSH director VM this doesn't matter, since bosh cck will just
    recreate any missing VMs using the last spec, and reattach the persistent
    drives.

    However, in the case of BOSH director, the thing that manages the restore
    (the director) is the thing that needs to be restored...

    If there was a way to make /var/vcap/data/ persistent for the microbosh VM,
    then you could just do a simplistic make AMI backup / restore.

    D
    On 3 Nov 2013 17:57, "Dr Nic Williams" wrote:

    Tammer/James/MattK/etc - how are Pivotal doing backup/restore of your
    microbosh?

    For any Pivots or people not using bosh-bootstrap, please still consider
    answering David - it does nothing special other than generate a functioning
    micro_bosh.yml and determine which stemcell/AMI to use.

    Backup/restore of microbosh is a critical part of living with Cloud
    Foundry.

    On Sun, Nov 3, 2013 at 9:35 AM, wrote:

    All,

    Beyond a couple of partially answered questions on the mailing lists,
    I've been unable to find any documentation / guidance on backup and
    disaster recovery with / of BOSH.

    Please could you help me create some at
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery

    I'm assuming an inception server created with
    https://github.com/cloudfoundry-community/inception-server and a
    MicroBOSH created with
    https://github.com/cloudfoundry-community/bosh-bootstrap

    Disaster recovery for the inception server is pretty straight forward -
    see
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#inception-server

    I'm stuck with disaster recovery for the MicoBOSH -
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#backup-procedure-1

    I can see how bosh backup will make a .tgz of the director's data to
    /var/vcap/store

    However, I can't figure out how one would restore this data in the case
    of your MicroBOSH instance being terminated.

    Guidance? Advise?

    Thanks!

    ;D

    To unsubscribe from this group and stop receiving emails from it, send an
    email to bosh-users+unsubscribe@cloudfoundry.org.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic
    To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.
  • Dr Nic Williams at Nov 3, 2013 at 8:26 pm
    All microboshes have /var/vcap/store as a persistent disk. Perhaps we use that?
    On Sun, Nov 3, 2013 at 12:25 PM, David Laing wrote:

    Totally agree with Dr Nic's request - any info on how to restore in a BOSH
    context would be most welcome.
    I think the core issue is that BOSH maps /var/vcap/data/ to ephemeral
    storage for BOSHes own VMs.
    For a none BOSH director VM this doesn't matter, since bosh cck will just
    recreate any missing VMs using the last spec, and reattach the persistent
    drives.
    However, in the case of BOSH director, the thing that manages the restore
    (the director) is the thing that needs to be restored...
    If there was a way to make /var/vcap/data/ persistent for the microbosh VM,
    then you could just do a simplistic make AMI backup / restore.
    D
    On 3 Nov 2013 17:57, "Dr Nic Williams" wrote:
    Tammer/James/MattK/etc - how are Pivotal doing backup/restore of your
    microbosh?

    For any Pivots or people not using bosh-bootstrap, please still consider
    answering David - it does nothing special other than generate a functioning
    micro_bosh.yml and determine which stemcell/AMI to use.

    Backup/restore of microbosh is a critical part of living with Cloud
    Foundry.

    On Sun, Nov 3, 2013 at 9:35 AM, wrote:

    All,

    Beyond a couple of partially answered questions on the mailing lists,
    I've been unable to find any documentation / guidance on backup and
    disaster recovery with / of BOSH.

    Please could you help me create some at
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery

    I'm assuming an inception server created with
    https://github.com/cloudfoundry-community/inception-server and a
    MicroBOSH created with
    https://github.com/cloudfoundry-community/bosh-bootstrap

    Disaster recovery for the inception server is pretty straight forward -
    see
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#inception-server

    I'm stuck with disaster recovery for the MicoBOSH -
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#backup-procedure-1

    I can see how bosh backup will make a .tgz of the director's data to
    /var/vcap/store

    However, I can't figure out how one would restore this data in the case
    of your MicroBOSH instance being terminated.

    Guidance? Advise?

    Thanks!

    ;D

    To unsubscribe from this group and stop receiving emails from it, send an
    email to bosh-users+unsubscribe@cloudfoundry.org.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic
    To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.
  • David Laing at Nov 3, 2013 at 11:20 pm
    Out of interest, bosh backup on a microbosh puts the backup.tgz on
    /var/vcap/store

    Of course the backup mainly contains stuff that is already on
    var/vcap/store (eg postgres and the blobstore), and I can't find the
    corresponding bosh restore command.
    On 3 Nov 2013 20:26, "Dr Nic Williams" wrote:

    All microboshes have /var/vcap/store as a persistent disk. Perhaps we use
    that?

    On Sun, Nov 3, 2013 at 12:25 PM, David Laing wrote:

    Totally agree with Dr Nic's request - any info on how to restore in a
    BOSH context would be most welcome.

    I think the core issue is that BOSH maps /var/vcap/data/ to ephemeral
    storage for BOSHes own VMs.

    For a none BOSH director VM this doesn't matter, since bosh cck will just
    recreate any missing VMs using the last spec, and reattach the persistent
    drives.

    However, in the case of BOSH director, the thing that manages the restore
    (the director) is the thing that needs to be restored...

    If there was a way to make /var/vcap/data/ persistent for the microbosh
    VM, then you could just do a simplistic make AMI backup / restore.

    D
    On 3 Nov 2013 17:57, "Dr Nic Williams" wrote:

    Tammer/James/MattK/etc - how are Pivotal doing backup/restore of your
    microbosh?

    For any Pivots or people not using bosh-bootstrap, please still consider
    answering David - it does nothing special other than generate a functioning
    micro_bosh.yml and determine which stemcell/AMI to use.

    Backup/restore of microbosh is a critical part of living with Cloud
    Foundry.

    On Sun, Nov 3, 2013 at 9:35 AM, wrote:

    All,

    Beyond a couple of partially answered questions on the mailing lists,
    I've been unable to find any documentation / guidance on backup and
    disaster recovery with / of BOSH.

    Please could you help me create some at
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery

    I'm assuming an inception server created with
    https://github.com/cloudfoundry-community/inception-server and a
    MicroBOSH created with
    https://github.com/cloudfoundry-community/bosh-bootstrap

    Disaster recovery for the inception server is pretty straight forward -
    see
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#inception-server

    I'm stuck with disaster recovery for the MicoBOSH -
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#backup-procedure-1

    I can see how bosh backup will make a .tgz of the director's data to
    /var/vcap/store

    However, I can't figure out how one would restore this data in the case
    of your MicroBOSH instance being terminated.

    Guidance? Advise?

    Thanks!

    ;D

    To unsubscribe from this group and stop receiving emails from it, send
    an email to bosh-users+unsubscribe@cloudfoundry.org.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic
    To unsubscribe from this group and stop receiving emails from it, send
    an email to bosh-users+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.
  • David Laing at Nov 3, 2013 at 11:23 pm
    Is it not possible to do something along the lines of bosh micro deploy
    --with-persistent-disk=vol-xxxyyyy

    I.e, deploy a new microbosh and attach some existing data?
    On 3 Nov 2013 23:19, "David Laing" wrote:

    Out of interest, bosh backup on a microbosh puts the backup.tgz on
    /var/vcap/store

    Of course the backup mainly contains stuff that is already on
    var/vcap/store (eg postgres and the blobstore), and I can't find the
    corresponding bosh restore command.
    On 3 Nov 2013 20:26, "Dr Nic Williams" wrote:

    All microboshes have /var/vcap/store as a persistent disk. Perhaps we use
    that?

    On Sun, Nov 3, 2013 at 12:25 PM, David Laing wrote:

    Totally agree with Dr Nic's request - any info on how to restore in a
    BOSH context would be most welcome.

    I think the core issue is that BOSH maps /var/vcap/data/ to ephemeral
    storage for BOSHes own VMs.

    For a none BOSH director VM this doesn't matter, since bosh cck will
    just recreate any missing VMs using the last spec, and reattach the
    persistent drives.

    However, in the case of BOSH director, the thing that manages the
    restore (the director) is the thing that needs to be restored...

    If there was a way to make /var/vcap/data/ persistent for the microbosh
    VM, then you could just do a simplistic make AMI backup / restore.

    D
    On 3 Nov 2013 17:57, "Dr Nic Williams" wrote:

    Tammer/James/MattK/etc - how are Pivotal doing backup/restore of your
    microbosh?

    For any Pivots or people not using bosh-bootstrap, please still
    consider answering David - it does nothing special other than generate a
    functioning micro_bosh.yml and determine which stemcell/AMI to use.

    Backup/restore of microbosh is a critical part of living with Cloud
    Foundry.

    On Sun, Nov 3, 2013 at 9:35 AM, wrote:

    All,

    Beyond a couple of partially answered questions on the mailing lists,
    I've been unable to find any documentation / guidance on backup and
    disaster recovery with / of BOSH.

    Please could you help me create some at
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery

    I'm assuming an inception server created with
    https://github.com/cloudfoundry-community/inception-server and a
    MicroBOSH created with
    https://github.com/cloudfoundry-community/bosh-bootstrap

    Disaster recovery for the inception server is pretty straight forward
    - see
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#inception-server

    I'm stuck with disaster recovery for the MicoBOSH -
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#backup-procedure-1

    I can see how bosh backup will make a .tgz of the director's data to
    /var/vcap/store

    However, I can't figure out how one would restore this data in the
    case of your MicroBOSH instance being terminated.

    Guidance? Advise?

    Thanks!

    ;D

    To unsubscribe from this group and stop receiving emails from it, send
    an email to bosh-users+unsubscribe@cloudfoundry.org.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic
    To unsubscribe from this group and stop receiving emails from it, send
    an email to bosh-users+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.
  • Dr Nic Williams at Nov 3, 2013 at 11:27 pm
    The existing disk reference is stored in the deployments/bosh-deployment.yml file.  That useful to rebuild microbosh with a new VM?
    On Sun, Nov 3, 2013 at 3:23 PM, David Laing wrote:

    Is it not possible to do something along the lines of bosh micro deploy
    --with-persistent-disk=vol-xxxyyyy
    I.e, deploy a new microbosh and attach some existing data?
    On 3 Nov 2013 23:19, "David Laing" wrote:
    Out of interest, bosh backup on a microbosh puts the backup.tgz on
    /var/vcap/store

    Of course the backup mainly contains stuff that is already on
    var/vcap/store (eg postgres and the blobstore), and I can't find the
    corresponding bosh restore command.
    On 3 Nov 2013 20:26, "Dr Nic Williams" wrote:

    All microboshes have /var/vcap/store as a persistent disk. Perhaps we use
    that?

    On Sun, Nov 3, 2013 at 12:25 PM, David Laing wrote:

    Totally agree with Dr Nic's request - any info on how to restore in a
    BOSH context would be most welcome.

    I think the core issue is that BOSH maps /var/vcap/data/ to ephemeral
    storage for BOSHes own VMs.

    For a none BOSH director VM this doesn't matter, since bosh cck will
    just recreate any missing VMs using the last spec, and reattach the
    persistent drives.

    However, in the case of BOSH director, the thing that manages the
    restore (the director) is the thing that needs to be restored...

    If there was a way to make /var/vcap/data/ persistent for the microbosh
    VM, then you could just do a simplistic make AMI backup / restore.

    D
    On 3 Nov 2013 17:57, "Dr Nic Williams" wrote:

    Tammer/James/MattK/etc - how are Pivotal doing backup/restore of your
    microbosh?

    For any Pivots or people not using bosh-bootstrap, please still
    consider answering David - it does nothing special other than generate a
    functioning micro_bosh.yml and determine which stemcell/AMI to use.

    Backup/restore of microbosh is a critical part of living with Cloud
    Foundry.

    On Sun, Nov 3, 2013 at 9:35 AM, wrote:

    All,

    Beyond a couple of partially answered questions on the mailing lists,
    I've been unable to find any documentation / guidance on backup and
    disaster recovery with / of BOSH.

    Please could you help me create some at
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery

    I'm assuming an inception server created with
    https://github.com/cloudfoundry-community/inception-server and a
    MicroBOSH created with
    https://github.com/cloudfoundry-community/bosh-bootstrap

    Disaster recovery for the inception server is pretty straight forward
    - see
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#inception-server

    I'm stuck with disaster recovery for the MicoBOSH -
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#backup-procedure-1

    I can see how bosh backup will make a .tgz of the director's data to
    /var/vcap/store

    However, I can't figure out how one would restore this data in the
    case of your MicroBOSH instance being terminated.

    Guidance? Advise?

    Thanks!

    ;D

    To unsubscribe from this group and stop receiving emails from it, send
    an email to bosh-users+unsubscribe@cloudfoundry.org.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic
    To unsubscribe from this group and stop receiving emails from it, send
    an email to bosh-users+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.
  • David Laing at Nov 4, 2013 at 8:12 am
    I had a go deleting the entries referring to the dead instance-ids but
    keeping the volume references in bosh-deployment.yml

    However a subsequent bosh micro deploy died saying that instance id's
    couldn't be null.

    Any idea what combination of keys would force a new deployment with
    existing data?
    On 3 Nov 2013 23:27, "Dr Nic Williams" wrote:

    The existing disk reference is stored in the
    deployments/bosh-deployment.yml file. That useful to rebuild microbosh
    with a new VM?

    On Sun, Nov 3, 2013 at 3:23 PM, David Laing wrote:

    Is it not possible to do something along the lines of bosh micro deploy
    --with-persistent-disk=vol-xxxyyyy

    I.e, deploy a new microbosh and attach some existing data?
    On 3 Nov 2013 23:19, "David Laing" wrote:

    Out of interest, bosh backup on a microbosh puts the backup.tgz on
    /var/vcap/store

    Of course the backup mainly contains stuff that is already on
    var/vcap/store (eg postgres and the blobstore), and I can't find the
    corresponding bosh restore command.
    On 3 Nov 2013 20:26, "Dr Nic Williams" wrote:

    All microboshes have /var/vcap/store as a persistent disk. Perhaps we
    use that?

    On Sun, Nov 3, 2013 at 12:25 PM, David Laing wrote:

    Totally agree with Dr Nic's request - any info on how to restore in a
    BOSH context would be most welcome.

    I think the core issue is that BOSH maps /var/vcap/data/ to ephemeral
    storage for BOSHes own VMs.

    For a none BOSH director VM this doesn't matter, since bosh cck will
    just recreate any missing VMs using the last spec, and reattach the
    persistent drives.

    However, in the case of BOSH director, the thing that manages the
    restore (the director) is the thing that needs to be restored...

    If there was a way to make /var/vcap/data/ persistent for the
    microbosh VM, then you could just do a simplistic make AMI backup / restore.

    D
    On 3 Nov 2013 17:57, "Dr Nic Williams" <drnicwilliams@gmail.com>
    wrote:
    Tammer/James/MattK/etc - how are Pivotal doing backup/restore of
    your microbosh?

    For any Pivots or people not using bosh-bootstrap, please still
    consider answering David - it does nothing special other than generate a
    functioning micro_bosh.yml and determine which stemcell/AMI to use.

    Backup/restore of microbosh is a critical part of living with Cloud
    Foundry.

    On Sun, Nov 3, 2013 at 9:35 AM, wrote:

    All,

    Beyond a couple of partially answered questions on the mailing
    lists, I've been unable to find any documentation / guidance on backup and
    disaster recovery with / of BOSH.

    Please could you help me create some at
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery

    I'm assuming an inception server created with
    https://github.com/cloudfoundry-community/inception-server and a
    MicroBOSH created with
    https://github.com/cloudfoundry-community/bosh-bootstrap

    Disaster recovery for the inception server is pretty straight
    forward - see
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#inception-server

    I'm stuck with disaster recovery for the MicoBOSH -
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#backup-procedure-1

    I can see how bosh backup will make a .tgz of the director's data to
    /var/vcap/store

    However, I can't figure out how one would restore this data in the
    case of your MicroBOSH instance being terminated.

    Guidance? Advise?

    Thanks!

    ;D

    To unsubscribe from this group and stop receiving emails from it,
    send an email to bosh-users+unsubscribe@cloudfoundry.org.


    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic
    To unsubscribe from this group and stop receiving emails from it,
    send an email to bosh-users+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to bosh-users+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.
  • Brian McClain at Nov 4, 2013 at 6:19 pm
    This is something I've been curious on the best practices of for quit some
    time now. Would love to hear some real-world backup/recovery workflows for
    those running CF/BOSH in prod.

    - Brian
    @BrianMMcClain
    On Sunday, November 3, 2013 12:35:33 PM UTC-5, da...@castlelaing.com wrote:

    All,

    Beyond a couple of partially answered questions on the mailing lists, I've
    been unable to find any documentation / guidance on backup and disaster
    recovery with / of BOSH.

    Please could you help me create some at
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery

    I'm assuming an inception server created with
    https://github.com/cloudfoundry-community/inception-server and a
    MicroBOSH created with
    https://github.com/cloudfoundry-community/bosh-bootstrap

    Disaster recovery for the inception server is pretty straight forward -
    see
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#inception-server

    I'm stuck with disaster recovery for the MicoBOSH -
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#backup-procedure-1

    I can see how bosh backup will make a .tgz of the director's data to
    /var/vcap/store

    However, I can't figure out how one would restore this data in the case of
    your MicroBOSH instance being terminated.

    Guidance? Advise?

    Thanks!

    ;D
    To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.
  • Rob Day-Reynolds at Nov 8, 2013 at 12:04 am
    I'll add this to
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery ,
    but here is a playbook of sorts that we created for recovering a failed
    Micro BOSH on Pivotal's production environment on AWS. The `backup`
    command does not have a corresponding `recover` command at the moment.

    Recover terminated MicroBosh on AWS

    Assumptions

      * Persistent EBS volume for terminated MicroBosh is still around
      * bosh-deployments.yml for terminated MicroBosh is saved and up-to-date
      * micro_bosh.yml for terminated MicroBosh is up-to-date.


    Getting Started

    `cd path/to/deployments/repo` (directory containing your
    bosh-deployments.yml file)

    In bosh-deployments.yml for terminated MicroBosh

    Take note of its ami (e.g. ami-12345)
    Take note of its persistent disk's volume-id (e.g. vol-111111)

    `mv bosh-deployments.yml bosh-deployments-old.yml`


    Deploy a new MicroBosh

    `be bosh micro deploy ami-12345`

    Take note of the new persistent disk's volume-id (e.g. vol-222222)


    On the new MicroBosh

    ```
    sudo -i
    monit stop all
    watch monit summary
    ```

    Wait until jobs are no longer being monitored

    ```
    sv stop agent
    mount
    ```

    Take note of device for /var/vcap/store (e.g. /dev/xvdf1, which corresponds
    to /dev/sdf in the AWS console)

    `umount /var/vcap/store`


    In the AWS console

    Detach the new persistent EBS volume (vol-222222 from new
    bosh-deployments.yml) from the new MicroBosh instance
    Attach old persistent EBS volume (vol-111111 from old bosh-deployments.yml)
    to the new MicroBosh instance, use the same device as new persistent volume
    (e.g. /dev/sdf)


    Back on the new MicroBosh (ssh into your micro instance)

    ```
    sudo -i
    sed -i 's/vol-222222/vol-111111/' /var/vcap/bosh/settings.json
    sv start agent
    watch monit summary
    ```


    Hop back out of the MicroBosh

    `sed -i 's/vol-222222/vol-111111/' bosh-deployments.yml`

    `rm bosh-deployments-old.yml`


    In the AWS console, delete the unused EBS volume vol-222222


    You could also create an AMI from your running MicroBosh and use that AMI
    when deploying a new MicroBosh to recover from a failure.
    In that case, you could just ignore the AMI being used in
    bosh-deployments.yml, and use the backup AMI.


    - Rob Day-Reynolds
       GoPivotal Bosh Team


    On Sunday, November 3, 2013 9:35:33 AM UTC-8, da...@castlelaing.com wrote:

    All,

    Beyond a couple of partially answered questions on the mailing lists, I've
    been unable to find any documentation / guidance on backup and disaster
    recovery with / of BOSH.

    Please could you help me create some at
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery

    I'm assuming an inception server created with
    https://github.com/cloudfoundry-community/inception-server and a
    MicroBOSH created with
    https://github.com/cloudfoundry-community/bosh-bootstrap

    Disaster recovery for the inception server is pretty straight forward -
    see
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#inception-server

    I'm stuck with disaster recovery for the MicoBOSH -
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#backup-procedure-1

    I can see how bosh backup will make a .tgz of the director's data to
    /var/vcap/store

    However, I can't figure out how one would restore this data in the case of
    your MicroBOSH instance being terminated.

    Guidance? Advise?

    Thanks!

    ;D
    To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.
  • Dr Nic Williams at Nov 8, 2013 at 6:38 am
    Rob, thanks very much for writing that up!




    Nic


    Sent from Mailbox for iPad

    On Thu, Nov 7, 2013 at 4:04 PM, Rob Day-Reynolds
    wrote:
    I'll add this to
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery ,
    but here is a playbook of sorts that we created for recovering a failed
    Micro BOSH on Pivotal's production environment on AWS. The `backup`
    command does not have a corresponding `recover` command at the moment.
    Recover terminated MicroBosh on AWS
    Assumptions
    * Persistent EBS volume for terminated MicroBosh is still around
    * bosh-deployments.yml for terminated MicroBosh is saved and up-to-date
    * micro_bosh.yml for terminated MicroBosh is up-to-date.
    Getting Started
    `cd path/to/deployments/repo` (directory containing your
    bosh-deployments.yml file)
    In bosh-deployments.yml for terminated MicroBosh
    Take note of its ami (e.g. ami-12345)
    Take note of its persistent disk's volume-id (e.g. vol-111111)
    `mv bosh-deployments.yml bosh-deployments-old.yml`
    Deploy a new MicroBosh
    `be bosh micro deploy ami-12345`
    Take note of the new persistent disk's volume-id (e.g. vol-222222)
    On the new MicroBosh
    ```
    sudo -i
    monit stop all
    watch monit summary
    ```
    Wait until jobs are no longer being monitored
    ```
    sv stop agent
    mount
    ```
    Take note of device for /var/vcap/store (e.g. /dev/xvdf1, which corresponds
    to /dev/sdf in the AWS console)
    `umount /var/vcap/store`
    In the AWS console
    Detach the new persistent EBS volume (vol-222222 from new
    bosh-deployments.yml) from the new MicroBosh instance
    Attach old persistent EBS volume (vol-111111 from old bosh-deployments.yml)
    to the new MicroBosh instance, use the same device as new persistent volume
    (e.g. /dev/sdf)
    Back on the new MicroBosh (ssh into your micro instance)
    ```
    sudo -i
    sed -i 's/vol-222222/vol-111111/' /var/vcap/bosh/settings.json
    sv start agent
    watch monit summary
    ```
    Hop back out of the MicroBosh
    `sed -i 's/vol-222222/vol-111111/' bosh-deployments.yml`
    `rm bosh-deployments-old.yml`
    In the AWS console, delete the unused EBS volume vol-222222
    You could also create an AMI from your running MicroBosh and use that AMI
    when deploying a new MicroBosh to recover from a failure.
    In that case, you could just ignore the AMI being used in
    bosh-deployments.yml, and use the backup AMI.
    - Rob Day-Reynolds
    GoPivotal Bosh Team
    On Sunday, November 3, 2013 9:35:33 AM UTC-8, da...@castlelaing.com wrote:

    All,

    Beyond a couple of partially answered questions on the mailing lists, I've
    been unable to find any documentation / guidance on backup and disaster
    recovery with / of BOSH.

    Please could you help me create some at
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery

    I'm assuming an inception server created with
    https://github.com/cloudfoundry-community/inception-server and a
    MicroBOSH created with
    https://github.com/cloudfoundry-community/bosh-bootstrap

    Disaster recovery for the inception server is pretty straight forward -
    see
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#inception-server

    I'm stuck with disaster recovery for the MicoBOSH -
    https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Backup-and-disaster-recovery#backup-procedure-1

    I can see how bosh backup will make a .tgz of the director's data to
    /var/vcap/store

    However, I can't figure out how one would restore this data in the case of
    your MicroBOSH instance being terminated.

    Guidance? Advise?

    Thanks!

    ;D
    To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to bosh-users+unsubscribe@cloudfoundry.org.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupbosh-users @
postedNov 3, '13 at 5:35p
activeNov 8, '13 at 6:38a
posts11
users5

People

Translate

site design / logo © 2022 Grokbase