{"id":5329,"date":"2014-10-23T11:49:46","date_gmt":"2014-10-23T01:49:46","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=5329"},"modified":"2018-12-11T13:39:45","modified_gmt":"2018-12-11T03:39:45","slug":"backing-up-renamed-directories","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2014\/10\/23\/backing-up-renamed-directories\/","title":{"rendered":"Backing up renamed directories"},"content":{"rendered":"

Long-term NetWorker administrators may remember that NetWorker used to have a somewhat odd mechanism of dealing with renamed directories. Nowadays the default<\/em> option for any new client is to enable backup renamed directories<\/em>, and this is a good thing, even though it might end up using a bit more backup media.<\/p>\n

To explain the difference between then<\/em> and now<\/em>, and why the new default is so much better, I first have to setup a scenario.<\/p>\n

Consider a client that has a directory called \/renaming\/backup<\/strong>, and underneath that directory there’s another directory called \/renaming\/backup\/alpha<\/strong>. The named saveset for this client will be \/renaming\/backup<\/strong>, which will capture all subdirectories.<\/p>\n

In our scenario, there will first be a full backup of \/renaming\/backup, then the alpha<\/em> directory will be renamed to beta<\/em>, and a new backup taken.<\/p>\n

Temporarily reinstating the old<\/em> mechanism by turning off “backup renamed directories” for this client, there’s a considerable difference between the full backup done with a \/renaming\/backup\/alpha subdirectory and the subsequent incremental with alpha renamed to beta. First, the full:<\/p>\n

\"Backup<\/a><\/p>\n

After that backup was taken, I renamed the alpha<\/em> directory to beta<\/em> and re-ran the backup. Here’s what the savegroup completion looked like:<\/p>\n

\"Backup<\/a><\/p>\n

You’ll note there that the size of the incremental backup of \/renaming\/backup was just 2KB, which would be around consistent with backing up the details associated with a changed directory, but nothing underneath that directory.<\/p>\n

And that was sort of the problem with the old method, right there. A recovery following that second backup of \/renaming\/backup would yield odd<\/em> results:<\/p>\n

[root@centaur backup]# recover<\/strong>\nCurrent working directory is \/renaming\/backup\/\nrecover> add beta<\/strong>\n\/renaming\/backup\/beta\n1 file(s) marked for recovery\nrecover> relocate \/renaming\/recovery\/backup-rename-off<\/strong>\nrecover> recover<\/strong>\nRecovering 1 file from \/renaming\/backup\/ into \/renaming\/recovery\/backup-rename-off\nVolumes needed (all on-line):\n        centaur.003 at AFTD-01\nTotal estimated disk space needed for recover is 36 KB.\nRequesting 1 file(s), this may take a while...\nRecover start time: Mon 20 Oct 2014 19:52:42 AEDT\nRequesting 1 recover session(s) from server.\n91651:recover: Successfully established AFTD DFA session for recovering save-set ID '4114926770'.\n.\/beta\/\nReceived 1 file(s) from NSR server `centaur'\nRecover completion time: Mon 20 Oct 2014 19:52:42 AEDT\nrecover> \n\n[root@centaur backup]# cd ..<\/strong>\n[root@centaur renaming]# ls<\/strong>\nbackup  recovery\n[root@centaur renaming]# cd recovery<\/strong>\n[root@centaur recovery]# ls<\/strong>\nbackup-rename-off\n[root@centaur recovery]# cd backup-rename-off\/<\/strong>\n[root@centaur backup-rename-off]# ls<\/strong>\nbeta\n[root@centaur backup-rename-off]# cd beta<\/strong>\n[root@centaur beta]# ls<\/strong>\n<crickets chirping><\/em><\/pre>\n
To recover the contents of the beta<\/em> directory, one had to instead switch to a browse time before<\/em> the rename happened, and recover the old directory name. As you might imagine, this required rather intimate knowledge for the recovery operator of when directories had been renamed.<\/p>\n
Jumping forward to now<\/em>, we have a much more agreeable mechanism. After a delete of all the backups for the client, the backup process takes up a bit more space, but results in a simpler, more reliable recovery. First, I renamed \/renaming\/backup\/beta back<\/em> to \/renaming\/backup\/alpha. Then, the full backup:<\/p>\n
\"Full<\/a><\/p>\n
After that backup completed, I renamed \/renaming\/backup\/alpha to \/renaming\/backup\/beta and re-ran the backup – again, as an incremental:<\/p>\n
\"Backup<\/a><\/p>\n
You’ll notice in this scenario the incremental is as big as the previous full, since the alpha (or beta) directory is the only subdirectory of \/renaming\/backup.<\/p>\n
However, that little hit on the backup space is more than made up for by a simplified recovery process. Executing a recovery after the second backup completes yields the following results:<\/p>\n
[root@centaur backup]# recover<\/strong>\nCurrent working directory is \/renaming\/backup\/\nrecover> ls<\/strong>\n beta\nrecover> add beta<\/strong>\n11 file(s) marked for recovery\nrecover> relocate \/renaming\/recovery\/backup-renamed-on<\/strong>\nrecover> recover<\/strong>\nRecovering 11 files within \/renaming\/backup\/ into \/renaming\/recovery\/backup-renamed-on\nVolumes needed (all on-line):\n        centaur.003 at AFTD-01\nTotal estimated disk space needed for recover is 1047 MB.\nRequesting 11 file(s), this may take a while...\nRecover start time: Mon 20 Oct 2014 20:03:29 AEDT\nRequesting 1 recover session(s) from server.\n91651:recover: Successfully established AFTD DFA session for recovering save-set ID '4014264195'.\n.\/beta\/file-2MB.dat\n.\/beta\/file-32MB.dat\n.\/beta\/file-1MB.dat\n.\/beta\/file-512MB.dat\n.\/beta\/file-128MB.dat\n.\/beta\/file-4MB.dat\n.\/beta\/file-16MB.dat\n.\/beta\/file-8MB.dat\n.\/beta\/file-256MB.dat\n.\/beta\/file-64MB.dat\n.\/beta\/\nReceived 11 file(s) from NSR server `centaur'\nRecover completion time: Mon 20 Oct 2014 20:03:36 AEDT<\/pre>\n
If the version of NetWorker you’re using was setup more recently, it’s more than likely clients you’ve created have backup renamed directories<\/em> already turned on. If you’re working with an older version of NetWorker, or a NetWorker server that has been in use since version 7.4 or older, it’s possible legacy clients still have the option turned off.<\/p>\n
I heartily recommend all filesystem clients always<\/em> have backup renamed directories<\/em> enabled.<\/p>\n","protected":false},"excerpt":{"rendered":"
Long-term NetWorker administrators may remember that NetWorker used to have a somewhat odd mechanism of dealing with renamed directories. Nowadays the default option…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[5,19],"tags":[138,1190,818,1191],"class_list":["post-5329","post","type-post","status-publish","format-standard","hentry","category-backup-theory","category-recovery","tag-backup","tag-backup-renamed-directories","tag-rename","tag-renamed"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t