We have a SQL Server 2008 R2 database that backs up transaction logs every now and then. Today there was a big error in the database caused at around 12am... I have transaction logs up to 8am and then 12am - 16pm - etc.
My question is: can I sort of reverse-merge those transaction logs into database, so that I return to the database state at 8am?
Or is my best chance to recover an older full backup and restore all transaction logs up to 8am?
The first option is preferable since full backup has been performed a bit of a while ago and I am afraid to f*ck things up restoring from there and applying trn logs. Am I falsely alarmed about that? Is it actually possible for anything bad to happen if going by that scenario (restoring the full backup and applying trn logs)?
The fact that you don’t create regular transaction log backups doesn’t affect the success of the recovery process. As long as your database is in the Full recovery model, the transactions are stored in the online transaction log and kept in it until a transaction log backup is made. If you make a transaction log backup later than usual, it only means that the online transaction log may grow and that the backup might be bigger. It will not cause any transaction history to be lost.
With a complete chain of transaction log backups back to 8 AM, you can successfully roll back the whole database to a point in time.
As for restoring the full backup and applying trn logs – nothing should go wrong, but it’s always recommended to test the scenario on a test server first, and not directly in production
To restore to a point in time:
In SSMS expand Databases
Right-click the database, select Tasks | Restore| Database
In the General tab, in the Backup sets the available backups will be listed. Click Timeline
Select Specific date and time, change the Time interval to show a wider time range, and move the slider to the time you want to roll back to
You can find more detailed instructions here: How to: Restore to a Point in Time (SQL Server Management Studio)
Keep in mind that this process will roll back all changes made to the database. If you want to roll back only specific changes (e.g. only recover some deleted data, or reverse wrong updates), I suggest a third party tool, such as ApexSQL Log
Reverting your SQL Server database back to a specific point in time
Restore a database to a point in time
Disclaimer: I work for ApexSQL as a Support Engineer
Related
I have hosted my MySql database on Amazon RDS, and It has last automated snapshot. (e.g. yesterday midnight). Now situation is, I have deleted some of records from a very important table accidentally, and would like to recovery it. I have no additional backup since yesterday midnight. (as mention earlier). Now How should I recover data without taking any downtime?
How do I use point-in-time data recovery?
If someone need more information let me know and sorry for my poor explanation.
Point in time recovery allows you to create an additional RDS instance, based on the data as it existed on your instance at any specific point in time you choose between the oldest available automated backup and approximately 5 minutes ago. All you have to do is select what date and time you need.
There is no disruption or change to your running instance.
The process creates a new instance, which you connect to, collect the data you need in order to get your production system back the way it should be, and then destroy the new instance. Or, depending on what went wrong for you, you could also switch your application to this new instance and destroy the old one, though it seems unlikely that this is what you would want to do. But you can do either.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html
I have no additional backup since yesterday midnight.
Point in time recovery doesn't care. RDS preserves the snapshots as well as a complete, timestamped log of everything that changed between the snapshots. These logs are archived in an area that is not accessible to you... but they are there. RDS will automatically load the most recent snapshot that is earlier than the point-in-time you select, and then use the logs to roll the new instance's data forward in time to the target time. When the process is complete, your new instance will contain exactly the data that was present on the old instance at the point in time that you selected.
lets assume I have one table contain 10 records at midnight. which is exists in backup/snapshot.
Stop thinking about what is in the snapshot. It doesn't matter.
Next day morning I have added 5 another records at 10:00pm. After half an hour (at 10:30) I have deleted 2 records from them antecedently.
Perform a point in time recovery, selecting any point between 10:00 and 10:30 -- a point in time when the records were in your database.
Point in time recovery creates a new instance, which contains all your data exactly as it existed at the time you selected. Connect to that new instance manually, fetch the missing rows, insert them back into your live/main/production database, and then the newly-created instance can be destroyed because it is no longer needed.
Do not assume this process is complicated or difficult.
I have accidently deleted some records from the production database in the morning. I do not have backup. i tried this link
[http://raresql.com/2011/10/22/how-to-recover-deleted-data-from-sql-sever/][1]
and i got the records in local i got the records.
But, issue arised when i tried this in the afternoon.
Is it like the transaction log file shows only recent activity records?
If so, what could be the possible time interval?
And what if i have to recover older records?
Please, guide me.
Thanks.
The transaction log is a cyclic log. You can google the working of sql server transaction log.
But getting straight to the answer, the transaction log gets overwritten when a checkpoint occurs,so the old records are overwritten.
You can take the transaction log backups by putting the database in full recovery mode but remember to take the transaction log backups as the logs will grow in size till you take a log backup which will result in hard disk space issue and also the data going into suspect mode in a worst case scenario.
Assume a number of conventional LAMP-style applications which use MySQL as a back-end to record the 'current durable state' for the applications.
I am interested in establishing an 'audit' of transitions at the database level - and storing them as a log. The idea is that - assuming the MySQL database has been 'dumped' at the beginning of the day, it would be possible to 'replay' transactions against the back-up to recover any state during the working day.... A bit like time-machine for MySQL - I guess.
I have found some documentation about "Audit plugins" which look relevant but leaves me with more questions than answers.
http://dev.mysql.com/doc/refman/5.6/en/writing-audit-plugins.html
Essentially, I'd like to establish if it would be feasible to write a MySQL plugin to achieve my goal - such that it would work 'seamlessly' with existing MySQL applications?
The principal detail I'm finding it difficult to ascertain is this: When the audit-plugin is notified of an event, what is the mechanism by which the new data can be established in order to log it? How are data types encoded? How hard would it be to write a tool to 'replay' this audit against a 'full-system-backup' using mysqldump, for example?
Are there any existing examples of such plugins?
You just want MySQL's Point-in-Time (Incremental) Recovery Using the Binary Log:
Point-in-time recovery refers to recovery of data changes made since a given point in time. Typically, this type of recovery is performed after restoring a full backup that brings the server to its state as of the time the backup was made. (The full backup can be made in several ways, such as those listed in Section 7.2, “Database Backup Methods”.) Point-in-time recovery then brings the server up to date incrementally from the time of the full backup to a more recent time
Let's say your taking daily snapshots of your server as a whole (public_html, sql files, etc) for later restoration in case of system failure.
Is it possible that you can restore damaged a MySQL InnoDB if you took the snapshot while an uncommitted transaction was taking place? Or will InnoDB do just fine and discard "incomplete" transactions on restoration?
From the databases viewpoint we are dealing with an unclean shutdown (i.e. power went off) and a lost connection so it will discard all transactions that are not committed.
If you are taking a snapshot of the server that's just like freezing everything in a cryogenic sleep, then after a restore the database would just awake expecting to talk to a non existing application.
The only issue that i can see is not from a transaction itself but from the fact that the database itself resides inside files. What if you freeze a file half-written to disk. I can see how that might be a problem. On the other hand there's probably some architectural design in place to prevent this as the same is true for a power outage and a database should live through that too.
To best of my knowledge, during a transaction, nothing gets saved into the database until commit has occurred. That's the ACID compliance right there. So no database files get written during a transaction, only after.
Also, in my opinion, database 'snapshots' should be done via dump. I'm not a server administrator so I wouldn't know for a fact, but it'd be a lot safer to restore the data that way.
Although, MySQL is a gray area to me, I'm more confident with SQL Server, so don't take this as a fact, as SQL Server has its own ways of getting backups made.
Without not reason, I lose all my data in my database. Fortunately this was just test data, but this made me to think what will happen if this was done with a production db.
Ultimately, every developer got a db problem and want to rollback the db. We don't do things to protect the db, as we think its a DBA work, but then we got into trouble...
What are your backup best practices?
Since all the developers are also the DBAs where I work, we're collectively responsible for our backup strategy as well - if you care about the data, make sure you're at least informed about how the backups work, even if you're not part of the actual decisions.
The VERY first thing I do (before I even have any databases set up) is set up nightly maintenance plans that include a full backup, and direct those backups to a central network share on a different computer (our NAS). At the very least, for the love of your job, don't put the backups on the same physical storage that your database files sit on. What good are backups if you lose them at the same time you lose the disk?
We don't do point-in-time restores, so we don't do log backups (all our databases are set to Simple recovery mode), but if you want logs backed up, make sure you include those as well, as an acceptable interval as well.
On a side note, SQL 2008 supports compressed backups, which speeds up backup time considerably and makes the files much, much smaller - I can't think of an instance where you wouldn't want to use this option. I'd love to hear one, though, and I'm willing to reconsider!
Here are some points from my own experience:
Store your backups and SQL Server database files on the different physical storages. Otherwise, if your physical storage failed you will lose both backups and database files.
Create your own SQL Server database backup schedule.
Test your SQL Server backup. If you never tested your backups I have a doubt that you will be able to restore your database if the failure occurs. Time to time you need to have the practice to restore your backup on a test server.
Test your recovery strategy - here is another tip. If the failure occurs how much time do you need to restore your database to the working state?
Backup SQL Server's system databases.
And this isn't a whole list, you can find more tips in my article https://sqlbak.com/blog/backup-and-recovery-best-practices/
Choosing the right backup strategy is one of the most important factors a DBA should consider at the point of developing the DB.
However the backup strategy you choose depends on a number of factors:
How frequent is transaction carried out on the DB: are there thousands of transactions going on every minute or maybe few transactions per day? For very busy database, i would say, take full nightly backups and transaction log backups every 10 mins or even less.
How critical the data content is: may it be employee payroll data? Then you'll have no acceptable excuse or you may have a few angry faces around your car when you want to drive home! For very critical database, take nightly backups possibly in two locations and transaction log backups every 5 mins. (Also think of implementing mirroring).
Location of your backup location: if your backup location is close to the DB location, then you can afford to take more frequent backup than when it is located several hops away with not excellent bandwidth between.
But in all, i would say, schedule a nighly backup every night, and then transaction log backups at intervals.