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
On Thu, Apr 11, 2013 at 11:02 AM, Terry Bootsma <[email protected]>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
>
>
>
>
> ------------------------------
> *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
>
>
> On Thu, Apr 11, 2013 at 8:02 AM, Longwing, Lj <[email protected]> wrote:
>
>> **
>> Yes, putting in admin mode would stop all non admin level traffic...but
>> that kinda defeats the purpose of doing it 'online'....
>>
>>
>> On Thu, Apr 11, 2013 at 8:55 AM, Drew Shuller <[email protected]>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
>>>
>>>
>>> On Thu, Apr 11, 2013 at 7:19 AM, Longwing, Lj <[email protected]>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.
>>>>
>>>>
>>>> On Thu, Apr 11, 2013 at 6:51 AM, [email protected] <
>>>> [email protected]> 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----
>>>>> Da: [email protected]
>>>>> 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.
>>>>>
>>>>> sent using Galaxy Nexus
>>>>> On Apr 11, 2013 6:12 PM, "Mayuresh Wagh" <[email protected]> wrote:
>>>>>
>>>>>> You should be able to do that. It would be transparent to AR. Online
>>>>>> backup is possible. Check with DBA.
>>>>>>
>>>>>> sent using Galaxy Nexus
>>>>>> On Apr 11, 2013 2:29 PM, "[email protected]" <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>> Is there a remedy command that place the ARServer in a "consistent
>>>>>>> state" so i
>>>>>>> can freely backup the underlying database throught 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"
>>>>>>>
>>>>>> _ARSlist: "Where the Answers Are" and have been for 20 years_
>>>>>
>>>>>
>>>>> _ARSlist: "Where the Answers Are" and have been for 20 years_
>>>>>
>>>>
>>>> _ARSlist: "Where the Answers Are" and have been for 20 years_
>>>>
>>>
>>> _ARSlist: "Where the Answers Are" and have been for 20 years_
>>>
>>
>> _ARSlist: "Where the Answers Are" and have been for 20 years_
>>
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
> _ARSlist: "Where the Answers Are" and have been for 20 years_
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
