{"id":2625,"date":"2011-02-02T03:39:26","date_gmt":"2011-02-01T17:39:26","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=2625"},"modified":"2018-12-11T18:21:20","modified_gmt":"2018-12-11T08:21:20","slug":"differential-backups-and-recoveries","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2011\/02\/02\/differential-backups-and-recoveries\/","title":{"rendered":"Differential backups and recoveries"},"content":{"rendered":"<p>Late last year while in New Zealand, I attended a {Product} Overview session. Unfortunately, I had to leave after an hour, and during that time only managed to hear a couple of new things about {Product}. Instead, my colleagues and I spent most of the time trying to correct the {Vendor} technical specialist, who was regurgitating some old FUD about NetWorker.<\/p>\n<p>One of the funniest pieces of FUD that I heard from the {Vendor} rep was that &#8220;workgroup&#8221; (ha!) products like NetWorker will waste time during the recovery process when differential backups have been run. Drawing up a simple table like the following. The argument used ran along these lines:<\/p>\n<ul>\n<li>Weekend \u2013 Full backup (i.e., 100%)<\/li>\n<li>Monday \u2013 Backup 5% change<\/li>\n<li>Tuesday \u2013 Backup 10% change<\/li>\n<li>Wednesday \u2013 Backup 15% change<\/li>\n<li>Thursday \u2013 Backup 20% change<\/li>\n<li>Friday \u2013 Backup 25% change<\/li>\n<\/ul>\n<p>Now, as I point out in <a title=\"Enterprise Systems Backup and Recovery: A corporate insurance policy\" href=\"http:\/\/www.enterprisesystemsbackup.com\" target=\"_blank\">my book<\/a>, while one must consider the potential that the unique changed files in set of differential backups <em>may<\/em> be 100% on each day, it&#8217;s not always going to be the case. In fact, only in fairly niche areas or situations will this be so. To be more accurate, a differential backup model may look more like:<\/p>\n<ul>\n<li>Weekend \u2013 Full backup (i.e., 100%)<\/li>\n<li>Monday \u2013 Backup 5% change.<\/li>\n<li>Tuesday \u2013 Backup 7% change.<\/li>\n<li>Wednesday \u2013 Backup 9% change.<\/li>\n<li>Thursday \u2013 Backup 10% change.<\/li>\n<li>Friday \u2013 Backup 11% change.<\/li>\n<\/ul>\n<p>(That is \u2013 in most sites where differentials are used, the unique files that change each day will be minimal.)<\/p>\n<p>Now, regardless of which model happens within an environment, the {Vendor} representative bravely then tried to assert that &#8220;with NetWorker, that means a full recovery on Friday would need to pull back 125% of the data!&#8221;<\/p>\n<p>That statement is of course about as accurate as &#8220;croc shoes are cool&#8221;.<\/p>\n<p>There are two types of implied FUD In this statement &#8211; and both are incorrect. They are:<\/p>\n<ul>\n<li>The FUD that if you backup the same file in both a full and a differential, NetWorker would recover <em>both<\/em> files, first the one from the full, then the one from the differential, in order to complete the recovery.<\/li>\n<li>The FUD that a filesystem recovery from fulls + X might pull back all files that were backed up, rather than a point in time view of the filesystem as of the last backup.<\/li>\n<\/ul>\n<p>Thankfully, like Elmer, both of these FUDs are relatively easy to put to rest. I&#8217;ll do them in reverse order, since disproving the second puts us in an easy position to disprove the first FUD.<\/p>\n<p>Scenario:<\/p>\n<ul>\n<li>Schedule called &#8220;TestDiff&#8221;: full, 5, 5, 5, 5, 5, 5<\/li>\n<li>Group called &#8220;TestDiff&#8221;: Using schedule &#8220;TestDiff&#8221;<\/li>\n<li>Client tara in group &#8220;TestDiff&#8221; has save set: \/root\/casestudy<\/li>\n<\/ul>\n<p>Initial content of \/root\/casestudy:<\/p>\n<pre>[root@tara ~]# <strong>ls -al \/root\/casestudy<\/strong>\ntotal 30796\ndrwxr-xr-x &nbsp;2 root root &nbsp; &nbsp; 4096 Feb &nbsp;2 03:41 .\ndrwxr-x--- 22 root root &nbsp; &nbsp;20480 Feb &nbsp;2 03:34 ..\n-rw-r--r-- &nbsp;1 root root 10485760 Feb &nbsp;2 03:41 full1.dat\n-rw-r--r-- &nbsp;1 root root 10485760 Feb &nbsp;2 03:41 full2.dat\n-rw-r--r-- &nbsp;1 root root 10485760 Feb &nbsp;2 03:41 full3.dat<\/pre>\n<p>So that&#8217;s 30MB of data. Our first backup will by necessity be a full, and we&#8217;ll follow that with an mminfo so we can see how much data has been backed up:<\/p>\n<pre>[root@tara ~]# <strong>savegrp -l full TestDiff<\/strong>\nFeb &nbsp;2 03:44:35 tara logger: NetWorker media: (waiting) Waiting for 1 writable volume(s) to backup pool 'TestDiff' tape(s) on tara.pmdg.lab\n[root@tara ~]# <strong>mminfo -q \"name=\/root\/casestudy\"<\/strong>\nvolume &nbsp; &nbsp; &nbsp; &nbsp;client &nbsp; &nbsp; &nbsp; date &nbsp; &nbsp; &nbsp;size &nbsp; level &nbsp;name\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 30 MB full &nbsp;\/root\/casestudy<\/pre>\n<p>Now that we&#8217;ve got that initial backup done, we&#8217;ll populate a couple more files into the directory, and do 2 level 5 differential backups:<\/p>\n<pre>[root@tara ~]# <strong>dd if=\/dev\/zero bs=1024k count=10 of=\/root\/casestudy\/1stdiff-1.dat<\/strong>\n10+0 records in\n10+0 records out\n10485760 bytes (10 MB) copied, 0.02353 seconds, 446 MB\/s\n\n[root@tara ~]# <strong>dd if=\/dev\/zero bs=1024k count=10 of=\/root\/casestudy\/1stdiff-2.dat<\/strong>\n10+0 records in\n10+0 records out\n10485760 bytes (10 MB) copied, 0.080027 seconds, 131 MB\/s\n\n[root@tara ~]# <strong>ls -al \/root\/casestudy<\/strong>\ntotal 51308\ndrwxr-xr-x &nbsp;2 root root &nbsp; &nbsp; 4096 Feb &nbsp;2 03:45 .\ndrwxr-x--- 22 root root &nbsp; &nbsp;20480 Feb &nbsp;2 03:34 ..\n-rw-r--r-- &nbsp;1 root root 10485760 Feb &nbsp;2 03:45 1stdiff-1.dat\n-rw-r--r-- &nbsp;1 root root 10485760 Feb &nbsp;2 03:45 1stdiff-2.dat\n-rw-r--r-- &nbsp;1 root root 10485760 Feb &nbsp;2 03:41 full1.dat\n-rw-r--r-- &nbsp;1 root root 10485760 Feb &nbsp;2 03:41 full2.dat\n-rw-r--r-- &nbsp;1 root root 10485760 Feb &nbsp;2 03:41 full3.dat\n\n[root@tara ~]# <strong>savegrp -l5 TestDiff<\/strong>\n[root@tara ~]# <strong>!mminfo<\/strong>\nmminfo -q \"name=\/root\/casestudy\"\nvolume &nbsp; &nbsp; &nbsp; &nbsp;client &nbsp; &nbsp; &nbsp; date &nbsp; &nbsp; &nbsp;size &nbsp; level &nbsp;name\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 30 MB full &nbsp;\/root\/casestudy\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 20 MB &nbsp; &nbsp;5 &nbsp;\/root\/casestudy\n\n[root@tara ~]# <strong>savegrp -l5 TestDiff<\/strong>\n[root@tara ~]# <strong>mminfo -q \"name=\/root\/casestudy\"<\/strong>\nvolume &nbsp; &nbsp; &nbsp; &nbsp;client &nbsp; &nbsp; &nbsp; date &nbsp; &nbsp; &nbsp;size &nbsp; level &nbsp;name\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 30 MB full &nbsp;\/root\/casestudy\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 20 MB &nbsp; &nbsp;5 &nbsp;\/root\/casestudy\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 20 MB &nbsp; &nbsp;5 &nbsp;\/root\/casestudy<\/pre>\n<p>All of that looks completely normal. So, now we&#8217;ll put a couple of more files in the directory &#8211; this time of differing sizes, and run a differential backup as well as the mminfo commands again:<\/p>\n<pre>[root@tara ~]# <strong>dd if=\/dev\/zero bs=512k count=10 of=\/root\/casestudy\/3rddiff-1.dat<\/strong>\n10+0 records in\n10+0 records out\n5242880 bytes (5.2 MB) copied, 0.022319 seconds, 235 MB\/s\n[root@tara ~]# <strong>dd if=\/dev\/zero bs=512k count=10 of=\/root\/casestudy\/3rddiff-2.dat<\/strong>\n10+0 records in\n10+0 records out\n5242880 bytes (5.2 MB) copied, 0.011584 seconds, 453 MB\/s\n\n[root@tara ~]# <strong>savegrp -l5 TestDiff<\/strong>\n[root@tara ~]# <strong>!mminfo<\/strong>\nmminfo -q \"name=\/root\/casestudy\"\nvolume &nbsp; &nbsp; &nbsp; &nbsp;client &nbsp; &nbsp; &nbsp; date &nbsp; &nbsp; &nbsp;size &nbsp; level &nbsp;name\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 30 MB full &nbsp;\/root\/casestudy\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 20 MB &nbsp; &nbsp;5 &nbsp;\/root\/casestudy\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 20 MB &nbsp; &nbsp;5 &nbsp;\/root\/casestudy\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 30 MB &nbsp; &nbsp;5 &nbsp;\/root\/casestudy<\/pre>\n<p>Right, next step is to delete some files &#8211; I&#8217;m going to delete the &#8220;1stdiff*&#8221; files, then run a new backup:<\/p>\n<pre>[root@tara ~]# <strong>rm \/root\/casestudy\/1stdiff-*<\/strong>\nrm: remove regular file `\/root\/casestudy\/1stdiff-1.dat'? <strong>y<\/strong>\nrm: remove regular file `\/root\/casestudy\/1stdiff-2.dat'? <strong>y<\/strong>\n\n[root@tara ~]# <strong>ls -l \/root\/casestudy<\/strong>\ntotal 41032\n-rw-r--r-- 1 root root &nbsp;5242880 Feb &nbsp;2 03:48 3rddiff-1.dat\n-rw-r--r-- 1 root root &nbsp;5242880 Feb &nbsp;2 03:48 3rddiff-2.dat\n-rw-r--r-- 1 root root 10485760 Feb &nbsp;2 03:41 full1.dat\n-rw-r--r-- 1 root root 10485760 Feb &nbsp;2 03:41 full2.dat\n-rw-r--r-- 1 root root 10485760 Feb &nbsp;2 03:41 full3.dat\n\n[root@tara ~]# <strong>savegrp -l5 TestDiff<\/strong>\n[root@tara ~]# <strong>!mminfo<\/strong>\nmminfo -q \"name=\/root\/casestudy\"\nvolume &nbsp; &nbsp; &nbsp; &nbsp;client &nbsp; &nbsp; &nbsp; date &nbsp; &nbsp; &nbsp;size &nbsp; level &nbsp;name\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 30 MB full &nbsp;\/root\/casestudy\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 20 MB &nbsp; &nbsp;5 &nbsp;\/root\/casestudy\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 20 MB &nbsp; &nbsp;5 &nbsp;\/root\/casestudy\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 30 MB &nbsp; &nbsp;5 &nbsp;\/root\/casestudy\n800844L4 &nbsp; &nbsp; &nbsp; tara.pmdg.lab 02\/02\/2011 10 MB &nbsp; &nbsp;5 &nbsp;\/root\/casestudy<\/pre>\n<p>Right, {Vendor} FUD &#8211; are you with us now? We&#8217;ll now delete all the files in the directory and do a recovery and see what we pull back. By rights, it should be <strong>only<\/strong> those files in the directory as of the time of backup &#8211; full1.dat, full2.dat, full3.dat, 3rddiff-1.dat and 3rddiff-2.dat:<\/p>\n<pre>[root@tara casestudy]# <strong>cd \/root\/casestudy<\/strong>\n[root@tara casestudy]# <strong>rm *<\/strong>\nrm: remove regular file `3rddiff-1.dat'? <strong>y<\/strong>\nrm: remove regular file `3rddiff-2.dat'? <strong>y<\/strong>\nrm: remove regular file `full1.dat'? <strong>y<\/strong>\nrm: remove regular file `full2.dat'? <strong>y<\/strong>\nrm: remove regular file `full3.dat'? <strong>y<\/strong>\n[root@tara casestudy]# <strong>recover -s tara<\/strong>\nCurrent working directory is \/root\/casestudy\/\nrecover&gt; <strong>ls<\/strong>\n 3rddiff-1.dat   3rddiff-2.dat   full1.dat       full2.dat       full3.dat\nrecover&gt; <strong>add *<\/strong>\n5 file(s) marked for recovery\nrecover&gt; <strong>volumes<\/strong>\nVolumes needed (all on-line):\n        800844L4 at \/dev\/nst1\nrecover&gt; <strong>recover<\/strong>\nRecovering 5 files into their original locations\nVolumes needed (all on-line):\n        800844L4 at \/dev\/nst1\nTotal estimated disk space needed for recover is 41 MB.\nRequesting 5 file(s), this may take a while...\nRequesting 1 recover session(s) from server.\n.\/full1.dat\n.\/full2.dat\n.\/full3.dat\n.\/3rddiff-1.dat\n.\/3rddiff-2.dat\nReceived 5 file(s) from NSR server `tara'\nRecover completion time: Wed 02 Feb 2011 03:51:43 AM EST\nrecover&gt; <strong>quit<\/strong>\n[root@tara casestudy]# <strong>ls -l<\/strong>\ntotal 41032\n-rw-r--r-- 1 root root  5242880 Feb  2 03:48 3rddiff-1.dat\n-rw-r--r-- 1 root root  5242880 Feb  2 03:48 3rddiff-2.dat\n-rw-r--r-- 1 root root 10485760 Feb  2 03:41 full1.dat\n-rw-r--r-- 1 root root 10485760 Feb  2 03:41 full2.dat\n-rw-r--r-- 1 root root 10485760 Feb  2 03:41 full3.dat<\/pre>\n<p>So, {Vendor} FUD #2 is toast. If we do multiple differential backups (or for that matter, incrementals!) with file deletes happening between backups, NetWorker just recovers the filesystem as of the last point it was backed up \u2013 it doesn&#8217;t try to repopulate files that didn&#8217;t exist as of the last backup.<\/p>\n<p>Let&#8217;s return now to {Vendor} FUD #1 about differential backups in NetWorker. We&#8217;ve got a bunch of files for which we&#8217;ve done differential backups with, and so far all of those files have been backed up to a single volume \u2013 800844L4. So, what I&#8217;m going to do is unmount that tape, mark it as full, then overwrite the file &#8216;full3.dat&#8217;, which will mean it&#8217;ll need a new backup:<\/p>\n<pre>[root@tara casestudy]# <strong>nsrjb -u 800844L4<\/strong>\nInfo: Operation `Eject' in progress on device `\/dev\/nst1'\nJukebox operation finished with status: succeeded\n[root@tara casestudy]# <strong>nsrmm -o full 800844L4<\/strong>\nMark LTO Ultrium-4 tape 800844L4 as full? <strong>y<\/strong>\n[root@tara casestudy]# <strong>dd if=\/dev\/zero bs=1024k count=50 of=full3.dat<\/strong>\n50+0 records in\n50+0 records out\n52428800 bytes (52 MB) copied, 0.249461 seconds, 210 MB\/s\n[root@tara casestudy]# <strong>!savegrp<\/strong>\nsavegrp -l5 TestDiff\nFeb  2 03:56:29 tara logger: NetWorker media: (waiting) Waiting for 1 writable volume(s) to backup pool 'TestDiff' tape(s) on tara.pmdg.lab\n[root@tara casestudy]# <strong>!mminfo<\/strong>\nmminfo -q \"name=\/root\/casestudy\"\n volume        client       date      size   level  name\n<em>800843L4<\/em>       tara.pmdg.lab 02\/02\/2011 81 MB    5  \/root\/casestudy\n800844L4       tara.pmdg.lab 02\/02\/2011 30 MB full  \/root\/casestudy\n800844L4       tara.pmdg.lab 02\/02\/2011 20 MB    5  \/root\/casestudy\n800844L4       tara.pmdg.lab 02\/02\/2011 20 MB    5  \/root\/casestudy\n800844L4       tara.pmdg.lab 02\/02\/2011 30 MB    5  \/root\/casestudy\n800844L4       tara.pmdg.lab 02\/02\/2011 10 MB    5  \/root\/casestudy<\/pre>\n<p>Our new backup is sitting on 800843L4 &#8211; a different tape. I&#8217;ll now delete and recover full3.dat, and demonstrate that NetWorker doesn&#8217;t do anything so stupid as the notion of recovering the file twice:<\/p>\n<pre>[root@tara casestudy]# <strong>rm full3.dat<\/strong>\nrm: remove regular file `full3.dat'? <strong>y<\/strong>\n[root@tara casestudy]# <strong>recover<\/strong>\nCurrent working directory is \/root\/casestudy\/\nrecover&gt; <strong>add full3.dat<\/strong>\n\/root\/casestudy\n1 file(s) marked for recovery\nrecover&gt; <strong>volumes<\/strong>\nVolumes needed (all on-line):\n        800843L4 at \/dev\/nst2\nrecover&gt; <strong>recover<\/strong>\nRecovering 1 file into its original location\nVolumes needed (all on-line):\n        800843L4 at \/dev\/nst2\nTotal estimated disk space needed for recover is 51 MB.\nRequesting 1 file(s), this may take a while...\nRequesting 1 recover session(s) from server.\n.\/full3.dat\nReceived 1 file(s) from NSR server `tara.pmdg.lab'\nRecover completion time: Wed 02 Feb 2011 03:57:57 AM EST\nrecover&gt; <strong>quit<\/strong><\/pre>\n<p>Now, just to prove that I&#8217;m not incorrectly trusting NetWorker, here&#8217;s the <em>nsr_render_log<\/em> output for the daemon.raw from the time of recovery \u2013&nbsp;see if you can spot how many tapes we used:<\/p>\n<pre>70920 02\/02\/2011 03:57:42 AM  0 0 2 2426823904 26733 0 tara.pmdg.lab nsrd tara.pmdg.lab:root browsing\n70919 02\/02\/2011 03:57:51 AM  0 0 2 2426823904 26733 0 tara.pmdg.lab nsrd tara.pmdg.lab:root done browsing\n70920 02\/02\/2011 03:57:51 AM  0 0 2 2426823904 26733 0 tara.pmdg.lab nsrd tara.pmdg.lab:root browsing\n70911 02\/02\/2011 03:57:53 AM  0 0 2 2426823904 26733 0 tara.pmdg.lab nsrd tara.pmdg.lab:\/root\/casestudy (2\/02\/11) starting read from 800843L4 of 51 MB\n70904 02\/02\/2011 03:57:57 AM  0 0 2 2426823904 26733 0 tara.pmdg.lab nsrd tara.pmdg.lab:\/root\/casestudy (2\/02\/11) done reading 51 MB\n70919 02\/02\/2011 03:57:57 AM  0 0 2 2426823904 26733 0 tara.pmdg.lab nsrd tara.pmdg.lab:root done browsing\n70920 02\/02\/2011 03:57:57 AM  0 0 2 2426823904 26733 0 tara.pmdg.lab nsrd tara.pmdg.lab:root browsing\n42506 02\/02\/2011 03:57:57 AM  2 0 0 2426823904 26733 0 tara.pmdg.lab nsrd recover info: User root on tara.pmdg.lab successfully recovered tara.pmdg.lab's files\n70919 02\/02\/2011 03:58:00 AM  0 0 2 2426823904 26733 0 tara.pmdg.lab nsrd tara.pmdg.lab:root done browsing<\/pre>\n<p>Wait for it, wait for it &#8230; now let&#8217;s see, it used 800843L4. That&#8217;s one tape. That was our second backup of the file. Hmmm, but it <strong>didn&#8217;t<\/strong> pull back the first copy of the file, because that was on 800844L4, and the logs tell us it only read from a single tape.<\/p>\n<p>{Vendor} FUD #1 put to rest too.<\/p>\n<p>The real pity about vendors flinging FUD about other vendors products is that it takes away from time that could be otherwise used productively. In this case, I had been looking forward to getting at least an hour of a {Product} technical briefing. Lamentably, that&#8217;s not what I got.<\/p>\n<p>Maybe next time.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Late last year while in New Zealand, I attended a {Product} Overview session. Unfortunately, I had to leave after an&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":[16,19],"tags":[319,398,1249],"class_list":["post-2625","post","type-post","status-publish","format-standard","hentry","category-networker","category-recovery","tag-differential","tag-fud","tag-networker"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-Gl","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/2625","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=2625"}],"version-history":[{"count":1,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/2625\/revisions"}],"predecessor-version":[{"id":7528,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/2625\/revisions\/7528"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=2625"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=2625"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=2625"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}