Backup and Restore a Standalone or Frontend install
Periodic backups of Chef Infra Server are essential to managing and maintaining a healthy configuration and ensuring the availability of important data for restoring your system, if required. The backup takes around 4 to 5 minutes for each GB of data on a t3.2xlarge AWS EC2 instance.
Requirements
- Chef Infra Server 14.11.36 or later
chef-server-ctl
For the majority of use cases, chef-server-ctl backup is the recommended way to take backups of the Chef Infra Server. Use the following commands for managing backups of Chef Infra Server data, and for restoring those backups.
backup
The backup subcommand is used to back up all Chef Infra Server data. This subcommand:
- Requires rsync to be installed on the Chef Infra Server before running the command
- Requires a
chef-server-ctl reconfigurebefore running the command - Should not be run in a Chef Infra Server configuration with an external PostgreSQL database; use knife ec backup instead
- Puts the initial backup in the
/var/opt/chef-backupdirectory as a tar.gz file; move this backup to a new location for safe keeping
Options
This subcommand has the following options:
-y,--yesUse to specify if the Chef Infra Server can go offline during tar.gz-based backups.
--pg-optionsUse to specify and pass additional options PostgreSQL during backups. See the PostgreSQL documentation for more information.
-c,--config-onlyBackup the Chef Infra Server configuration without backing up data.
-t,--timeoutSet the maximum amount of time in seconds to wait for shell commands (default 600). This option should be set to greater than 600 for backups taking longer than 10 minutes.
-h,--helpShow help message.
Syntax
This subcommand has the following syntax:
chef-server-ctl backup restore
The restore subcommand is used to restore Chef Infra Server data from a backup that was created by the backup subcommand. This subcommand may also be used to add Chef Infra Server data to a newly-installed server. Do not run this command in a Chef Infra Server configuration that uses an external PostgreSQL database; use knife ec backup instead. This subcommand:
- Requires rsync installed on the Chef Infra Server before running the command
- Requires a
chef-server-ctl reconfigurebefore running the command
Ideally, the restore server will have the same FQDN as the server that you backed up. If the restore server has a different FQDN, then:
- Replace the FQDN in the
/etc/opscode/chef-server.rb. - Replace the FQDN in the
/etc/opscode/chef-server-running.json. - Delete the old SSL certificate, key and
-ssl.conffile from/var/opt/opscode/nginx/ca. - If you use a CA-issued certificate instead of a self-signed certificate, copy the CA-issued certificate and key into
/var/opt/opscode/nginx/ca. - Update the
/etc/chef/client.rbfile on each client to point to the new server FQDN. - Run
chef-server-ctl reconfigure. - Run
chef-server-ctl restore.
Options
This subcommand has the following options:
-c,--cleanseUse to remove all existing data on the Chef Infra Server; it will be replaced by the data in the backup archive.
-d DIRECTORY,--staging-dir DIRECTORYUse to specify that the path to an empty directory to be used during the restore process. This directory must have enough disk space to expand all data in the backup archive.
--pg-optionsUse to specify and pass additional options PostgreSQL during backups. See the PostgreSQL documentation for more information.
-t,--timeoutSet the maximum amount of time in seconds to wait for shell commands. Set to greater than 600 for backups that take longer than 10 minutes. Default: 600.
-h,--helpShow help message.
Syntax
This subcommand has the following syntax:
chef-server-ctl restore PATH_TO_BACKUP (options) Examples
chef-server-ctl restore /path/to/tar/archive.tar.gz Backup and restore a Chef Backend install
Warning
Chef Backend is deprecated and no longer under active development. Contact your Chef account representative for information about migrating to Chef Automate HA.
This document is no longer maintained.
In a disaster recovery scenario, the backup and restore processes allow you to restore a data backup into a newly built cluster. The restore process is not intended for recovering individual machine in the Chef Backend cluster or for a point-in-time rollback of an existing cluster.
Backup
Restoring your data in an emergency requires existing backups in the .tar format of:
- The Chef Backend cluster data
- The Chef Infra Server configuration file
To make backups use in future disaster scenarios:
- On a follower Chef Backend node, create the back-end data backup with:
chef-backend-ctl backup - On Chef Infra Server node, create the server configuration backup with:
chef-server-ctl backup --config-only - Move the tar archives created in steps (1) and (2) to a long-term storage location
Restore
The restore process requires Chef Infra Server 14.11.36 or later.
Restoring Chef Backend for a Chef Infra Server cluster has two steps:
- Restore the back-end services
- Restore the front-end services
Backend Restore
Restoring the back-end services creates a new cluster. Select one node as the leader and restore the backup on that node first. Use the IP address of the leader node as the value for the
--publish_addressoption.chef-backend-ctl restore --publish_address my.company.ip.address /path/to/backup.tar.gzFor example,
chef-backend-ctl restore --publish_address 198.52.1000.0 /backups/2021/backup.tar.gzThe restore process creates a new cluster and generates a JSON secrets file for setting up communication between the nodes. Locate the file in
/etc/chef-backend/chef-backend-secrets.jsonand copy it to each node astmp/chef-backend-secrets.jsonJoin follower nodes to your new Chef Backend cluster. For each follower node, run the
join-clustersubcommand to establish communication in the cluster. The command uses:- The IP address of the new leader node.
- The IP address of the follower node that joins through the
--publish_addressoption. - The secrets option
-swith the/tmp/chef-backend-secrets.jsonfile on the node.
The
join-clustercommand is:chef-backend-ctl join-cluster --accept-license --yes --quiet IP_OF_LEADER_NODE --publish_address IP_OF_FOLLOWER_NODE -s /tmp/chef-backend-secrets.jsonFor example:
chef-backend-ctl join-cluster --accept-license --yes --quiet 198.51.100.0 --publish_address 203.0.113.0 -s /tmp/chef-backend-secrets.jsonGenerate the configuration for the front end from the new cluster:
chef-backend-ctl gen-server-config chefserver.internal > /tmp/chef-server.rb
Frontend Restore
Note
Restore Chef Infra Server from your backed-up Infra Server configuration generated by the new cluster.
chef-server-ctl restore /path/to/chef-server-backup.tar.gzCopy the Chef generated config
/tmp/chef-server.rb, to the front end node and replace it onto/etc/opscode/chef-server.rb.Run reconfigure to apply the changes.
chef-server-ctl reconfigureRun the
reindexcommand to re-populate your search indexchef-server-ctl reindex --all
Note
knife search does not return the expected results and data is present in the Chef Infra Server after reindex, then verify the search index configuration.Verify
The best practice for maintaining useful backup is to periodically verify your backup by restoring:
- One Chef Backend node
- One Chef Infra Server node
Verify that you can execute knife commands and Chef Infra Client runs against your these restored nodes.
Troubleshoot
The restore process requires Chef Infra Server 14.11.36 or later.
For a quick fix you can edit /opt/opscode/embedded/lib/ruby/gems/2.7.0/gems/chef-server-ctl-1.1.0/bin/chef-server-ctl and add the following methods:
# External Solr/ElasticSearch Commands def external_status_opscode_solr4(_detail_level) solr = external_services['opscode-solr4']['external_url'] begin Chef::HTTP.new(solr).get(solr_status_url) puts "run: opscode-solr4: connected OK to #{solr}" rescue StandardError => e puts "down: opscode-solr4: failed to connect to #{solr}: #{e.message.split("\n")[0]}" end end def external_cleanse_opscode_solr4(perform_delete) log <<-EOM Cleansing data in a remote Sol4 instance is not currently supported. EOM end def solr_status_url case running_service_config('opscode-erchef')['search_provider'] when "elasticsearch" "/chef" else "/admin/ping?wt=json" end end