{"id":264,"date":"2009-03-30T17:20:56","date_gmt":"2009-03-30T06:20:56","guid":{"rendered":"http:\/\/nsrd.wordpress.com\/?p=264"},"modified":"2018-12-12T16:23:16","modified_gmt":"2018-12-12T06:23:16","slug":"expecting-a-more-complete-backup","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2009\/03\/30\/expecting-a-more-complete-backup\/","title":{"rendered":"Expecting a more complete backup"},"content":{"rendered":"<p>As I point out in my <a title=\"Enterprise Systems Backup: A Corporate Insurance Policy\" href=\"http:\/\/www.amazon.com\/gp\/redirect.html?ie=UTF8&amp;location=http%3A%2F%2Fwww.amazon.com%2FEnterprise-Systems-Backup-Recovery-Corporate%2Fdp%2F1420076396%3Fie%3DUTF8%26s%3Dbooks%26qid%3D1221104920%26sr%3D8-1&amp;tag=entesystbacka-20&amp;linkCode=ur2&amp;camp=1789&amp;creative=9325\" target=\"_blank\">book<\/a>, there&#8217;s a lot of stuff that ends up in datacentres completely unprotected. That includes such components as:<\/p>\n<ul>\n<li>Network switch configurations<\/li>\n<li>Storage switch configurations<\/li>\n<li>PABXs<\/li>\n<li>etc.<\/li>\n<\/ul>\n<p>By &#8220;unprotected&#8221;, I mean not regularly backed up and monitored within the centralised enterprise backup framework.<\/p>\n<p>However, it also covers backups for databases that don&#8217;t have application modules. Over the last few years there&#8217;s been a lot of outcry over a lack of support for MySQL \u2013 personally I&#8217;d prefer more attention be given to PostgreSQL, but either way, these two open source databases also frequently get neglected in centralised backup solutions as well due to the lack of module support.<\/p>\n<p>When it comes to backing up what I&#8217;d traditionally refer to black box devices \u2013 switches, PABXs, etc., you&#8217;re <em>never<\/em> going to get an application module. That doesn&#8217;t mean though that backups for these devices need to stay in the dark ages where every now and then someone logs on to it, retrieves the configuration, saves it to a fileserver somewhere and hopes that it doesn&#8217;t get deleted before the next backup \u2013 or that the backups for it are retained long enough.<\/p>\n<p>To centralise and automate backups for &#8216;non-traditional&#8217; components, you need to start exploring scripting languages. Sure, some devices now support ssh and scp, but even so, there&#8217;ll reach a point where a certain level of interractivity is required to backup a non-traditional device or database, and at that point you need to script.<\/p>\n<p>One of my favourite languages for this purpose is a lesser known one (particularly outside of Unix circles) called <a title=\"Expect\" href=\"http:\/\/en.wikipedia.org\/wiki\/Expect\" target=\"_blank\"><em>expect<\/em><\/a>. If you don&#8217;t want to follow that link yet, but need the elevator pitch for <em>expect<\/em>, it&#8217;s a language that allows you to script an interactive session with a program that would normally reject scripts and require you to manually type the commands. That is, it&#8217;s an <em>automation tool<\/em>.<\/p>\n<p>As I advocate in my book, by using utilities like <em>expect<\/em>, you can design a solution such as the following:<\/p>\n<ul>\n<li>Traditional clients receive standard backups<\/li>\n<li>For non-traditional clients:\n<ul>\n<li>Define a special client (e.g., another instance of the backup servers&#8217; client resource) that makes use of savepnpc for its backups;<\/li>\n<li>The savepnpc component, will, for a pre-script, log on to the non-traditional devices, retrieve their configuration dumps, backups, etc.;<\/li>\n<li>That retrieved data will then be saved as files on the backup server, preferably both in some human-readable format (where applicable), and also in the appropriate format for re-loading the configuration;<\/li>\n<li>Once the savepnpc activities are complete, the local filesystems will be backed up normally using NetWorker, allowing the <em>centralise<\/em> and <em>automated<\/em> backup of non-traditional clients.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Similarly, the same can be achieved for non-supported databases such as MySQL or PostgreSQL:<\/p>\n<ul>\n<li>Database server is configured with savepnpc for its backup command;<\/li>\n<li>The pre-script for the backup server generates a snapshot or exports a dump of the database;<\/li>\n<li>The exported or snapshot region is backed up as part of the traditional filesystem backup.<\/li>\n<\/ul>\n<p>In essence, what I&#8217;m saying is there&#8217;s very little, if no reason, why you can&#8217;t automate and centralise your non-traditional backups in the same way that you use an enterprise class backup product to automate and centralise your traditional backups.<\/p>\n<p>For example, let&#8217;s consider backing up a PostgreSQL database via <em>expect<\/em>, and integrating that backup with regular filesystem backups for the database server. In this case, it&#8217;s only a small database, and PostgreSQL supports hot exports*, so we&#8217;ll do the backup via the PostgreSQL <em>pg_dump<\/em> command.<\/p>\n<p>The <em>pg_dump<\/em> command leverages the security of the database(s) being dumped; thus, if you have a standard PostgreSQL configuration that allows anyone on the local host to connect to any database, you don&#8217;t need any special scripting. But assuming you&#8217;re in an enterprise environment and you have password protected access to the database, you will need to supply a password to the <em>pg_dump<\/em> command for the database to be backed up. The <em>pg_dump<\/em> command however is one of those pesky commands that <em>refuses<\/em> to accept a password as a command line argument**, so we need to look at using <em>expect<\/em> to supply a password for us.<\/p>\n<p>So you&#8217;d start with an <em>expect<\/em> script file, which for a simple database called &#8220;tododb&#8221;, might resemble the following:<\/p>\n<pre>#!\/usr\/bin\/expect -f\nspawn \/usr\/local\/pgsql\/bin\/pg_dump -U backup_user -W -f \/nsr\/backups\/tododb.dump\nexpect \"Password: \"\nsend \"a9d8ea8d12b4b47db8bd833b8fade7b2r\"\nsleep 120<\/pre>\n<p>(For the purposes of what we&#8217;re doing, we&#8217;ll call this file <em>pgbackup.e<\/em> and assume it&#8217;s in the <em>\/home\/postgresql<\/em> directory.)<\/p>\n<p>So what does this do? First, it spawns (or executes) the <em>pg_dump<\/em> command. Then it waits for the &#8220;Password: &#8221; prompt to be supplied by the <em>pg_dump<\/em> command, and when it receives that, it sends the encrypted password. (No, that&#8217;s not the real password I use!)<\/p>\n<p>Because it&#8217;s only a small database, it then waits 2 minutes for the dump to complete before exiting.<\/p>\n<p>You&#8217;d either add into, or wrap around this script, additional commands or scripts to say, confirm that the database dump has been completed successfully, or ensure that multiple copies are being kept on-line, etc., but for the purposes of brevity I&#8217;ll leave those options as exercises for the reader. Since NetWorker doesn&#8217;t provide any environment to the precmd or pstcmd in a savepnpc action, you will need to ensure that at bare minimum you setup an execution environment that configures the <em>PATH<\/em> and the <em>PGDATA<\/em> path correctly. This might resemble the following:<\/p>\n<pre>#!\/bin\/bash\n\nexport PATH=\/usr\/bin:\/bin:\/usr\/sbin:\/sbin:\/usr\/local\/pgsql\/bin\nexport PGDATA=\/usr\/local\/pgsql\/data\n\/home\/postgresql\/pgbackup.e<\/pre>\n<p>For the purposes of this exercise, we&#8217;ll assume this is saved as <em>\/home\/postgresql\/pgbackup.sh<\/em>.<\/p>\n<p>Next, the client needs to be configured to use <em>savepnpc<\/em>. Assuming you wanted to do this for the client <em>cerberus<\/em> in the group <em>Daily Databases<\/em>, you would need to create in<em> \/nsr\/res <\/em>on <em>cerberus<\/em> a file named &#8220;Daily Databases.res&#8221;, with the following content:<\/p>\n<pre>type: savepnpc;\nprecmd: \"\/home\/postgresql\/pgbackup.sh\";\npstcmd: \"\/bin\/sleep 5\";\ntimeout: \"12:00:00\";\nabort precmd with group: No;<\/pre>\n<p>Note that the <em>pstcmd<\/em> content isn&#8217;t really important in this scenario, as we only need to do something <em>before<\/em> the backup runs; I don&#8217;t like to delete this entry though because in the past I&#8217;ve encountered issues with savepnpc backups that were missing either a <em>precmd<\/em> entry or a <em>pstcmd<\/em> entry (admittedly that was some time ago).<\/p>\n<p>With this file in place, all you would need to do is set the <em>backup command<\/em> for the client <em>cerberus<\/em> in the <em>Daily Databases<\/em> group to <em>savepnpc<\/em>; NetWorker will handle the rest.<\/p>\n<p>For more in-depth coverage of choosing what to backup, extending your backups beyond traditional filesystems and databases, and making <em>risk vs cost<\/em> decisions on backup strategies, check out <a title=\"Enterprise Systems Backup: A Corporate Insurance Policy\" href=\"http:\/\/www.amazon.com\/gp\/redirect.html?ie=UTF8&amp;location=http%3A%2F%2Fwww.amazon.com%2FEnterprise-Systems-Backup-Recovery-Corporate%2Fdp%2F1420076396%3Fie%3DUTF8%26s%3Dbooks%26qid%3D1221104920%26sr%3D8-1&amp;tag=entesystbacka-20&amp;linkCode=ur2&amp;camp=1789&amp;creative=9325\" target=\"_blank\">my book<\/a>.<\/p>\n<p>&#8212;<br \/>\n* I.e., can generate an export from an in-use database that can be recovered from later. Not all databases support this.<\/p>\n<p>** Something the programmers of it should be applauded for.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>As I point out in my book, there&#8217;s a lot of stuff that ends up in datacentres completely unprotected. That&hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[13,16,17],"tags":[149,151,614,642,752,1015],"class_list":["post-264","post","type-post","status-publish","format-standard","hentry","category-general-thoughts","category-networker","category-policies","tag-backup-pabx","tag-backup-switch","tag-mysql","tag-non-traditional","tag-postgresql","tag-traditional"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-4g","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/comments?post=264"}],"version-history":[{"count":1,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/264\/revisions"}],"predecessor-version":[{"id":7675,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/264\/revisions\/7675"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}