06-29-2016 03:18 PM - edited 06-29-2016 03:19 PM
If I want to back out from the hotfix I alredy applied what should I do ?
Do I just restore the backup taken ? or is there any another procedure ?
If restoring the backup (i mean backup of both config and home directories...for example "SAS94BASEprod" which consists SAS_94 and config directories) is an option ..what are the things needed to do.. just rename the backup to original name ? (for example.. rename "SAS94BASEprod_proir_hotfix" to "SAS94BASEprod") thats all?
06-29-2016 04:55 PM
Hotfixes can range from a simple version bump of a single file to a whole set of files plus updates to metadata, configuration and rebuild/redeployment ofd midtier components. I doubt there would be a viable one-size-fits-all apporach to reverting any hotfix other than going back in time by restoring a backup. And then that backup would involve a concise set of all of the above: binaries, metadata, configuration, content in the content server, framework database. Possibly destroying user data in the process. Also there is the deployment registry that needs to be updated to the new situation. In all, an intricate network of relationships that is easily disturbed. We now have the Backup&Restore Tool that takes care of this.
Simple hotfixes leave a log of files replaced and you may find it easy to undo. Also we have seen new hotfixes that aim at reverting existing ones due to adverse effects.
In this respect we may conclude that the SAS9 deployment has become convoluted over the years. No surprise SAS Vaiya is at the horizon, promising to take care of a lot of these and reated deployment headaches that are now synonymous to SAS (and probably bringing a few new ones).
Oke, enough. Off the soap box.
06-30-2016 03:40 AM
Hi, as @jklaverstijn mentioned, some of them you can backtrack thanks to the logs and instructions, some of them are harder to rollback or preferable not to rollback.
Something that can help is version control (SVN, CVS, Git, etc). Tee same that you can create branches on code and rollback to previous states, you can have versioning on any file system element, such as SAS binaries and SAS configuration.
This will be always much better than recovering from a backup and such other nasty procedures.
I cannot ensure anything of course, but I have the feeling that SAS Viya will have more integration with version control.
In the meantime, you can have a look to a SAS paper/proceeding provided by Alec Fernandez, Preparing for a SAS® 9.4 Deployment and Managing That Deployment Throughout Its Lifecycle: http://support.sas.com/resources/papers/proceedings16/SAS6501-2016.pdf
For now, you can do it, and be mindful when taking the decission of rolling back a hotfix.
07-01-2016 02:10 AM
if your servers on VM's take snapshots before applying the hotfix and roll back if the changes are not good.
07-01-2016 10:13 AM
A VM snapshot recovery will work only if there is no user content (metadata, filesystem, dbs, etc) modified in the time between you applied the hotfix and you actually recover from it. Otherwise users will lose their data.
Therefore your approach is OK if the recovery is inmediate after you apply the hotfix and it doesn't work. But if you apply the hotfix, everything seems just fine and after a couple of days (or 1 month) the users say " this isn't working as expected" or you find other kind of problems and you need to recover to a previous state... then you need a different approach.
02-01-2018 04:09 PM
Have there been any updates to this issue since July 2016? Do SAS Admins have a process to roll back hot fixes that are not System based?
02-02-2018 02:02 AM
Fully agree with the points made earlier.
I would also like to tag on another consideration, that being 'What hotfixes to apply ?'
There is a school of thought that says ALL available hotfixes should be applied. Given the complexity of rollbacks (as detailed in this post) and the fact that some hotfixes actually introduce new errors, I'm personally not of this opinion. My take is, if you have a specific problem that is fixed with a specific hotfix, then ok, go for it and follow the recommendations in this post. If you don't need a hotfix, you don't need it.
Then, the big one. Given that maintenance packs are cumulative of hotfixes and also introduce new product functionality, I'm firm of the opinion that maintenance packs should always be applied when released.
So what it comes down to for me is frequency of change vs. positive impact. By following my approach I feel that the system will stay relative bug-free with a low frequency of change, so you only need to worry about the whole rollback issue, a few times a year, if that. Maintenance packs are released few and far between. With maintenance packs you will (hopefully) go through a proper process that includes FULL backups, intensive UAT testing and a COMPREHENSIVE backout plan.
My 2 cents.....
02-02-2018 11:29 AM
I just loaded to current all hotfixes on my PC install of SAS, it introduced a bug that broke my code having to do with Oracle db connection and metadata data sizes. I have weekly responsibilities to make snapshots of my institutions data for a data warehouse I help support. We are a small shop and as a practice try to come to current just once a year. With this as a norm, I don't have a lot of time to spend to determine if we have bugs I "need" to fix, or if their are new feature we "want" to use. In my case I want SAS to make it as easy as can be to just go on auto pilot with SAS updates. I know it's not an method a firm with a 100+ SAS users would use, but I have too many fires burning to keep up with every possible issue with SAS Foundation. so these are my small shop, simple minded thoughts on the topic.
02-03-2018 06:19 AM
Yes, that should work, Hoping that when the backup was taken the SAS Services were down.
To restore, Shutdown the services, Revert the backup directories and start the Services again.
Hope this helps.