05-21-2014 11:45 AM
I wanted to test the metadata recovery. So, i first ran the backup of the metadata in the test environment. Then, i deleted a user and then recovered from the backup.
But i still cant find the user. Is that not what recovery has to do? Why am i not able to see the user?
05-21-2014 12:09 PM
The important thing to appreciate is that Metadata Backup and Recovery utilities backup (and restore) the entire Metadata Server. So when you restore, you are rolling back all metadata to the point in time at which you took the back. If you want to perform a selective restore, you can use the SAS Configuration Wizard to construct a new/temporary Metadata Server into which you can restore a backup - you can then selectively export the item(s) you want to recover and then import just these items into your target server.
However, it seems to me that you are failing at the first or second hurdle. The first hurdle of backing up the Metadata is quite tricky to fail at, so my guess is that the RESTORE is not actually working. If you can share here the exact steps you are going through, I am sure that somebody from the community will be able to help.
05-21-2014 12:18 PM
Thanks for your reply. These are the steps that i carried out:
Since at the time of taking the backup i had 13 users, ideally restoring the metadata should have 13 users, Right?
05-21-2014 01:20 PM
You should certainly expect to return to a state of 13 users.
Can you please share what commands you are issuing for steps #1 and #3.
Please also check this link SAS(R) 9.3 Intelligence Platform: System Administration Guide, Second Edition and confirm that you are following these steps (and not getting a red cross).
05-21-2014 02:11 PM
I am doing it using the SAS Management Console. The version of SAS is 9.3
For taking the backup, i am using the Run Backup Now option in the metadata manager plug-in.
05-21-2014 07:06 PM
I suspect that when you did the restore you replayed all of the transactions in the journal, including the deletion of the user. Pick a time just prior to the deletion of the user and replay the transactions up to that point, so the deletion is not included. You might find this blog post and the referenced SAS documentation useful: Metadata Time Travel with SAS 9.3 - platformadmin.com
[ Unkie - thanks for the mention! ]
05-22-2014 02:27 AM
Paul, You mentioned a common perception mistake of metadata backups. It is the same one as with RDBMS systems.
It is all are nothing approach, not suited for single objects part of that eco-system.
At some moment you have logical correct state off all the related tables/records/data (checkpoint).
You can backup/restore to that moment and perform roll-back roll/forward of modifications from that moment using registered updates.
When you need to be able to view/ (backup/restore) single objects this full approach of metadata is failing.
You clould solve that by saving export packages of needed areas (SLA requirements).
Another confusing topic within this area is DR Disaster Recovery.
In that approach a backup/restore could be an option. But if you go for synchronization and clustering the behavior of that is different again.
You could have a good DR implementation without being able anything being backupped. With that not able going to recover from logical failures.
05-23-2014 01:27 AM
Jaap, you are right that it is a complete restoration of all metadata objects as at a particular point in time, and it is more challenging if you only want to recover a small selection of objects from the past state into the current state. If regular metadata export packages from a change management procedure are not available, one potential option is to schedule some outage for the platform and follow the procedure:
Of course, this is all purely metadata. Sometimes there is associated physical content that also needs to be recovered too. In this case recovering a user's metadata identity only involves metadata, but then again for recovering a single user object, it would most likely be much easier to just recreate it manually than follow the procedure above and schedule outage
05-23-2014 05:37 AM
Ok Paul, This reply I could have expected as having heard before. Still it is not an acceptable approach solving backup/restore questions/requirements. For some reason IT people are wanting to invent over and over again what is already there. Using other words for the confusing not recognizing that. It starts with getting clear the business question/requirements.
We had the DR question and fail-over of the total IT configuration with all logical constraints.
The more detailed objects for the business can be either regular developed (D T A P staging) or done on ad-hoc (end user - interactive) base.
When the requirement is that just that content must be rather quick being set to a previous well known state, that is to solve in KISS approach.
There will commonly also an segregation between DT - A and P as requirement with different metadata-databases.
The release management will have a deployment process needing packages (export/impiort). Save those packages with documented content and you use for the restore requests.
Let an export process of the related involved folders (and all what belongs to that) run at scheduled agreed moments and save those listings.
When a request comes in for a restore use that to fulfill that request. I have seen StigE did this proposal for that approach also (Tricia's blog).
This approach is not really different as well known backup/restore tools for files/data at the OS-level.
Backup - Wikipedia, the free encyclopedia
For the question