From patchwork Fri Sep 9 08:07:30 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Sai.Sathujoda@toshiba-tsip.com X-Patchwork-Id: 13005239 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mo-csw.securemx.jp (mo-csw.securemx.jp [210.130.202.153]) by mx.groups.io with SMTP id smtpd.web09.4117.1662710858573103262 for ; Fri, 09 Sep 2022 01:07:39 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: toshiba-tsip.com, ip: 210.130.202.153, mailfrom: sai.sathujoda@toshiba-tsip.com) Received: by mo-csw.securemx.jp (mx-mo-csw1514) id 28987a8v026296; Fri, 9 Sep 2022 17:07:37 +0900 X-Iguazu-Qid: 34tKHR6adourcFSiS0 X-Iguazu-QSIG: v=2; s=0; t=1662710856; q=34tKHR6adourcFSiS0; m=z7APRyKqVXrIf4FPgYjXu9glbcjTThIMTr1DPXOgK7I= Received: from imx2-a.toshiba.co.jp (imx2-a.toshiba.co.jp [106.186.93.35]) by relay.securemx.jp (mx-mr1512) id 28987ZuZ019079 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 9 Sep 2022 17:07:36 +0900 From: sai.sathujoda@toshiba-tsip.com To: cip-dev@lists.cip-project.org, jan.kiszka@siemens.com Cc: Sai , dinesh.kumar@toshiba-tsip.com, kazuhiro3.hayashi@toshiba.co.jp Subject: [isar-cip-core 1/2] README.control-system-backup.md: Add steps to explain control system backup Date: Fri, 9 Sep 2022 13:37:30 +0530 X-TSB-HOP2: ON Message-Id: <20220909080731.10848-2-Sai.Sathujoda@toshiba-tsip.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20220909080731.10848-1-Sai.Sathujoda@toshiba-tsip.com> References: <20220909080731.10848-1-Sai.Sathujoda@toshiba-tsip.com> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2022 08:07:31.0916 (UTC) FILETIME=[362BA8C0:01D8C423] List-Id: From: Sai Control system backup is an IEC security requirement to backup critical systems for disaster recovery and system migration program. This document demonstrates how control system backup can be taken using 'duplicity', and also provide steps to check the integrity and restore the backups. Signed-off-by: Sai --- doc/README.control-system-backup.md | 194 ++++++++++++++++++++++++++++ 1 file changed, 194 insertions(+) create mode 100644 doc/README.control-system-backup.md diff --git a/doc/README.control-system-backup.md b/doc/README.control-system-backup.md new file mode 100644 index 0000000..4f4f9e1 --- /dev/null +++ b/doc/README.control-system-backup.md @@ -0,0 +1,194 @@ +# Overview +This document explains how to take system-level backup, verify integrity, and restore the backup file. It also mentions the demonstration which has to be carried out using **duplicity** to perform both local and remote backups. + +# Description +There is always a chance for the data to get corrupted or lost due to some unknown reasons. In those situations, system level backup is helpful so that if any data is lost then it can be restored back. +If there is a lot of space available in the system then **Local backup** can be considered. But in some cases space will not be enough if we opt for daily backup. In that situation, it is better to choose remote backup where all the data in the system will be stored on a remote server. + +**Duplicity** provides facilities like system-level backup, encryption of the data taken as a backup, verification of data integrity before restore and finally the restoration of the data from the backup. + +# Pre-Requisites +1. CIP security image which includes **duplicity** package, to build the image follow the steps described in the [README.security-testing.md](./README.security-testing.md#build-cip-security-linux-image). +2. Additional storage in case of local backup, (Add the below lines in **/kas/opt/security.yml** file to increase the rootfs size). + ``` + local_conf_header: + security_image_size: | + ROOTFS_EXTRA = "8192" + ``` +3. Remote machine with Linux OS to store remote backups. + +# Local Backup & Restore +For the first backup taken it will be a **full backup** but after that it will be incremental backups. If full backups are to be taken explicitly then add "full" in the command. + +The user can choose the data needed to be taken as backup. For example, in the below command /usr/bin directory is taken as backup in the /usr/local/backup location locally. +Note: PASSPHRASE should be more than 8 characters. +``` +root@demo:~# export PASSPHRASE=12345678 +root@demo:~# duplicity /usr/bin file:///usr/local/backup +Local and Remote metadata are synchronized, no sync needed. +Last full backup date: none +No signatures found, switching to full backup. +--------------[ Backup Statistics ]-------------- +StartTime 1661752359.77 (Mon Aug 29 05:52:39 2022) +EndTime 1661752362.69 (Mon Aug 29 05:52:42 2022) +ElapsedTime 2.92 (2.92 seconds) +SourceFiles 582 +SourceFileSize 49793026 (47.5 MB) +NewFiles 582 +NewFileSize 49793026 (47.5 MB) +DeletedFiles 0 +ChangedFiles 0 +ChangedFileSize 0 (0 bytes) +ChangedDeltaSize 0 (0 bytes) +DeltaEntries 582 +RawDeltaSize 49779683 (47.5 MB) +TotalDestinationSizeChange 21135788 (20.2 MB) +Errors 0 +``` +Note: Two different data sets cannot be taken as backup into the same location. So make sure when a data set different from the previous is taken as backup, choose a different storage location. + +### Verification of data integrity before restore +We can verify whatever changes are made to our latest file system on comparing with a latest backup taken like below: +``` +root@demo:/usr/bin# rm google-authenticator +root@demo:~# duplicity verify --compare-data -v4 file:///usr/local/backup /usr/bin +Last full backup date: Mon Aug 29 05:52:31 2022 +GnuPG passphrase for decryption: +Difference found: File . has mtime Mon Aug 29 05:56:13 2022, expected Mon Aug 29 03:54:07 2022 +Difference found: File google-authenticator is missing +Verify complete: 582 files compared, 2 differences found. +``` + +#### Data Restore +The files can be restored only after integrity verification as shown above so that the user will specifically know which files or directories have to be restored due to an unwanted change or deletion in the file system. + +``` +root@demo:~# duplicity --file-to-restore google-authenticator file:///usr/local/backup /usr/bin/google-authenticator +``` +Situation : If a directory containing 1000 files has around 250 files deleted and around 100 files modified. In that case it is not user friendly for the user to individually restore such a huge list of modified files to restore. Duplicity will not allow overwrite of remaining files in the directory so in that case the only possible solution is to delete the entire directory and restore it from the backup. + +The --file-to-restore switch should be removed if the user wants to restore a complete directory like shown below. +``` +root@demo:~# duplicity file:///usr/local/backup /usr/bin/ +``` + +### Listing all the files in the backup +To check all the contents of a backup do as shown below: +``` +root@demo:~# duplicity list-current-files file:///usr/local/backup +Local and Remote metadata are synchronized, no sync needed. +Last full backup date: Mon Aug 29 05:52:31 2022 +Mon Aug 29 03:54:07 2022 . +Mon Aug 29 03:52:37 2022 Mail +Thu Sep 24 08:36:09 2020 [ +Thu Jan 20 20:10:35 2022 addpart +Sun Jan 16 12:36:56 2022 aide +Thu Jun 10 08:53:34 2021 apt +Thu Jun 10 08:53:34 2021 apt-cache +Thu Jun 10 08:53:34 2021 apt-cdrom +Thu Jun 10 08:53:34 2021 apt-config +... +``` + +# Remote Backup & Restore +### Setting up the environment on remote server +In the Local server, generate a pair of RSA keys that will be used for authentication during remote backup. +``` +root@demo:~# ssh-keygen -t rsa -b 2048 -N "" -f /root/.ssh/id_rsa +root@demo:~# ssh-copy-id -i ~/.ssh/id_rsa remoteuser@remoteserver-ip +``` + +Create a directory in remote server for keeping the backup files +``` +root@demo:~# ssh remoteuser@remoteserver mkdir -p sftp_remote_bk_testing/first_backup +``` + +### Generation of GPG keys for encryption of data +Create a file name gen-key-script and add the parameters like below: +``` +root@demo:~# cat >foo <