As I'm about to implement it myself, I'm curious to know how people handle
incremental backups for their DB's.
The straight-forward way, as I see it, is to shutdown couch and use a tool
like rsync or duplicity to backup db files. It should do the job well, and
as an added bonus, it could also be used to backup views.
Does anyone know if a similar backup could be done while the couch is still
on (and the db is being updated)?
Does anyone do incremental backups in couchdb2.0?
For incremental backup, you can query the changes feed of a database using the "since" parameter, passing the latest revision from your last backup and then copy only the changes into a new database on the same or different server. AFAIK, there is no "since" parameter for replication, so you will need to roll your own framework for this.
Related
Is there any way to retrieve older version of changed view on pl/sql oracle developer?
I really dont know where to start atm. Its not materialiazed view
A view is just a stored query. If you replaced it with a new version, the old one is lost.
A few options:
check your version control system
restore it from backup
either of filesystem files or
database backup, be it RMAN or even .dmp file (as result of data pump export)
if you dropped it, see whether you can get it by flashback query on DBA_VIEWS
is it in Recycle bin?
If nothing of this help, huh, you're probably out of luck.
The database doesn't keep a history of object definitions.
However, any good development process will involve a change control and versioning system. Hopefully your database objects are being tracked as files in a Git repo somewhere.
If not, your DBA could probably get the previous version of your VIEW from a backup, or by mining the redo/archive logs.
I am trying to move my DB to Azure Managed Instance.
I would like to know what should I do about this.
I have the options of DB migration and DB restore to Azure managed instance.
Please let me know the difference between these 2 methods.
Normally you first do a full Backup and then migrate the Database.
If something go wrong then you Restore the Database.
But I don't know exactly how Azure M.I. works..
For database restore option; you can take a backup of your database and then you can restore that backup on the cloud if your application(s) or service(s) handle a moderate downtime or maybe you does not care about downtime. After the restoration you just need to redirect your database connections of your application(s) or service(s).
For the database migration; it is a little bit more complex. Generally, this option has been using for database systems which we do not want to take downtime on it. Also, for this option you will always need a database restoration(or initial load). After the restoration or inital load you just need your cloud database copy up to date. So, for this purpose the database logs which is generated on the source database systems are being applied on target database systems until you decide to switch cloud database systems.
PS: Of course, data volume is another critical aspects of database migration to the cloud.
I have a client who has been promised that he will get a regular copy of the database behind the application we are hosting for him.
The copy is in fact a backup (DB_EXPORT.BAK) that he downloads through SFTP.
(I know, I did not make that promise). I do not want to give him the whole with all the proprietary stored procedures, functions, users and other stuff. I want to give him a slimmed down version of that database with most tables, only selected sp's, some functions, no users and so on.
As I see there are two ways to do this:
a SSIS job that copies certain stuff (using Import/Export Wizard)
replication (snapshot or transactional)
The thing is: the original (DB1) AND the copy (DB_EXPORT) will be hosted on the same server. So using replication feels a bit awkward (publishing to yourself?) but it does give an easy interface for configuring which articles to replicate. Using a SSIS package feels more logical but is actually hard to change.
What can you say about this? Is there a better way for doing this? I am looking for a way that will allow people who just about understand SQL server wil be able to understand.
Thanks for thinking with me!
Not sure if this is the best answer, but I would go with snapshot replication per our discussion, and your avoidance of TSQL scripting.
Replication is relatively simple to setup, but can be a nightmare to troubleshoot (esp. transactional). Often times, its easier to completely delete the publication/subscription and rebuild.
On that note, you can fully script replication configurations -- if someone else has to maintain this, it may be as simple as you scripting out the replication removal (pub and sub removal), and scripting out the replication build-out. All they'd have to do is run the drop/build scripts and it's done.
You can also alter the scheduled job to run the backup immediately following the snapshot generation.
I'm using SQL Server 2012 in a local environment. In fact, it is running on my Windows 7 machine. My problem is as follows: I receive a daily backup of my SQL database. Right now, I'm just restoring the whole database on a daily basis by deleting the existing one. This restore task takes quite some time to complete. My understanding of the restore process is that it overwrites the previous database with the new backup.
Is there a way for SQL Server 2012 to just modify the existing database with any changes that have occured in the new backup? I mean, something like comparing the previous database with the updated one and making the necessary changes where needed.
Yes, instead of a full backup you ill need a differential backup. Restore it to move to a "point in time" state of original database.
Make a basic research about full/differential and log backups (too many info for a short answer)
I don't believe so. You can do things with database replication, but that's probably not appropriate.
If you did have something to just pull out changes it might not be faster than a restore anyway. Are you a C# or similar dev? If so, I'd be tempted to write a service which monitored the location of the backup and start the restore programatically when it arrives; might save some time.
If your question is "Can I merge changes from an external DB to my current DB without having to restore the whole DB?" then the answer is "Yes, but not easily." You can set up log shipping, but that's fairly complicated to do automatically. It's also fairly complicated to do manually, but for different reasons: there's no "Microsoft" way to do it. You have to figure out manual log shipping largely on your own.
You could consider copying the tables manually via a Linked Server. If you're only updating a small number of tables this might work just fine, and you could save yourself some trouble. A linked server on your workstation, a few MERGE statements saved to a .sql file, and you could update the important tabled in the DB as you need to.
You can avoid having to run the full backup on the remote server by using differential backups, but it's not particularly pleasant.
My assumption is that currently you're getting a full backup created with the COPY_ONLY option. This allows you to create an out-of-band backup copy that doesn't interfere with existing backups.
To do what you actually want, you'd have to do this: on the server you set up backup to do a full backup on day 1, and then do differential backups on days 2-X. Now, on your local system, you retain the full backup of the DB you created on day 1. You then have all differential backups since day 1. You restore the day 1 full DB, and then restore each subsequent differential in the correct order.
However, differential backups require the backup chain to be intact. You can't use COPY_ONLY with a differential backup. That means if you're also using backup to actually backup the database, you're going to either use these same backups for your data backups, or you'll need to have your data backups using COPY_ONLY, both of which seem philosophically wrong. Your dev database copies shouldn't be driving your prod backup procedures.
So, you can do it, but:
You still have to do a full DB restore.
You have considerably more work to do to restore the DB.
You might break your existing backup procedures of the original DB.
I'm looking for a simple (simplest if possible) way of backing up and restoring a database.
I want to do a backup in one state and then after doing some operations get back to the backed up state.
Tried Database->Tasks->Back Up... and then Database->Tasks->Restore but I always get an error with:
Restore failed for...DBName
The tail of the log for the database "database name" has not been backed up...
So, I want to back up and restore with one simple operation each, can one advise me
to a solution, be it GUI or not GUI based?
Use the WITH REPLACE option of the RESTORE command:
The REPLACE option overrides several
important safety checks that restore
normally performs. The overridden
checks are as follows:
Restoring over an existing database with a backup taken of another
database. With the REPLACE option,
restore allows you to overwrite an
existing database with whatever
database is in the backup set, even if
the specified database name differs
from the database name recorded in the
backup set. This can result in
accidentally overwriting a database by
a different database.
Restoring over a database using the full or bulk-logged recovery model
where a tail-log backup has not been
taken and the STOPAT option is not
used. With the REPLACE option, you
can lose committed work, because the
log written most recently has not been
backed up.
Overwriting existing files. For example, a mistake could allow
overwriting files of the wrong type,
such as .xls files, or that are being
used by another database that is not
online. Arbitrary data loss is
possible if existing files are
overwritten, although the restored
database is complete.
The topic is also covered at nauseam in MSDN see Restoring Without Using a Tail-Log Backup, which contains the links for 'How to' articles that cover Management Studio scenarios (ie. the tool you're using).
It looks like you have Differential Backups set up. It is slightly more complicated than restoring a Full backup.
http://msdn.microsoft.com/en-us/library/ms175510.aspx
By doing a Full backup, you are going to break the chain of backups that the DBA set up, so it would be a good idea to check first with the DBA before you break his backup set.
Edited for very helpful comments:
You should use the COPY_ONLY option when you do a backup so that you do not break the chain of backups.
http://msdn.microsoft.com/en-us/library/ms186865.aspx
When restoring you need to check the option to Overwrite existing database, if you are, otherwise it will fail.
MSSQL 2005 and up features snapshots, sounds like it suits your requirements nicely.