This section explains how to restore a server.
This section explains how to restore a primary or secondary master server, development server, or collaboration server.
To restore a server other than a slave server, execute the bdpp_restore command on the relevant server.
Note
Development server
Execution of the bdpp_restore command will not restore other items such as MapReduce applications developed on the development server.
Collaboration server
Execution of the bdpp_restore command will not back up business systems or business data on the collaboration server.
Preparing to perform restore
The preparatory tasks described below must be performed on the relevant server prior to performing restore.
Deploy the backup that will be used to perform restore to any directory on the server to be restored.
If the backup has been archived, decompress it.
Example
If backup is archived in tar format
The following example shows how the tar command is used to decompress the backup that was deployed to /var/backup (FJSVbdpp-backup-master1-20121010.tar).
# cd /var/backup <Enter> # tar xvf FJSVbdpp-backup-master1-20121010.tar <Enter>
Refer to "Chapter 5 Preparing to Build the System", and configure the required settings on the relevant server.
Note that there is no need to perform the tasks specified in "5.6 Host Name Settings", because the hosts file included in the backup will be used. Replace the hosts file located on the relevant server with the hosts file in the backup storage directory (FJSVbdpp-backup/SYS).
Example
Replacing the hosts file
The following example shows how the cp command is used to replace the hosts file located on the relevant server with the hosts file in the backup storage directory that was deployed to /var/backup.
# cp -p /var/backup/FJSVbdpp-backup/SYS/hosts /etc <Enter>
Refer to "6.5.2.2 Registering the hadoop Group and mapred User", and register the hadoop group and the mapred user on the collaboration server. These tasks are only performed when a collaboration server is restored.
Restore procedure
This section explains the restore procedure. Ensure that the tasks outlined in "Preparing to perform restore" have been performed in advance.
Log in to the master server that will not be restored using root permissions.
Execute the bdpp_stop command to stop Hadoop.
Note
If the master server uses replicated configuration, Hadoop may be running. If so, stop Hadoop.
Log in to the server to be restored using root permissions.
Deploy bdpp.conf located in the backup storage directory (FJSVbdpp-backup/SYS) to any directory.
Install the functionality for the relevant server.
On a master server
Refer to "6.1.1.2 Installing the Master Server Functionality", and install this functionality. Then, perform the HA cluster setup only on the master server to be restored. Refer to "6.1.2 HA Cluster Setup" for the setup procedure.
On a development server
Refer to "6.4.1.2 Installing the Development Server Functionality", and install this functionality.
On a collaboration server
Refer to "6.5.1.2 Installing the Collaboration Server Functionality", and install this functionality.
Execute the bdpp_restore command on the relevant server.
Example
The following example shows the backup storage directory deployed to /var/backup.
# /opt/FJSVbdpp/bin/bdpp_restore -d /var/backup <Enter>
Note
Ensure that the configuration of the backup storage directory and its subdirectories is the same as when the backup was created.
If the backup includes clone images, these will be decompressed (copied) when restore is executed on the primary master server. Note that in this case, the time required for restore may increase in proportion to the file size of the clone image multiplied by the number of images, because copying the files (disk I/O) is time-consuming.
Ensure that there is sufficient disk space on the server to be restored prior to performing the restore. Refer to "Table 14.3 Disk space required on each server" for details.
If job execution users were added using the method outlined in "11.1 Adding Job Execution Users", the settings for these users will need to be configured again on the server that will be restored. Refer to "11.1 Adding Job Execution Users" for information on how to configure these users.
If execution of the bdpp_restore command fails, refer to the output message and check its meaning and corrective action, or if required, refer to the backup log (/var/opt/FJSVbdpp/log/bdpp_restore.log), remove the cause of the failure, and re-execute the command.
This section explains how to restore a slave server.
Slave servers are restored using the cloning functionality.
Point
Restoring a slave server in a physical environment
Clone using the clone image that was created beforehand.
Restoring a slave server in a virtual environment
Clone from a slave server (virtual machine) that is already installed.
Preparing to perform restore
The preparatory tasks described below must be performed prior to cloning.
Confirm that the clone image to be used for restore is located in the clone image storage directory on the primary master server.
If the clone image has not yet been prepared, refer to "6.3.1.4 Creating a Clone Image" and create a clone image from a slave server that has been installed.
The network parameter and iSCSI name automatic configuration must be registered in the clone source slave server. Accordingly, check the clone source slave server that was used when the slave server to be restored was added.
If there is no clone source slave server, or if the clone source slave server itself will be restored, perform the steps outlined in "6.3.2.2 Registering the Network Parameter and iSCSI Name Automatic Configuration Feature" to ensure that an existing slave server can be used as the clone source.
Restore procedure
Rebuild the slave server to be restored using the cloning functionality.
For a physical environment, perform the steps outlined in "6.3.1.6 Cloning".
For a virtual environment, perform the steps outlined in "6.3.2.3 Cloning".
Note
Restoring a slave server to a physical environment
If the clone image used for the restore was created from a configuration older than the slave server currently operating, the files below must be obtained from the primary master server after cloning, and then deployed to the slave server that was restored.
DFS file system configuration information, client.conf.fsid
Slave server definitions file, /etc/opt/FJSVbdpp/conf/slaves
Hadoop configuration parameters, /etc/hadoop/mapred-site.xml
