Best Recovery plan for MergeReplication

hi all,
i established merge replication between two servers with no synch option.i
dont have any idea of how to restore it original is it fails.how can i
restore both publisher and subscriber with out any data loss.what is the
recovery plan i have to use.
your help is appreciated
thanks
reddy
thanks paul,
my doubt is the replication is stopped without synchronising the data from
publisher to subscriber.the data is available at publisher and not in
subscriber.in this case which steps i have to follow.just i can take a backup
of publisher and restore it in the original and start connecting to
subscriber.is it works.please help
thanks
reddy
"Paul Ibison" wrote:

> Reddy,
> you can backup your publisher, distributor and
> subscribers. The recovery mode is not important in the
> sense that any one will work for replication, and the
> usual considerations apply - eg if you want a more
> granular backup strategy, full recovery mode and
> transaction log backups are used.
> After you restore a publisher's backup, depending on your
> situation, you might want to reinitialize or you may want
> to synchronize your publication database immediately with
> a subscription database that has the latest data, and
> attempt to recover any changes synchronized with that
> replica but not included in the most recent publication
> database backup of publication database transaction log
> backup.
> Assuming you haven't changed the replication
> configuration, you don't need to restore the distribution
> database to a consistent point in time.
> BTW BOL has a good section on this : Strategies for
> Backing Up and Restoring Merge Replication.
> HTH,
> Paul Ibison
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Reddy,
you mention that 'replication is stopped'. What error
message do you receive when you run the merge agent. This
is the crucial bit and it may not be necessary/helpful to
restore a backup.
Regards,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Best practices for backup and restore of large replicated databases

Hello,
I am working on a project where we have a large database that is replicated.
My task is to create a backup/restore plan for this project.
I know the basics for backup/restore, but are looking for best practices and
experiences from you who have done this already on a large scale.
Both publisher and subscribers are allowed to do updates. Restore time at
subscribers have to be short and therefore I am looking for a solution where
both publisher and subscribers are backup up.
Thanks in advance for any pointers to white papers, books, emails, etc.
Best regards,
Vemund
Hi Vemund,
Thanks for your post and I would like to take ownership of this thread and
help you with this issue.
Based on my scope, I understood that you would like to find the best
practise about large scale replicated database backup and restore strategy.
Have I understood you? Correct me if I was wrong.
First of all, please understood that it is hard to say what is the best
practice for your porject as I am not sure how much important is the data
for you and how much data lose could be acceptable. You should discussed
this with your users and find the best strategy for your project.
Generally speaking, here are some general recommendations on database
disaster recovery strategy:
1. Make regular backups that reflect your backup strategy. Ask yourselves
the question - how much data can I afford to lose? (1 min, 1 hour, 1 day
worth). Then ensure that the frequency of the backups reflects the answer
to that question.
2. Make backup to a different media from where the database file reside.
That way you protect against a central point of failure. You can consider
backing up to tape or to another disk (share). Consider moving the backed
up data off-site to another location to protect against disasters like
fires, floods, hurricanes, tornadoes, etc.
3. Test your backups on a regular basis by ensuring they are restore-able
on another system. Then run DBCC CHECKDB on those to ensure the original
database or the backup are not damaged.
4. Keep in mind that the data stored in your database(s) may be one of the
most valuable assets your organization has!
In addition, please review the following information in SQL Books On-Line
"Designing a Backup and Restore Strategy"
Here are some precautions a database administrator should take to ensure
the safety of the data:
1. It is always a good idea to ensure that your backup strategy is
sufficient to recover from a catastrophic failure. Offsite storage and
other precautions are appropriate.
2. Test the database restore operation in a secondary or test database on a
frequent basis.
3. Ensure that any caching devices can handle all failure situations (power
outage, bad sectors, bad drives, system outage, lockups, power spike, and
so forth).
4. Ensure that your caching device:
-- Has integrated battery backup.
-- Can reissue writes on power up.
-- Can be fully disabled if necessary.
-- Handles bad sector re-mapping realtime.
5. Enable torn page detection; it has little performance impact.
6. Configure RAID drives allowing for a hot swap of a bad disk drive, if
possible.
7. Use newer caching controllers that allow addition of more disk space
without
restarting the OS. This can be an ideal solution.
Check the following which covers some of this in detail:
SQL Server capacity and storage guide:
http://www.microsoft.com/technet/pro...n/sqlops6.mspx
Windows backup guide:
http://www.microsoft.com/technet/pro...aintain/backup
rest/br04.mspx
Moreover, here is one more WebCast for you, which will discuss Microsoft
SQL Server database files, the different kinds of database backup options
that are available in SQL Server 2000, and some of the factors to consider
when you design a backup strategy. It will talk about best practices for
backing up and restoring database files. It will review some case studies
and talk about how to troubleshoot problems with backup and restore
operations.
Support WebCast: Microsoft SQL Server 2000: Understanding Backup and Restore
http://support.microsoft.com/?id=329833
Thank you for your patience and corperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Mingqing Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||Hi Vemund,
I am just checking on your progress regarding the information that was sent
you! I wonder whether my suggestion is useful or you would like to receive
more information on this.
If you encounter any difficulty, please do not hesitate to let me know.
Please post here and let me know the status of your issue. Looking forward
to hearing from you soon
Sincerely yours,
Mingqing Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
sql

best practice for copying between 2000 and 2005

currently built a new server with sql server 2005,
whats the best practise for copying the databases from a sql 2000 machine ?
backup / restore ? - i tried the copy wizard and it kept falling overNot sure if it is best practice. But I have been using Backup/Restore to
upgrade (or migrate) databases from SQL2000 to SQL2005 and found it work
fine.
Linchi
"luna" <luna@.themoon.com> wrote in message
news:p4sGf.16419$Fy4.3228@.newsfe4-win.ntli.net...
> currently built a new server with sql server 2005,
> whats the best practise for copying the databases from a sql 2000 machine
> ?
> backup / restore ? - i tried the copy wizard and it kept falling over
>|||"Linchi Shea" <linchi_shea@.NOSPAMml.om> wrote in message
news:evdU6HSLGHA.984@.tk2msftngp13.phx.gbl...
> Not sure if it is best practice. But I have been using Backup/Restore to
> upgrade (or migrate) databases from SQL2000 to SQL2005 and found it work
> fine.
> Linchi
>
great i'll try that today!
mark

best practice for copying between 2000 and 2005

currently built a new server with sql server 2005,
whats the best practise for copying the databases from a sql 2000 machine ?
backup / restore ? - i tried the copy wizard and it kept falling overNot sure if it is best practice. But I have been using Backup/Restore to
upgrade (or migrate) databases from SQL2000 to SQL2005 and found it work
fine.
Linchi
"luna" <luna@.themoon.com> wrote in message
news:p4sGf.16419$Fy4.3228@.newsfe4-win.ntli.net...
> currently built a new server with sql server 2005,
> whats the best practise for copying the databases from a sql 2000 machine
> ?
> backup / restore ? - i tried the copy wizard and it kept falling over
>|||"Linchi Shea" <linchi_shea@.NOSPAMml.om> wrote in message
news:evdU6HSLGHA.984@.tk2msftngp13.phx.gbl...
> Not sure if it is best practice. But I have been using Backup/Restore to
> upgrade (or migrate) databases from SQL2000 to SQL2005 and found it work
> fine.
> Linchi
>
great i'll try that today!
mark

best practice for copying between 2000 and 2005

currently built a new server with sql server 2005,
whats the best practise for copying the databases from a sql 2000 machine ?
backup / restore ? - i tried the copy wizard and it kept falling over
Not sure if it is best practice. But I have been using Backup/Restore to
upgrade (or migrate) databases from SQL2000 to SQL2005 and found it work
fine.
Linchi
"luna" <luna@.themoon.com> wrote in message
news:p4sGf.16419$Fy4.3228@.newsfe4-win.ntli.net...
> currently built a new server with sql server 2005,
> whats the best practise for copying the databases from a sql 2000 machine
> ?
> backup / restore ? - i tried the copy wizard and it kept falling over
>
|||"Linchi Shea" <linchi_shea@.NOSPAMml.om> wrote in message
news:evdU6HSLGHA.984@.tk2msftngp13.phx.gbl...
> Not sure if it is best practice. But I have been using Backup/Restore to
> upgrade (or migrate) databases from SQL2000 to SQL2005 and found it work
> fine.
> Linchi
>
great i'll try that today!
mark

Beginner at Backups

I've spent the afternoon reading as much as possible on how to backup and
restore databases except there are a couple of small areas I can't quite get
my head round, so apologies for the beginners question but here goes:
I can set up a disk backup device and then every night run the 'Backup
Database' command to back up our database to a local folder, on top of this
I can run the 'backup log with truncate_only' every 20 minutes to provide
even better restore capability. I have tested these functions and
successfully restored the DB, but in this scenario the backup device is one
file and will simlpy keep growing every day. How can I overcome this? Should
I be creating a new file for every day and then deleting old files? Also,
should each transaction log be backed up to a new file - if not then how do
you know when to start a new backup file for the transaction logs without
the possibility of loosing data?
Cheers, TomHi,
Use the INIT option along with BACKUP database command to reinitialize the
file every time.
Backup database dbname to device_name with INIT
See books online for more detail
Thanks
Hari
MCDBA
"Tom Clark" <tom_clark100@.hotmail.com> wrote in message
news:eTN0zsweEHA.140@.TK2MSFTNGP12.phx.gbl...
> I've spent the afternoon reading as much as possible on how to backup and
> restore databases except there are a couple of small areas I can't quite
get
> my head round, so apologies for the beginners question but here goes:
> I can set up a disk backup device and then every night run the 'Backup
> Database' command to back up our database to a local folder, on top of
this
> I can run the 'backup log with truncate_only' every 20 minutes to provide
> even better restore capability. I have tested these functions and
> successfully restored the DB, but in this scenario the backup device is
one
> file and will simlpy keep growing every day. How can I overcome this?
Should
> I be creating a new file for every day and then deleting old files? Also,
> should each transaction log be backed up to a new file - if not then how
do
> you know when to start a new backup file for the transaction logs without
> the possibility of loosing data?
> Cheers, Tom
>|||1. With TRUNCATE Only will ONLY truncate the logs (Basically smokes Em)
2. Instead of overwriting the backup file each night, it is fairly typical
to move the OLD Backup to an archive location and save a few previous
backups. OR you can just delete it and replace it with the new backup file.
We typically name our Backup Files with a date time element
...\Backups\DatabaseName\Full\DatabaseNameXX_FULL_MMDDYYYYMMSS.Bak
Where XX is the File Number (We create 4 seperate files for each full backup
to improve backup performance as SQL Server can write to multiple files at
once using multiple threads)
3. We write each transaction backup to a seperate file following the same
naming convention.
...\Backups\DatabaseName\TRXN\DatabaseName_Trnxn_MMDDYYYYMMSS.Bak
we backup our transaction logs every 15 minutes.
AFTER each successful FULL Backup, we move the Old Transaction Logs to an
Archive Location. in the archive folder we keep 48 hours of logs. We delete
files older than 48 hours.
this may not be perfect, but it works for us and is a good start for you.
Cheers,
Greg Jackson
PDX, Oregon|||Cheers Greg, this was exactly the kind of answer I was after!
Thinking on though, if you had to do a restore and then apply all the logs
up to the last log backup, would you do this by script (or apply each
transaction log by hand) and if so how? The testing I've done has only been
with a small number of log files and so I have applied them one by one.
"Jaxon" <GregoryAJackson@.hotmail.com> wrote in message
news:eb68X3weEHA.4068@.TK2MSFTNGP11.phx.gbl...
> 1. With TRUNCATE Only will ONLY truncate the logs (Basically smokes Em)
> 2. Instead of overwriting the backup file each night, it is fairly
typical
> to move the OLD Backup to an archive location and save a few previous
> backups. OR you can just delete it and replace it with the new backup
file.
> We typically name our Backup Files with a date time element
> ...\Backups\DatabaseName\Full\DatabaseNameXX_FULL_MMDDYYYYMMSS.Bak
> Where XX is the File Number (We create 4 seperate files for each full
backup
> to improve backup performance as SQL Server can write to multiple files at
> once using multiple threads)
> 3. We write each transaction backup to a seperate file following the same
> naming convention.
> ...\Backups\DatabaseName\TRXN\DatabaseName_Trnxn_MMDDYYYYMMSS.Bak
> we backup our transaction logs every 15 minutes.
> AFTER each successful FULL Backup, we move the Old Transaction Logs to an
> Archive Location. in the archive folder we keep 48 hours of logs. We
delete
> files older than 48 hours.
>
> this may not be perfect, but it works for us and is a good start for you.
>
> Cheers,
>
> Greg Jackson
> PDX, Oregon
>|||you can do it by hand or by script if you wanted.
I've actually done it by hand most often in past.
GAJ