Merge pull request #464 from github/lildude/update-docs

Update documentation for GitHub Enterprise Server name change

Author: lildude

docs/README.md

@@ -1,9 +1,9 @@
-# GitHub Enterprise Backup Utilities Documentation
+# GitHub Enterprise Server Backup Utilities Documentation
 
 - **[Requirements](requirements.md)**
   - **[Backup host requirements](requirements.md#backup-host-requirements)**
   - **[Storage requirements](requirements.md#storage-requirements)**
-  - **[GitHub Enterprise version requirements](requirements.md#github-enterprise-version-requirements)**
+  - **[GitHub Enterprise Server version requirements](requirements.md#github-enterprise-version-requirements)**
 - **[Getting started](getting-started.md)**
 - **[Using the backup and restore commands](usage.md)**
 - **[Scheduling backups](scheduling-backups.md)**

docs/docker.md

@@ -38,7 +38,7 @@ github/backup-utils ghe-backup
 
 ## SSH Keys
 
-A SSH private key that has been added to the GitHub Enterprise [Management Console
+A SSH private key that has been added to the GitHub Enterprise Server [Management Console
 for administrative SSH access][1] needs to be mounted into the container from the
 host system. It is also recommended to mount a SSH `.ssh/known_hosts` file into
 the container.
@@ -57,7 +57,7 @@ github/backup-utils ghe-backup
 ### Using ssh-agent
 
 If your SSH private key is protected with a passphrase, you can mount the `ssh-agent`
-socket from the Docker host into the GitHub Enterprise Backup Utilities image.
+socket from the Docker host into the GitHub Enterprise Server Backup Utilities image.
 
 1. Start the ssh-agent in the background.
 

docs/faq.md

@@ -2,10 +2,10 @@
 
 ## How does Backup Utilities differ from a High Availability replica?
 It is recommended that both Backup Utilities and an [High Availability replica][1]
-are used as part of a GitHub Enterprise deployment but they serve different roles.
+are used as part of a GitHub Enterprise Server deployment but they serve different roles.
 
 ### The purpose of the High Availability replica
-The High Availability replica is a fully redundant secondary GitHub Enterprise
+The High Availability replica is a fully redundant secondary GitHub Enterprise Server
 instance, kept in sync with the primary instance via replication of all major
 datastores. This active/passive cluster configuration is designed to minimize
 service disruption in the event of hardware failure or major network outage

docs/getting-started.md

@@ -9,10 +9,10 @@
     `git clone -b stable https://github.com/github/backup-utils.git`
 
     **Note**: you will need to use [Backup Utilities v2.11.x][2] or the `legacy` branch to
-    backup and restore GitHub Enterprise 2.10 and earlier.
+    backup and restore GitHub Enterprise Server 2.10 and earlier.
 
  2. Copy the [`backup.config-example`][3] file to `backup.config` and modify as
-    necessary. The `GHE_HOSTNAME` value must be set to the primary GitHub Enterprise
+    necessary. The `GHE_HOSTNAME` value must be set to the primary GitHub Enterprise Server
     host name. Additional options are available and documented in the
     configuration file but none are required for basic backup functionality.
 

docs/requirements.md

@@ -1,7 +1,7 @@
 # Requirements
 
 Backup Utilities should be run on a host dedicated to long-term permanent
-storage and must have network connectivity with the GitHub Enterprise appliance.
+storage and must have network connectivity with the GitHub Enterprise Server appliance.
 
 ## Backup host requirements
 
@@ -12,7 +12,7 @@ We encourage the use of [Docker](docker.md) if your backup host doesn't meet the
 requirements, or if Docker is your preferred platform.
 
 The backup host must be able to establish outbound network connections to the
-GitHub appliance over SSH. TCP port 122 is used to backup GitHub Enterprise.
+GitHub appliance over SSH. TCP port 122 is used to backup GitHub Enterprise Server.
 
 ## Storage requirements
 
@@ -22,31 +22,32 @@ of storage allocated to the primary GitHub appliance for historical snapshots
 and growth over time.
 
 Backup Utilities use [hard links][5] to store data efficiently, and the
-repositories on GitHub Enterprise use [symbolic links][6] so the backup snapshots
+repositories on GitHub Enterprise Server use [symbolic links][6] so the backup snapshots
 must be written to a filesystem with support for symbolic and hard links.
 
 Using a [case sensitive][7] file system is also required to avoid conflicts.
 
-## GitHub Enterprise version requirements
+## GitHub Enterprise Server version requirements
 
 Starting with Backup Utilities v2.13.0, version support is inline with that of the
-[GitHub Enterprise upgrade requirements][8] and as such, support is limited to
-three versions of GitHub Enterprise: the version that corresponds with the version
+[GitHub Enterprise Server upgrade requirements][8] and as such, support is limited to
+three versions of GitHub Enterprise Server: the version that corresponds with the version
 of Backup Utilities, and the two releases prior to it.
 
 For example, Backup Utilities v2.13.0 can be used to backup and restore all patch
-releases from 2.11.0 to the latest patch release of GitHub Enterprise 2.13.
-Backup Utilities v2.14.0 will be released when GitHub Enterprise 2.14.0 is released
-and will then be used to backup all releases of GitHub Enterprise from 2.12.0
-to the latest patch release of GitHub Enterprise 2.14.
+releases from 2.11.0 to the latest patch release of GitHub Enterprise Server 2.13.
+Backup Utilities v2.14.0 will be released when GitHub Enterprise Server 2.14.0 is released
+and will then be used to backup all releases of GitHub Enterprise Server from 2.12.0
+to the latest patch release of GitHub Enterprise Server 2.14.
 
-Backup Utilities v2.11.4 and earlier offer support for GitHub Enterprise 2.10
-and earlier releases.
+Backup Utilities v2.11.4 and earlier offer support for GitHub Enterprise Server 2.10
+and earlier releases up to GitHub Enterprise Server 2.2.0. Backup Utilities v2.11.0 and earlier
+offer support for GitHub Enterprise Server 2.1.0 and earlier.
 
 **Note**: You can restore a snapshot that's at most two feature releases behind
-the restore target's version of GitHub Enterprise. For example, to restore a
-snapshot of GitHub Enterprise 2.11, the target GitHub Enterprise appliance must
-be running GitHub Enterprise 2.12.x or 2.13.x. You can't restore a snapshot from
+the restore target's version of GitHub Enterprise Server. For example, to restore a
+snapshot of GitHub Enterprise Server 2.11, the target GitHub Enterprise Server appliance must
+be running GitHub Enterprise Server 2.12.x or 2.13.x. You can't restore a snapshot from
 2.10 to 2.13, because that's three releases ahead.
 
 [1]: https://www.gnu.org/software/bash/

docs/usage.md

@@ -6,7 +6,7 @@ After the initial backup, use the following commands:
    along with full snapshots of all other pertinent data stores.
  - The `ghe-restore` command restores snapshots to the same or separate GitHub
    Enterprise appliance. You must add the backup host's SSH key to the target
-   GitHub Enterprise appliance before using this command.
+   GitHub Enterprise Server appliance before using this command.
 
 These commands are run on the host you [installed][1] Backup Utilities on.
 
@@ -36,7 +36,7 @@ Creating a backup snapshot:
     Checking for leaked ssh keys ...
     * No leaked keys found
 
-Restoring from last successful snapshot to a newly provisioned GitHub Enterprise
+Restoring from last successful snapshot to a newly provisioned GitHub Enterprise Server
 appliance at IP "5.5.5.5":
 
     $ ghe-restore 5.5.5.5
@@ -72,12 +72,12 @@ The `ghe-backup` and `ghe-restore` commands also have a verbose output mode
 (`-v`) that lists files as they're being transferred. It's often useful to
 enable when output is logged to a file.
 
-When restoring to a new GitHub Enterprise instance, settings, certificate, and
+When restoring to a new GitHub Enterprise Server instance, settings, certificate, and
 license data *are* restored. These settings must be reviewed and saved before
-using the GitHub Enterprise to ensure all migrations take place and all required
+using the GitHub Enterprise Server to ensure all migrations take place and all required
 services are started.
 
-When restoring to an already configured GitHub Enterprise instance, settings, certificate, and license data
+When restoring to an already configured GitHub Enterprise Server instance, settings, certificate, and license data
 are *not* restored to prevent overwriting manual configuration on the restore
 host. This behavior can be overridden by passing the `-c` argument to `ghe-restore`,
 forcing settings, certificate, and license data to be overwritten with the backup copy's data.