Netbackup for Sybase (step by step)
Netbackup provides a Sybase backup and restore solution that not all of us aware of. the attached document provides detailed instratuction on all the steps required for backup and restore of sybase database. Note .... any feedback with mistakes or enhancmenteven in the writing style will be much appreciated
NetBackup 8.1.2 Linux persistent binding changes and SAS connected library
Good news, everyone! (c) Starting from NetBackup 8.1.2 we can usepersistent binding on Linux platform. Release Notes says: Starting with NetBackup 8.1.2, the NetBackup Device Manager (ltid) uses persistent device paths for tape drives. Instead of /dev/nstXXX device paths, NetBackup uses /dev/tape/by-path/YYY-nst device paths. The paths persist across SAN interruptions. Upon NetBackup Device Manager (ltid) startup, /dev/nstXXX paths are converted to the equivalent /dev/tape/by-path/YYY-nst path . Recently I had pretty big installation with different hardware and I had some feedback that might be usefulfor others. Unfortunately, persistent binding works correctlyout of the box for FC drives only. It isn't because of NetBackup but it's because of default Linux udev rule and SAS connected Tape Libraries specialty. By default the rule's part we're interested in (60-persistent-storage-tape.rules) looks like: # by-path (parent device path) KERNEL=="st*[0-9]|nst*[0-9]", IMPORT{builtin}="path_id" KERNEL=="st*[0-9]", ENV{ID_PATH}=="?*", SYMLINK+="tape/by-path/$env{ID_PATH}" KERNEL=="nst*[0-9]", ENV{ID_PATH}=="?*", SYMLINK+="tape/by-path/$env{ID_PATH}-nst" The main thing you should know it that symlink will be created using ID_PATH value. It's easy to get this value manually: # udevadm info -n /dev/nst0 | grep ID_PATH E: ID_PATH=pci-0000:12:00.0-fc-0x50012345678cc567-lun-0 E: ID_PATH_TAG=pci-0000_12_00_0-fc-0x50012345678cc567-lun-0 It works fine for FC connected drives because their paths are unique: # ls -la /dev/tape/by-path/ total 0 drwxr-xr-x 2 root root 280 Dec 19 12:33 . drwxr-xr-x 4 root root 80 Dec 19 12:28 .. lrwxrwxrwx 1 root root 9 Dec 19 12:28 pci-0000:12:00.0-fc-0x50012345678cc567-lun-0 -> ../../st0 lrwxrwxrwx 1 root root 10 Dec 19 12:28 pci-0000:12:00.0-fc-0x50012345678cc567-lun-0-nst -> ../../nst 0 lrwxrwxrwx 1 root root 9 Dec 19 12:28 pci-0000:12:00.0-fc-0x50012345678cc56a-lun-0 -> ../../st2 lrwxrwxrwx 1 root root 10 Dec 19 12:28 pci-0000:12:00.0-fc-0x50012345678cc56a-lun-0-nst -> ../../nst 2 lrwxrwxrwx 1 root root 9 Dec 19 12:33 pci-0000:12:00.1-fc-0x50012345678cc566-lun-0 -> ../../st4 lrwxrwxrwx 1 root root 10 Dec 19 12:33 pci-0000:12:00.1-fc-0x50012345678cc566-lun-0-nst -> ../../nst 4 lrwxrwxrwx 1 root root 9 Dec 19 12:28 pci-0000:d8:00.0-fc-0x50012345678cc567-lun-0 -> ../../st1 lrwxrwxrwx 1 root root 10 Dec 19 12:28 pci-0000:d8:00.0-fc-0x50012345678cc567-lun-0-nst -> ../../nst 1 lrwxrwxrwx 1 root root 9 Dec 19 12:28 pci-0000:d8:00.0-fc-0x50012345678cc56a-lun-0 -> ../../st3 lrwxrwxrwx 1 root root 10 Dec 19 12:28 pci-0000:d8:00.0-fc-0x50012345678cc56a-lun-0-nst -> ../../nst 3 lrwxrwxrwx 1 root root 9 Dec 19 12:33 pci-0000:d8:00.1-fc-0x50012345678cc566-lun-0 -> ../../st5 lrwxrwxrwx 1 root root 10 Dec 19 12:33 pci-0000:d8:00.1-fc-0x50012345678cc566-lun-0-nst -> ../../nst and tpautoconf shows correct information (drives are available via multiple paths): # /usr/openv/volmgr/bin/tpautoconf -t TPAC60 HPE Ultrium 8-SCSI J4DB CZ00000VGV -1 -1 -1 -1 /dev/tape/by-path/pci-0000:d8:00.1-fc-0x50 012345678cc566-lun-0-nst - - TPAC60 HPE Ultrium 8-SCSI J4DB CZ00000VGV -1 -1 -1 -1 /dev/tape/by-path/pci-0000:12:00.1-fc-0x50 012345678cc566-lun-0-nst - - TPAC60 HPE Ultrium 8-SCSI J4DB CZ00000VGW -1 -1 -1 -1 /dev/tape/by-path/pci-0000:d8:00.0-fc-0x50 012345678cc56a-lun-0-nst - - TPAC60 HPE Ultrium 8-SCSI J4DB CZ00000VGW -1 -1 -1 -1 /dev/tape/by-path/pci-0000:12:00.0-fc-0x50 012345678cc56a-lun-0-nst - - TPAC60 HPE Ultrium 8-SCSI J4DB CZ00000VGV -1 -1 -1 -1 /dev/tape/by-path/pci-0000:d8:00.0-fc-0x50 02345678cc567-lun-0-nst - - TPAC60 HPE Ultrium 8-SCSI J4DB CZ00000VGV -1 -1 -1 -1 /dev/tape/by-path/pci-0000:12:00.0-fc-0x50 012345678cc567-lun-0-nst - - But when we're working with SAS connected drives we might have some problems. For example after addingTape Library via SAS we have symlinks: # ls -la /dev/tape/by-path/ total 0 drwxr-xr-x 2 root root 80 Dec 6 13:41 . drwxr-xr-x 4 root root 80 Dec 6 13:41 .. lrwxrwxrwx 1 root root 9 Dec 6 13:41 pci-0000:12:00.0-sas-0x0000000000000000-lun-0 -> ../../st1 lrwxrwxrwx 1 root root 10 Dec 6 13:41 pci-0000:12:00.0-sas-0x0000000000000000-lun-0-nst -> ../../nst1 but when we check configuration we'll see one drive that has no symlinks: # /usr/openv/volmgr/bin/tpautoconf -t TPAC60 HPE Ultrium 8-SCSI J4DB CZ00000PH9 -1 -1 -1 -1 /dev/tape/by-path/pci-0000:12:00.0-sas-0x0000000000000000-lun-0-nst - - TPAC60 HPE Ultrium 8-SCSI J4DB CZ00000CVY -1 -1 -1 -1 - - - We have two drives indeed: # ls -la /dev/nst? crw------- 1 root tape 9, 128 Dec 21 02:42 /dev/nst0 crw------- 1 root tape 9, 129 Dec 21 02:42 /dev/nst1 Let's check their ID_PATHs: # udevadm info -n /dev/nst0 | grep ID_PATH E: ID_PATH=pci-0000:12:00.0-sas-0x0000000000000000-lun-0 E: ID_PATH_TAG=pci-0000_12_00_0-sas-0x0000000000000000-lun-0 # udevadm info -n /dev/nst1 | grep ID_PATH E: ID_PATH=pci-0000:12:00.0-sas-0x0000000000000000-lun-0 E: ID_PATH_TAG=pci-0000_12_00_0-sas-0x0000000000000000-lun-0 They are identical. That's why udev can't create two different symlinks and NBU can't configure two different drives. We need to modify thedefaultudev rule (or create a new custome one because during the upgrade default udev rules might be overwritten) to have different values for different drives. The easiest way you can do it is to use: # by-path (parent device path) KERNEL=="st*[0-9]|nst*[0-9]", IMPORT{builtin}="path_id" KERNEL=="st*[0-9]", ENV{ID_PATH}=="?*", SYMLINK+="tape/by-path/$env{ID_SCSI_SERIAL}" KERNEL=="nst*[0-9]", ENV{ID_PATH}=="?*", SYMLINK+="tape/by-path/$env{ID_SCSI_SERIAL}-nst" but it isn't a universal solutions and it depends on the Tape Library you're using. In my case I had different TapeLibraries and some of then presented all drives via multiple paths and I had to use minor numbers because it was the only unique value (I didn't have enough time for deep investigation because the TLs were on the remote site). It isn't the best thing to usebecause after reboot minor name can be different but in some cases you have no choice: # by-path (parent device path) KERNEL=="st*[0-9]|nst*[0-9]", IMPORT{builtin}="path_id" KERNEL=="nst*[0-9]", ENV{ID_PATH}=="?*", SYMLINK+="tape/by-path/$env{MINOR}-nst" after that you need to re-apply udev rules: # udevadm trigger now both synlinks are in place: # ls -la /dev/tape/by-path/ total 0 drwxr-xr-x 2 root root 80 Dec 21 02:42 . drwxr-xr-x 4 root root 80 Dec 6 13:41 .. lrwxrwxrwx 1 root root 10 Dec 21 02:42 128-nst -> ../../nst0 lrwxrwxrwx 1 root root 10 Dec 21 02:42 129-nst -> ../../nst1 and we can check if both drives can be configured correctly: # /usr/openv/volmgr/bin/tpautoconf -t TPAC60 HPE Ultrium 8-SCSI J4DB CZ00000PH9 -1 -1 -1 -1 /dev/tape/by-path/129-nst - - TPAC60 HPE Ultrium 8-SCSI J4DB CZ00020CVY -1 -1 -1 -1 /dev/tape/by-path/128-nst - - Hope it helps.
Full System Recovery of Unix/Linux client without BMR
A Full Unix/Linux client recovery from a backup image requires setting up a recovery environment on the target client hardware specifically for the activity. Overwriting system files on a running system will cause it to crash and leave it in a non-boot state.Tapes and Deduplication - Storage Lifecycle Policies
I wanted to share a data collection I did today, while working with IT Solutions, deciding the best approach on how we were going to continue sending our backups Offsite. We're running about 12000 jobs per weekend, 3000 of those going offsite on Tapes. The rest are sent to DataDomain.NetBackup 7.6 Blueprints - BMR
The Technical Services team for Backup and Recovery have produced a number of documents we call "Blueprints". These Blueprints are designed to show backup and recovery challenges around specific technologies or functions and how NetBackup solves these challenges. Each Blueprint consists of:Backup Exec 2014 Blueprints - Performance Tuning
The Technical Services team for Backup and Recovery have produced a number of documents we call "Blueprints". These Blueprints are designed to show backup and recovery challenges around specific technologies or functions and how Backup Exec solves these challenges. Each Blueprint consists of:
