Long-term NetWorker administrators may remember that NetWorker used to have a somewhat odd mechanism of dealing with renamed directories. Nowadays the default option for any new client is to enable backup renamed directories, and this is a good thing, even though it might end up using a bit more backup media.
To explain the difference between then and now, and why the new default is so much better, I first have to setup a scenario.
Consider a client that has a directory called /renaming/backup, and underneath that directory there’s another directory called /renaming/backup/alpha. The named saveset for this client will be /renaming/backup, which will capture all subdirectories.
In our scenario, there will first be a full backup of /renaming/backup, then the alpha directory will be renamed to beta, and a new backup taken.
Temporarily reinstating the old 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:
After that backup was taken, I renamed the alpha directory to beta and re-ran the backup. Here’s what the savegroup completion looked like:
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.
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 results:
[root@centaur backup]# recover Current working directory is /renaming/backup/ recover> add beta /renaming/backup/beta 1 file(s) marked for recovery recover> relocate /renaming/recovery/backup-rename-off recover> recover Recovering 1 file from /renaming/backup/ into /renaming/recovery/backup-rename-off Volumes needed (all on-line): centaur.003 at AFTD-01 Total estimated disk space needed for recover is 36 KB. Requesting 1 file(s), this may take a while... Recover start time: Mon 20 Oct 2014 19:52:42 AEDT Requesting 1 recover session(s) from server. 91651:recover: Successfully established AFTD DFA session for recovering save-set ID '4114926770'. ./beta/ Received 1 file(s) from NSR server `centaur' Recover completion time: Mon 20 Oct 2014 19:52:42 AEDT recover> [root@centaur backup]# cd .. [root@centaur renaming]# ls backup recovery [root@centaur renaming]# cd recovery [root@centaur recovery]# ls backup-rename-off [root@centaur recovery]# cd backup-rename-off/ [root@centaur backup-rename-off]# ls beta [root@centaur backup-rename-off]# cd beta [root@centaur beta]# ls <crickets chirping>
To recover the contents of the beta directory, one had to instead switch to a browse time before 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.
Jumping forward to now, 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 to /renaming/backup/alpha. Then, the full backup:
After that backup completed, I renamed /renaming/backup/alpha to /renaming/backup/beta and re-ran the backup – again, as an incremental:
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.
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:
[root@centaur backup]# recover Current working directory is /renaming/backup/ recover> ls beta recover> add beta 11 file(s) marked for recovery recover> relocate /renaming/recovery/backup-renamed-on recover> recover Recovering 11 files within /renaming/backup/ into /renaming/recovery/backup-renamed-on Volumes needed (all on-line): centaur.003 at AFTD-01 Total estimated disk space needed for recover is 1047 MB. Requesting 11 file(s), this may take a while... Recover start time: Mon 20 Oct 2014 20:03:29 AEDT Requesting 1 recover session(s) from server. 91651:recover: Successfully established AFTD DFA session for recovering save-set ID '4014264195'. ./beta/file-2MB.dat ./beta/file-32MB.dat ./beta/file-1MB.dat ./beta/file-512MB.dat ./beta/file-128MB.dat ./beta/file-4MB.dat ./beta/file-16MB.dat ./beta/file-8MB.dat ./beta/file-256MB.dat ./beta/file-64MB.dat ./beta/ Received 11 file(s) from NSR server `centaur' Recover completion time: Mon 20 Oct 2014 20:03:36 AEDT
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 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.
I heartily recommend all filesystem clients always have backup renamed directories enabled.
Hey my friend,
Thanks for good article.
Question for you : does this also apply with differential backup level or only with incr ?
I trend to think for incr only as diff levels are always diffs in regards with previous full or higher level ..
Thanks
TH
Hi Thierry,
While I’ve not explicitly tested it with differential backups, the logic should remain the same – the renamed directory is seen as a change and the contents therein backed up again.
Cheers,
Preston.