[isar-cip-core 0/2] Patches to meet IEC CR 7.3

[isar-cip-core 0/2] Patches to meet IEC CR 7.3

[Sai.Sathujoda]

From: Sai <Sai.Sathujoda@toshiba-tsip.com>

These patches contain the packages to add in the IEC security layer to meet CR 7.3
and the manual to use the package to fulfill the requirement.

Sai (2):
  cip-core-image-security.bb: Add duplicity package to enable IEC
    requirement
  README.control-system-backup.md : Add steps to explain control system
    backup

 doc/README.control-system-backup.md           | 214 ++++++++++++++++++
 .../images/cip-core-image-security.bb         |   1 +
 2 files changed, 215 insertions(+)
 create mode 100644 doc/README.control-system-backup.md

-- 
2.20.1

[isar-cip-core 1/2] cip-core-image-security.bb: Add duplicity package to enable IEC requirement

[Sai.Sathujoda]

From: Sai <Sai.Sathujoda@toshiba-tsip.com>

Duplicity package provides below features in order to implement IEC
requirement "Control System Backup"
1. Backup and restore
2. Encryption of backup
3. Checks integrity before restore

Python3-paramiko package is required to enable remote backups.

Signed-off-by: Sai <Sai.Sathujoda@toshiba-tsip.com>
---
 recipes-core/images/cip-core-image-security.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/recipes-core/images/cip-core-image-security.bb b/recipes-core/images/cip-core-image-security.bb
index 24b1f46..9e9e43a 100644
--- a/recipes-core/images/cip-core-image-security.bb
+++ b/recipes-core/images/cip-core-image-security.bb
@@ -34,6 +34,7 @@ IMAGE_PREINSTALL += " \
 	sudo \
 	aide-common \
 	libpam-google-authenticator \
+	duplicity python3-paramiko \
 "
 
 OVERRIDES_append = ":${BASE_DISTRO_CODENAME}"
-- 
2.20.1

[isar-cip-core 2/2] README.control-system-backup.md : Add steps to explain control system backup

[sai.sathujoda]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="maccentraleurope", Size: 11056 bytes --]

From: Sai <Sai.Sathujoda@toshiba-tsip.com>

Control system backup is an IEC security requirement to backup critical
systems for disaster recovery and system migration program.

Signed-off-by: Sai <Sai.Sathujoda@toshiba-tsip.com>
---
 doc/README.control-system-backup.md | 214 ++++++++++++++++++++++++++++
 1 file changed, 214 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..ea8b761
--- /dev/null
+++ b/doc/README.control-system-backup.md
@@ -0,0 +1,214 @@
+# 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.
+
+<<<<<<< HEAD
+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. 
+=======
+# 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 restored back. 
+>>>>>>> 22bdd8e95910548b96c7b2e30499b6f7ad951b9e
+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
+<<<<<<< HEAD
+
+1. Build the CIP security image which includes **duplicity** package as described in the [README.security-testing.md](./README.security-testing.md).
+2. Add additional storage in case of local backup like below in **/kas/opt/security.yml** file.
+```
+local_conf_header:
+     security_image_size: |
+        ROOTFS_EXTRA = "8192"
+```
+=======
+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 backups or increase the rootfs size by adding the below lines in **/kas/opt/security.yml** file.
+     ```
+     local_conf_header:
+          security_image_size: |
+          ROOTFS_EXTRA = "8192"
+     ```
+>>>>>>> 22bdd8e95910548b96c7b2e30499b6f7ad951b9e
+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.
+```
+<<<<<<< HEAD
+#### 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.
+=======
+
+### 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 restored due to an unwanted change or deletion in the file system.
+>>>>>>> 22bdd8e95910548b96c7b2e30499b6f7ad951b9e
+
+```
+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 unwantedly 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 <<EOF
+     Key-Type: DSA
+     Key-Length: 1024
+     Subkey-Type: ELG-E
+     Subkey-Length: 1024
+     Name-Real: username
+     Name-Email: usermailID
+     Expire-Date: 0
+     # passphrase should be more than 8 characters
+     Passphrase: 123456789
+EOF
+root@demo:~# gpg --batch --gen-key foo
+gpg: Generating a basic OpenPGP key
+gpg: key AE57464HFG4 marked as ultimately trusted
+gpg: revocation certificate stored as '/root/.gnupg/openpgp-revocs.d/E4C84C97B37BB24947E4522DA4B60C25738850E9.rev'
+```
+Use the encrypted key generated as above command and the encrypt key is AE57464HFG4 in the remote backup.
+
+### Remote Backup
+```
+root@demo:~# duplicity --encrypt-key "AE57464HFG4" /usr/bin sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+```
+Find the backed up files in the remote location using the below command
+```
+root@demo:~# ssh remoteuser@remoteserver ls /home/remoteuser/sftp_remote_bk_testing/first_backup
+- duplicity-full.20220829T070950Z.manifest.gpg 
+- duplicity-full.20220829T070950Z.vol1.difftar.gpg  
+- duplicity-full-signatures.20220829T070950Z.sigtar.gpg
+```
+
+### Verification of integrity after recent backup in remote server
+```
+root@demo:~# duplicity verify --encrypt-key "AE57464HFG4" --compare-data  sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin
+Local and Remote metadata are synchronized, no sync needed.5CAE2A504" --compare-data  sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin
+Last full backup date: Mon Aug 29 07:09:50 2022
+GnuPG passphrase for decryption: 
+Difference found: File . has mtime Mon Aug 29 07:14:15 2022, expected Mon Aug 29 06:00:22 2022
+Difference found: File google-authenticator is missing
+Verify complete: 582 files compared, 2 differences found.
+```
+
+#### Restoration of data from remote server
+```
+root@demo:~# duplicity --file-to-restore google-authenticator sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin/google-authenticator
+```
+
+# Automatic Backup scheduling using cron service
+To avoid operator overhead to regularly take system backup, it is necessary to automate the backup so that the data backup will be **up-to-date**.
+
+While automating this backup process, it is suggestible to use remote backup based on space issue. 
+
+Below a simple script which shall be added in the crontab to run on a daily basis.
+
+```
+#!/bin/bash
+echo "This will execute the backup on the first minute, first hour , every day"
+export PASSPHRASE=12345678
+duplicity --encrypt-key "AE57464HFG4" /usr/bin sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+unset PASSPHRASE
+```
+
+In this demo script, the /usr/bin is being taken as a backup. The user can replace based on the requirement.
+The passphrase should also match the one assigned by the user during GPG keys creation.
+
+Save the file (daily_backup.sh) in a known path and start the cron service.
+```
+root@demo:~# systemctl start cron
+```
+Check the status of the service (expected to be in running state)
+```
+root@demo:~# systemctl status cron
+● cron.service - Regular background program processing daemon
+     Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
+     Active: active (running) since Mon 2022-08-29 12:11:25 UTC; 12min ago
+```
+Open the crontab 
+```
+root@demo:~# crontab -e
+```
+Add the below line at the end of the crontab file if the user needs a backup on daily basis onto the remote server.
+```
+0 0 * * * /root/daily_backup.sh
+```
+After saving the crontab, the below message should be displayed.
+**crontab: installing new crontab**
+The user can verify this automation by checking the contents of the remote backup folder regularly.
-- 
2.20.1

RE: [cip-dev] [isar-cip-core 2/2] README.control-system-backup.md : Add steps to explain control system backup

[Sai.Sathujoda]

Hi Jan, 

Please ignore below patch series , it has merge conflicts. I will resolve and re-send the patch series again. 
Sorry for the confusion.

Regards,
Sai Ashrith

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of sai.sathujoda@toshiba-tsip.com
Sent: Friday, September 9, 2022 12:34 PM
To: cip-dev@lists.cip-project.org; jan.kiszka@siemens.com
Cc: ashrith sai(ＴＳＩＰ) <Sai.Sathujoda@toshiba-tsip.com>; dinesh kumar(ＴＳＩＰ TMIEC ODG Porting) <dinesh.kumar@toshiba-tsip.com>; hayashi kazuhiro(林 和宏 □ＳＷＣ◯ＡＣＴ) <kazuhiro3.hayashi@toshiba.co.jp>
Subject: [cip-dev] [isar-cip-core 2/2] README.control-system-backup.md : Add steps to explain control system backup

From: Sai <Sai.Sathujoda@toshiba-tsip.com>

Control system backup is an IEC security requirement to backup critical systems for disaster recovery and system migration program.

Signed-off-by: Sai <Sai.Sathujoda@toshiba-tsip.com>
---
 doc/README.control-system-backup.md | 214 ++++++++++++++++++++++++++++
 1 file changed, 214 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..ea8b761
--- /dev/null
+++ b/doc/README.control-system-backup.md
@@ -0,0 +1,214 @@
+# 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.
+
+<<<<<<< HEAD
+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. 
+=======
+# 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 restored back. 
+>>>>>>> 22bdd8e95910548b96c7b2e30499b6f7ad951b9e
+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
+<<<<<<< HEAD
+
+1. Build the CIP security image which includes **duplicity** package as described in the [README.security-testing.md](./README.security-testing.md).
+2. Add additional storage in case of local backup like below in **/kas/opt/security.yml** file.
+```
+local_conf_header:
+     security_image_size: |
+        ROOTFS_EXTRA = "8192"
+```
+=======
+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 backups or increase the rootfs size by adding the below lines in **/kas/opt/security.yml** file.
+     ```
+     local_conf_header:
+          security_image_size: |
+          ROOTFS_EXTRA = "8192"
+     ```
+>>>>>>> 22bdd8e95910548b96c7b2e30499b6f7ad951b9e
+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.
+```
+<<<<<<< HEAD
+#### 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.
+=======
+
+### 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 restored due to an unwanted change or deletion in the file system.
+>>>>>>> 22bdd8e95910548b96c7b2e30499b6f7ad951b9e
+
+```
+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 unwantedly 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 <<EOF
+     Key-Type: DSA
+     Key-Length: 1024
+     Subkey-Type: ELG-E
+     Subkey-Length: 1024
+     Name-Real: username
+     Name-Email: usermailID
+     Expire-Date: 0
+     # passphrase should be more than 8 characters
+     Passphrase: 123456789
+EOF
+root@demo:~# gpg --batch --gen-key foo
+gpg: Generating a basic OpenPGP key
+gpg: key AE57464HFG4 marked as ultimately trusted
+gpg: revocation certificate stored as '/root/.gnupg/openpgp-revocs.d/E4C84C97B37BB24947E4522DA4B60C25738850E9.rev'
+```
+Use the encrypted key generated as above command and the encrypt key is AE57464HFG4 in the remote backup.
+
+### Remote Backup
+```
+root@demo:~# duplicity --encrypt-key "AE57464HFG4" /usr/bin 
+sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+```
+Find the backed up files in the remote location using the below command 
+``` root@demo:~# ssh remoteuser@remoteserver ls 
+/home/remoteuser/sftp_remote_bk_testing/first_backup
+- duplicity-full.20220829T070950Z.manifest.gpg
+- duplicity-full.20220829T070950Z.vol1.difftar.gpg
+- duplicity-full-signatures.20220829T070950Z.sigtar.gpg
+```
+
+### Verification of integrity after recent backup in remote server ``` 
+root@demo:~# duplicity verify --encrypt-key "AE57464HFG4" 
+--compare-data  
+sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup 
+/usr/bin Local and Remote metadata are synchronized, no sync needed.5CAE2A504" --compare-data  sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup /usr/bin Last full backup date: Mon Aug 29 07:09:50 2022 GnuPG passphrase for decryption:
+Difference found: File . has mtime Mon Aug 29 07:14:15 2022, expected 
+Mon Aug 29 06:00:22 2022 Difference found: File google-authenticator is 
+missing Verify complete: 582 files compared, 2 differences found.
+```
+
+#### Restoration of data from remote server ``` root@demo:~# duplicity 
+--file-to-restore google-authenticator 
+sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup 
+/usr/bin/google-authenticator ```
+
+# Automatic Backup scheduling using cron service To avoid operator 
+overhead to regularly take system backup, it is necessary to automate the backup so that the data backup will be **up-to-date**.
+
+While automating this backup process, it is suggestible to use remote backup based on space issue. 
+
+Below a simple script which shall be added in the crontab to run on a daily basis.
+
+```
+#!/bin/bash
+echo "This will execute the backup on the first minute, first hour , every day"
+export PASSPHRASE=12345678
+duplicity --encrypt-key "AE57464HFG4" /usr/bin 
+sftp://remoteuser@remoteserver:/sftp_remote_bk_testing/first_backup
+unset PASSPHRASE
+```
+
+In this demo script, the /usr/bin is being taken as a backup. The user can replace based on the requirement.
+The passphrase should also match the one assigned by the user during GPG keys creation.
+
+Save the file (daily_backup.sh) in a known path and start the cron service.
+```
+root@demo:~# systemctl start cron
+```
+Check the status of the service (expected to be in running state) ``` 
+root@demo:~# systemctl status cron ● cron.service - Regular background 
+program processing daemon
+     Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
+     Active: active (running) since Mon 2022-08-29 12:11:25 UTC; 12min 
+ago ``` Open the crontab ``` root@demo:~# crontab -e ``` Add the below 
+line at the end of the crontab file if the user needs a backup on daily basis onto the remote server.
+```
+0 0 * * * /root/daily_backup.sh
+```
+After saving the crontab, the below message should be displayed.
+**crontab: installing new crontab**
+The user can verify this automation by checking the contents of the remote backup folder regularly.
--
2.20.1