#2762 Issue closed: rear backup and TSM server

Labels: support / question, external tool, no-issue-activity

xslima00 opened issue at 2022-02-17 07:42:

  • ReaR version ("/usr/sbin/rear -V"):
    Relax-and-Recover 2.4 / Git

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
    NAME="Red Hat Enterprise Linux Server"
    VERSION="7.6 (Maipo)"

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
    ISO_PREFIX=rootvg-rear-$HOSTNAME
    BACKUP=TSM
    ONLY_INCLUDE_VG=( "rhel" )
    SSH_ROOT_PASSWORD="passw0rd"
    TSM_RESULT_FILE_PATH=/opt/tivoli/tsm/rear
    TSM_RM_ISOFILE=Yes

  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
    description: pSeries LPAR
    product: IBM,9080-M9S
    vendor: IBM

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
    4.14.0-115.32.1.el7a.ppc64le

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    GRUB

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    disks are mapped via VIO with vscsi

  • Issue description
    Hello, I´d like to ask if it´s possible to force rear to use additional parameters to identify TSM server. On classic machine it looks OK but in our case we have few TSM servers where "dsmc" command must be used with additional parameter -se=SERVER name.

Example:

  • Will not work as expected
[root@XXXXXXXXX-503 ~]# dsmc q fi
IBM Spectrum Protect
Command Line Backup-Archive Client Interface
  Client Version 8, Release 1, Level 13.2
  Client date/time: 02/17/2022 08:36:01
(c) Copyright by IBM Corporation and other(s) 1990, 2022. All Rights Reserved.

Node Name: XXXXXXXXX-503
Please enter your user id <XXXXXXXXX-503>:
  • We need following parameter:
[root@XXXXXXXXX-503 ~]# dsmc q fi -se=XXXXXXXXX-41
IBM Spectrum Protect
Command Line Backup-Archive Client Interface
  Client Version 8, Release 1, Level 13.2
  Client date/time: 02/17/2022 08:37:36
(c) Copyright by IBM Corporation and other(s) 1990, 2022. All Rights Reserved.

Node Name: XXXXXXXXX-503
Session established with server XXXXXXXXX-41: Linux/ppc64le
  Server Version 8, Release 1, Level 12.000
  Server date/time: 02/17/2022 08:37:38  Last access: 02/17/2022 08:14:56

       Last Incr Date          Type    File Space Name

  1     02/16/2022 17:00:42     XFS     /
  2     02/16/2022 17:00:42     XFS     /boot
  • Is it possible to force this parameter in rear configuration or some workaround has to be created from our side?

gdha commented at 2022-02-17 16:41:

@xslima00 Use rear dump to see all possible TSM parameters available, or check the /usr/share/rear/conf/default.conf file if something could fit your needs. If that is not the case you could try to add it and propose a pull request to the team.
Try the command rear -s mkrescue | grep TSM to retrieve all TSM related scripts (that might help you to get started).

jsmeix commented at 2022-02-18 11:35:

TSM_DSMC_RESTORE_OPTIONS looks promising,
cf. in our GitHub master code currently at
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L2006

In general regarding issues with third-party backup tools:
Usually we at ReaR upstream do not use third-party backup tools
so usually we cannot reproduce issues with third-party backup tools.
Nevertheless we try to help as good as we can from plain looking at the code.
In this case the code that does the restore with TSM is mainly in
usr/share/rear/restore/TSM/default/400_restore_with_tsm.sh
in our GitHub master code currently
https://github.com/rear/rear/blob/master/usr/share/rear/restore/TSM/default/400_restore_with_tsm.sh

@xslima00
you use ReaR 2.4 which is dated June 2018, cf.
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt
so it is rather old.

I recommend to try out our latest GitHub master code because
the GitHub master code is the only place where we fix things
and if there are issues it helps when you use exactly the code
where we could fix things.

See the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery

xslima00 commented at 2022-02-19 07:50:

@gdha @jsmeix Thanks for the hints guys. I was checking TSM scripts used by rear and found I have to actually modify following:
/usr/share/rear/backup/TSM/default/500_make_TSM_backup.sh
/usr/share/rear/output/TSM/default/950_dsmc_save_result_files.sh
/usr/share/rear/output/TSM/default/960_dsmc_verify_isofile.sh
/usr/share/rear/restore/TSM/default/400_restore_with_tsm.sh

Basically all those where command dsmc is used. It was necessary to add to the end (-se=SERVER1) like in this example:

grep dsmc /usr/share/rear/output/TSM/default/950_dsmc_save_result_files.sh
LC_ALL=${LANG_RECOVER} dsmc incremental "${TSM_RESULT_FILES[@]}" -se=SERVER1 >/dev/null
LC_ALL=${LANG_RECOVER} dsmc archive -archmc="$TSM_ARCHIVE_MGMT_CLASS" "${TSM_RESULT_FILES[@]}" -se=SERVER1 >/dev/null

For some smart reason this command line argument has to be always in the end so dsmc q fi -se=SERVER1 works while dsmc -se=SERVER1 q fi ends with error.

I was also checking that rear use automatically default configuration file /opt/tivoli/tsm/client/ba/bin/dsm.opt so I believe my issue would be solved if it would possible to define which opt file should be used in local.conf.

Meanwhile I have used following workaround which force rear to use server parameter:

#create fake dsmc
echo '/opt/tivoli/tsm/client/ba/bin/dsmc "$@" -se=SERVER1' > /scripts/dsmc
chmod 555 /scripts/dsmc

#crontab entry
cat /etc/cron.d/rear
PATH=/scripts/:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
00 14 * * 5 root /usr/sbin/rear mkbackup >/dev/null 2>&1

#local.conf entry
BACKUP_PROG_INCLUDE=( '/scripts/*' )

github-actions commented at 2022-04-21 03:15:

Stale issue message

github-actions commented at 2022-06-21 03:19:

Stale issue message

github-actions commented at 2022-08-21 03:26:

Stale issue message

[Export of Github issue for rear/rear.]