For 1 and 4 and 6 . What, You mean your backup group is not using the ARS system (so someone can request a recovery/restore) ;)
Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Steve Kallestad Sent: Thursday, April 11, 2013 2:02 PM To: [email protected] Subject: Re: Taking a database backup with ARServer running. ** Bonus points to Terry for pointing out that the recovery solution is more important than the backup solution. I've seen so many situations where the recovery experience was far from optimal. A list of things to avoid: 1) A single (sometimes external) team is responsible for everyone's backups and is undermanned such that obtaining a backup to recover from takes significant time. 2) Not regularly verifying the backups are recoverable. (i.e. "We had nightly backups but they didn't work") 3) Not testing your recovery process. ("Initial recovery was easy, but then we had to apply 15 transaction logs") 4) Application administrators have no idea how to ask for a recovery once they determine one is necessary. (or no idea how long it takes, or no idea who to get in touch with as a getting started point) 5) Reliance on external vendors at any point in your backup/recovery process who don't have SLAs that match the response you need in a real disaster situation. This one applies to development environments as well. If you have 4 projects reliant on your development system being up and running and the fact that it's a development environment pushes the recovery SLA from 3 hours to 5 days, that's a huge risk. 6) No documented verification process to follow once a recovery has taken place. Just throwing my 2 cents in. Steve -----Original Message----- On Thu, Apr 11, 2013 at 11:02 AM, Terry Bootsma wrote: ** Good database backups do two things; (a) Take a database backup (b) Take a transaction log backup during the time that the database backup was running (included in the backup) As I am sure you already know, this is one of the differences between a SQL database backup and an MS Access DB backup. The included transaction log backup allows the DBMS to restore a database so that it is consistent. So, your database should be consistent from a purely backup/restore basis and from a Remedy-application basis. However, if you need to restore the database from this backup at a later time, you may restore to a point where you were in a middle of some processing, reconciliation, etc. etc. when the database backup was executed.... so the data may not be completely recovered from a business application perspective. If that is the case, you will also need to schedule your periodic transaction log backups to get the db restore to a point where the business data is consistent. Better transaction log recovery tools allow you to restore to a specific transaction/point in time. Scheduling of your database and transaction log backups should take this into consideration. I hope this answers your question. Terry -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jason Miller Sent: April-11-13 12:36 PM To: [email protected] Subject: Re: Taking a database backup with ARServer running. ** Also other admin processes would continue to update the DB. Things like Escalations, Reconciliation Engine, Email Engine, Normalization, SLM. The only way to stop changes to the db is shut down the Remedy apps or put the db in a read-only mode but then the apps would most likely die. Can you specify what you concern is? Our organization and many others restore ARSystem databases from backups all the time without issue. Yes there are probably some records out of sync due to timing of the backups but for our purposes it is good enough. It sounds like you might be doing more than just restoring production to dev where consistency is a bit more critical. Jason -----Original Message----- On Thu, Apr 11, 2013 at 8:02 AM, Longwing, Lj wrote: ** Yes, putting in admin mode would stop all non admin level traffic...but that kinda defeats the purpose of doing it 'online'.... -----Original Message----- On Thu, Apr 11, 2013 at 8:55 AM, Drew Shuller wrote: ** Wouldn't putting the AR Server in Admin Only mode stop any transactions to the db? No one would be able to use the system, but it would take less time that a reboot. Drew JTF-Bravo Honduras -----Original Message----- On Thu, Apr 11, 2013 at 7:19 AM, Longwing, Lj wrote: ** The only thing that should be 'in flight' during a backup would be data, and that is going to happen any time an online backup is done, but the application structure is 'consistent' by the fact that you aren't actively making changes to it, so no concerns from that point. -----Original Message----- On Thu, Apr 11, 2013 at 6:51 AM, team.remedy wrote: ** I know that I can take the DB backup even if the ARServer is running. This isn't my question (I'm also the DBA, I know that I can and I know how to do this ). The matter is if I can consider the ARServer "application consistent" because it's running. ----Messaggio originale---- Data: 11-apr-2013 14.47 A: <[email protected]> Ogg: Re: Taking a database backup with ARServer running. ** BTW its DB activity and not AR. Remedy does not have inbuilt mechanism to backup underlying DB. -----Original Message----- On Apr 11, 2013 6:12 PM, "Mayuresh Wagh" wrote: You should be able to do that. It would be transparent to AR. Online backup is possible. Check with DBA. -----Original Message----- On Apr 11, 2013 2:29 PM, team.remedy wrote: Hi All, Is there a remedy command that place the ARServer in a "consistent state" so i can freely backup the underlying database through database native tools without the need of shutting down the ARServer? The goal is to take a database backup with application consistency having the ARServer up&running, minimizing the downtime. Is there any way? Thanks in advance, Ale. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
