10 reasons for choosing Rear as a DR strategy

Abstract: Relax and Recover (Rear) is an Open Source tool that implements a simple, yet effective, workflow for bare metal disaster recovery. The design approach taken by its authors delivers a setup-and-forget solution that is easy to deploy, offers a high success rate and makes recovery simple as possible.

So there, I already gave away 3 reasons ! Maybe I'll higher the stakes and bring it to 13 reasons, who knows ? So if you are looking for a solution to complement you existing backup strategy, or if you're looking for a one-stop solution, look no more !

Transcript

1. Relax and Recover 10 reasons for choosing Rear as a DR strategy Dag Wieërs - dag@wieers.com
2. Who is Dag Wieërs ? • Freelance Linux and Open Source consultant – Currently at Hewlett-Packard, previously contracted at AXA, EMC², Euroclear and employed at IBM – design, automation, integration, maintenance, ... • Author of various tools – dstat, mrepo, proxytunnel, wiipresent, dconf, asciidoc-odf, unoconv, … • Involved in various Open Source communities – RPMforge, ELRepo, CentOS, syslinux, AsciiDoc, LibreOffice, docbook2odf, Rear, Devops, ...
3. What is Relax and Recover ? Tool that implements a DR workflow for Linux Which basically means ? – Modular framework written in Bash ❶ – Easy to extend to own needs ❷ – Easy to deploy ❸ – Needs no maintenance (set up and forget) ❹ – Integration with various Linux technologies ❺ – Integration with various back-up solutions ❻ – Can be used for p2p, p2v, v2p and v2v ❼ – Makes recovery as easy as possible ❽
4. How is Rear used ? • Creating Rear boot media: rear mkrescue – Copies kernel, modules, minimal system – Saves storage layout, network configuration – Write (and transfer) boot media • Restore system – Boot Rear media – Optionally, modify storage/network config – Run: rear recover – Rear parses layout then creates diskrestore script – Rear initiates restore or prompts for restore
5. Rear functionality • Supported storage technologies ❺ – HP SmartArray, SW RAID, iSCSI, DRBD, multipath – LVM, LUKS, ext2/ext3/ext4, xfs, jfs, vfat • Boot media or remote storage ❺ – Tape, ISO, USB, eSATA, … – NFS, CIFS, rsync, HTTP, FTP, SFTP, ... • Back-up backends ❻ – TSM, HP DP, Symantec NetBackup, Bacula – tar, rsync • Integrates with monitoring
6. Nifty features to help relax ❽ • Local GRUB integration (password protected) • Serial console support (think: disaster) • History-stuffing during recovery • Network and SSH key integration • Layout code guides you through recovery – Menu's and command-line in one session – Provides original storage info • Beep, UID led and USB suspend integration • Syslinux management • Log-file on recovery media
7. Use case: Belgian Federal Police • Requirements: – About 200 sites with each a set of Linux servers – Each server comes with a tape-drive – Single bootable tape to: • Restore complete system • Restore from back-up – Support for various technologies • HP SmartArray, SW RAID, DRBD, LVM • OBDR, Bacula tape support • RHEL 4, RHEL5 and RHEL6 support – End-user documentation in 3 languages
8. Use case: Belgian Federal Police (2) • Solution: – All requirements implemented but... – Newer systems did not support bootable tapes... – USB is much more flexible than tape anyway • Stores multiple rescue images of multiple systems • Easier workflow (udev): insert, wait, pull (2 min max) • Cheaper • Implementation is more reliable – Bonus implementation of flexible layout – Support migration scenarios – Integrates with monitoring (Nagios/Opsview)
9. Use case: Belgian Federal Police (3) • Rear config for USB rescue media: BACKUP=BACULA OUTPUT=USB USB_DEVICE=/dev/disk/by-label/REAR-000 • Rear config for USB backup media: BACKUP=NETFS OUTPUT=USB USB_DEVICE=/dev/disk/by-label/REAR-000 ONLY_INCLUDE_VG=( vg00 ) EXCLUDE_MOUNTPOINTS=( /data )
10. Use case: Belgian Federal Police (4) • Rear config for OBDR rescue tapes: BACKUP=BACULA OUTPUT=OBDR BEXTRACT_DEVICE=Ultrium-1 BEXTRACT_VOLUME=VOL-* • Rear config for OBDR backup tapes: BACKUP=NETFS OUTPUT=OBDR TAPE_DEVICE=/dev/nst0
11. Use case: Centralize images • Requirements: – Remote rescue images – Removable media for off-site storage – Easy restore of physical hosts and guests • Solution: – Cron creates image when Rear detects change – Images pushed through HTTP to PXE server/host – Stored on USB disks, rotated every week
12. Use case: Centralize images (2) • Label USB disk(s) and mount • Configure Apache to allow HTTP PUT to USB disk • Rear config in /etc/rear/local.conf: BACKUP=BACULA OUTPUT=ISO ISO_URL=http://server:port/path/ • Rear cron-job at /etc/cron.d/rear: 30 0 1 * * root /usr/sbin/rear mkrescue 30 1 * * * root /usr/sbin/rear checklayout || /usr/sbin/rear mkrescue
13. Use case: Migrations • Physical system with HW RAID • Storage needs more capacity • Decision is to replace disks • Solution: – Run Rear with rescue on USB or bootable tape, and backup to tape – Replace disks – Boot Rear rescue image – Recover (optionally extend storage layout)
14. Rear command line [root@moria rear]# rear help Usage: rear [-dDsSvV] [-r KERNEL] COMMAND [-- ARGS...] -snip- List of commands: checklayout check if the disk layout has changed dump dump configuration and system information format format and label media for use with rear mkbackup create rescue media and backup system mkbackuponly backup system without creating rescue media mkrescue create rescue media only recover recover the system; valid during rescue validate submit validation information Use 'rear -v help' for more advanced commands.
15. Rear command line (2) [root@moria rear]# rear help Usage: rear [-dDsSvV] [-r KERNEL] COMMAND [-- ARGS...] Available options: -d debug mode; log debug messages -D debugscript mode; log every function call -r KERNEL kernel version to use -s simulation mode; show included scripts -S step-by-step mode; ack each script one-by-one -v verbose mode; show more output -V version information -snip-
16. Hacking on Rear • It is Bash ! ❶ • Join the mailinglist • Understand modular framework and workflows ❶ – Use: rear -s <workflow> • Logging – Logfile in: /tmp/rear-hostname.log • Debugging ❾ – Verbose: rear -v – Debug: rear -d – Tracing: rear -D
17. Project future • Functionality – Improved rsync support (like rsnapshot or rbme) – More back-up backend integration – PXE integration / timemachine workflow • Development – Re-organize code base – Release management needs a better process – Website and documentation not up-to-date – Continuous testing scenarios
18. Rear Development • Development team – Schlomo Schapiro and Gratien D'haese (authors) – Jeroen Hoekx and Dag Wieërs (new contributors) • Development at Sourceforge Github → – http://github.com/rear/ – rear-users@lists.sourceforge.net – http://rear.sourceforge.net/ → http://rear.github.com/
19. Summary: 10 reasons • Modular framework in Bash • Easy to extend and customize • Easy to deploy • Set up and forget nature • Integrates various Linux technologies • Integration various back-up solutions • Integrates with monitor- ing • Can be used for migra- tions • Makes recovery as easy as possible • Nice developers ❿
20. Thank you for listening Any questions, ideas, pull-requests ?
21. Live USB demo • Demo USB/udev integration (check udev config !) – Prepare USB stick: rear format /dev/sdb – Re-insert USB stick and wait until light goes out • Demo restore procedure (disable udev rule !) – Boot from KVM virtual machine – Re-insert USB stick and start virt-manager – Create VM with 4GB disk and boot VM – Show bash history and perform: rear recover – Show menu system and modify sizes