I did a blunder in my client database. I have dropped all tables and created new tables with same name in client database. I lost all client data. I don’t have any backup of client DB. Can you please let me know if I can recover data of old tables.
Few options .All untested and i am not sure,how consistent the database will be
1.RedGate Provides a tool called SQL Log Rescue..It claims to do View and recover deleted and modified data
2.Volume Shadow Copy service
some reference of what this means :(emphasis mine)
This service allows Windows to take automatic or manual backups, or snapshots, of the current state of the files on a particular volume (drive letter). The important part of this process is that these backups can be taken of files even if they are open. Therefore, this provides a mechanism that backup programs and Windows can use to retain a reliable history of a computer's files
Below is a step by step tutorial on how to do this
https://www.bleepingcomputer.com/tutorials/how-to-recover-files-and-folders-using-shadow-volume-copies/
Related
Background:
I have a medium-sized database (900GB) that needs to be copied onto another server (driven via code, not scheduled). Currently we take a backup (to .bak), move it to a staging server, and restore it to the target server. The target server does not have enough space to hold the backup file, and the restored instance simultaneously, thus the staging server. These transfers (backup to staging, restore from staging) happen over SMB2. The staging server needs to go away due to business requirements, however. It is worth mentioning the target server will be taken offline (and used offline) after the transfer, so I'm not sure the mirroring or replication options are valid.
I have identified two options -- one is to backup the database to the primary server, and open up firewall rules/smb to serve the backup file to the target server over SMB. ("RESTORE FROM \x.x.x.x\blah\db.bak"). Security isn't a fan, though.
The ideal solution (and one that could easily be implemented in every other database I've worked with), is to quiesce the database and transfer the datafiles (in the case of ms-sql, mdf and ldf files). However, upon research I see there is no such functionality available out of the box. I know I can take the database offline to copy the mdf/ldf safely, but that's not an acceptable solution (database must remain online).
I have read LOTS of posts and Microsoft documentation regarding VSS / shadow copy, but I have also read lots of conflicting information about the reliability of using VSS/sqlwriter to copy the mdf/ldf file to the target server, and simply re-attaching the database.
I am looking for documentation or advice (or even backup software that can be programmatically driven via an API) to accomplish this goal of transferring the database without requiring a secondary holding place. Currently I'm researching how to drive this copying process with Powershell, using VSS(vssadmin/vshadow from sdk), but I'm not confident in what I'm reading, and it's not even clear to me if VSS/sqlwriter is a supportable method to copying online LDF/MDF files. Any advice is appreciated.
Thanks,
TL;DR: My POS uses Sybase Advantage Database Server to store my sales data, and I'd like to access it, but I only have the backup files.
I own a small business with "advanced" POS software, which has the only copy of all my sales data ever. They have some backup scheme, but they're unwilling to divulge any details. There's also an automatic daily local backup routine, but because this is a POS and there are certain laws about deleting data, I am not allowed (nor do I have the software required) to restore from backup even to check that it works. I asked the support guy when the last time he had to restore from backup was, and he said "don't worry, we don't ever need it".
Naturally, I'm worried.
I'll note at this point that I am required by law to keep this data, and should I fail to do so for any reason I may personally face massive fines in the range of multiple millions. I'd like to avoid that.
Additionally to keeping the data, and verifying that the backups contain the data I so need to keep, I'd also like to create reports. The POS vendor claims that it can create any report I'd ever need, but every single time I've asked them about a report it either contained wrong data, crashed, exported unreadable files (to which their reply was that the files are fine, my [insert relevant file reader] is broken), or simply didn't exist (to which their reply is usually something like "you don't need that report anyway"). I asked about accessing a copy of the database myself, and they said they can't allow that. My only recourse is to pay them tens of thousands for developing and testing the report. What report do I want, you ask?
SELECT * FROM SALES
To create this simple report, I need to migrate my data from the Sybase Advantage Database Server backup files into a format I can use, e.g. a MySQL database, but all the migration tools I've found require access to a working database server.
How can I get my data out of these backups?
It's actually a complete Sybase iAnywhere database (which uses .db for the data and .log for the transaction log).
So you should be looking for Sybase iAnywhere or Sybase SQLAnywhere drivers and tools.
SAP / Sybase has a developer website here: http://scn.sap.com/community/sql-anywhere
We are working on generating a database that will be distributed to several third parties. We will also re-generate this database on an on-going basis, redistribute it, and those third parties will need to overwrite their existing database copy with the new version.
I'm trying to decide whether I want to detach the database temporarily, make a copy of the .mdf, and send that copy out, or whether I should just do a full backup of the database, and send the .bak out.
The primary difference I can see is that to distribute the .mdf, you must detach the database temporarily, so that you can copy it.
What are the other pros/cons of each format?
Are there security implications with distributing one over the other?
Is it easier to initially import one format over the other?
Thank you.
Neither. The proper way to distribute database changes is via upgrade scripts, otherwise those third parties using the database will loose the actual data contained in the database.
For the case when the data is never changed by the third parties (ie. the database is read only at those sites) then distribution by backup file is feasible. MDF is completely out of the question, first and foremost because MDF is not the entire database: at least the LDF is required in addition to recreate a coherent database. Simply attaching the MDF w/o a corresponding LDF will result in most cases, in a corrupt database. In addition to being incorrect, MDF distribution is inefficient (BAK files are smaller than the corresponding MDF because they do not contain unallocated pages) and also MDF manipulation requires placing the database offline during the file copy.
We host on our servers a vendor application's SQL Server database that we'd like to copy/mirror/replicate to a reporting location on a regular basis. Full restores of nightly backups aren't working, full backups are too large to transfer over the network and restore in a timely manner.
I am aware of Replication and Log Shipping, but it appears that those options require the "source" database to do the work and be configured in some way to allow for this to happen. We'd like to make as few changes as possible to our production database since it is "controlled" by a 3rd-party vendor's application and any changes we make causes support issues for them (understandably so).
So .. this must be a common scenario but searching yielded no results. Is there a clean, simple way to mirror a very large, active SQL Server 2005 database to a reporting location incrementally on a regular basis (say, nightly) while making no (or minimal) changes to the source database?
I have done this in the past with Log Shipping. The only thing you need to do to the source database to enable this is to set the recovery model to "Full", and then configure it with a schedule of Complete and Transaction Log backups. A more detailed outline:
Configure the source database with recovery model set to Full.
Create the "first" complete backup
Create the target database by restoring the complete backup, leaving it in Standby* mode
Set up a schedule of transaction log backups. Frequency totally depends upon your circumstances, but by and large you don't want the t-log backup files to be too big.
Configure log shipping between the two database
*Standby Mode allows read-only access to the database. Note that you cannot apply subsequent restores to a standby database if there are any connections open to it.
Timing is the hard part here. Presumably you want to update the database once per day at, say, Midnight YST (that's "Your Standard Time"), which means that:
- At that time, ensure that there are no open connections to the target database (i.e. kill any you find, and make sure your users know you'll be doing that!)
- Apply the day's accumulated restores at that time
I did this a few years back, and I don't think these precise requirements were supported by the built-in log shipping utilities (that, or they were overly complex). Whatever, it wasn't all that hard to "roll your own"; simply keep track of the last t-log applied, write a "Shoot Zem All" connection-killing routine, and pull and apply any subsequent ones found in the backup folder.
I have one database which contains the most recent data, and I want to replicate the database content into some other servers. Due to non-technical reasons, I can not directly use replicate function or sync function to sync to other SQL Server instances.
Now, I have two solutions, and I want to learn the pros and cons for each solution. Thanks!
Solution 1: detach the source database which contains the most recent data, then copy to the destination servers which need the most recent data, and attach database at the destination servers;
Solution 2: make a full backup of source server for the whole database, then copy data to destination servers and take a full recovery at the destination server side.
thanks in advance,
George
The Detach / Attach option is often quicker than performing a backup as it doesn't have to create a new file. Therefore, the time from Server A to Server B is almost purely the file copy time.
The Backup / Restore option allows you to perform a full backup, restore that, then perform a differential backup which means your down time can be reduced between the two.
If it's data replication you're after, does that mean you want the database functional in both locations? In that case, you probably want the backup / restore option as that will leave the current database fully functional.
EDIT: Just to clarify a few points. By downtime I mean that if you're migrating a database from one server to another, you generally will be stopping people using it whilst it's in transit. Therefore, from the "stop" point on Server A up to the "start" point on Server B this could be considered downtime. Otherwise, any actions performed on the database on server A during transit will not be replicated onto server B.
In regards to the "create a new file". If you detach a database you can copy the MDF file immediately. It's already there ready to be copied. However, if you perform a backup, you have to wait for the .BAK file to be created and then move it to it's new location for a restore. Again this all comes down to is this a snapshot copy or a migration.
Backing up and restoring makes much more sense, even if you might eek out a few extra minutes from a detach attach option instead. You have to take the original database offline (disconnect everyone) prior to a detach, and then the db is unavailable until you reattach. You also have to keep track of all of the files, whereas with a backup all of the files are grouped. And with the most recent versions of SQL Server the backups are compressed.
And just to correct something: DB backups and differential backups do not truncate the log, and do not break the log chain.
In addition, the COPY_ONLY functionality only matters for the differential base, not for the LOG. All log backups can be applied in sequence from any backup assuming there was no break in the log chain. There is a slight difference with the archive point, but I can't see where that matters.
Solution 2 would be my choice... Primarily becuase it won't create any downtime on the source database. The only disadvatage i can see is that depending on the database recovery model, the transaction log will be truncated meaning if you wanted to restore any data from the transaction log you'd be stuffed, you'd have to use your backup file.
EDIT: Found a nice link; http://sql-server-performance.com/Community/forums/p/5838/35573.aspx