Can HANA incremental backups be scripted?
As per SAP note ‘1642148 - FAQ: SAP HANA Database Backup & Recovery’:
“Are incremental and differential backups available?
Yes. Starting with HANA SPS 10 incremental and differential data backups are available.
It's also possible to combine both kinds of backups in one backup strategy, e.g. an incremental backup can be created based on a complete data backup, a differential or an incremental data backup.”
SAP note ‘1651055 - Scheduling SAP HANA Database Backups in Linux’ leads me to believe that hdbsql (like the following) could be used in a script:
hdbsql -U user_store_key "backup data INCREMENTAL using backint('backup_prefix')"
But, I am not 100% sure that incremental backups can be scripted.
Any help is very much appreciated.
Many thanks,
Fionn
generally speaking, yes, incremental backups can be scripted just as the other backup options can.
Concerning the mentioned SAP note, well, it is written in the note, the documentation PDF and in the script as well: there is no support nor further development happening with this example script.
So, if a HANA user wants to take the script as a sort of template and create its own script that can do incremental backups, that's definitively possible.
In fact, I'd recommend explaining to that user, that the challenge with INCREMENTAL backups is not so much creating them, but maintaining the backups that have already been made. How long should which backup set be retained? Which backup paths have to be supported/guaranteed? When it comes to housekeeping, increm. backups are much more similar to log backups than to full data backups.
Anyhow, to come back to your original question: yes, that's possible.
Cheers,
Lars
Related
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.
Here is the use-case: we need to backup some of the tables from a client server, copy it to our servers, restore it, then running some queries using ODBC.
I managed to do this process for the entire database by using probkup for backup, prorest for restore and proserve to make it accessible for SQL queries.
However, some of the databases are big (> 8GB), so we are looking for a solution to do the backup for only the tables we need. I didn't find anything with the documentation of probkup how this can be done.
Progress only supports full database backups.
To get the effect that you are looking for you could dump (export) the tables that you want and then load them into an empty database.
"proutil dump" and "proutil load" are where you want to start digging.
The details will vary depending on exactly what you want to do and what resources and capabilities you have available to you.
Another option would be to replicate the tables in question to a partial database. Progress has a product called "pro2" that can help with that. It is usually pointed at SQL targets but you could also point it at a Progress database.
Or, if you have programming skills, you could put together a solution using replication triggers (under the covers that's what pro2 does...)
probkup and prorest are block-level programs and can't do a backup or restore by table.
To do what you're asking for, you'll need to do a dump the data from the source db's tables and then load it into the target db.
If your object is simply to maintain a copy of the DB, you might also try incremental backups. Depending upon your situation, that might speed things up a bit.
Other options include various forms of DB replication, which allow you to keep real- or near-real-time copies of your database.
OpenEdge Replication. With the correct license, you can do query-only access on the replication target, which is good for reporting and analysis.
Third-party replication products. These can be more flexible in terms of both target DBs and limiting the tables to be replicated.
Home-grown replication (by copying and applying AI files). This is not terribly complicated, but you have to factor the cost of doing the work and maintaining the system. There are some scripts out there that can get you started.
Or, as Tom said, you can get clever with replication via triggers.
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 was wondering whats the best way to backup MySQL (v5.1.x) data -
creating mysql data dir archive
use mysqldump
What are the pro/cons for the above? I am guessing mysqldump has some performance impact on a live database. How much impact are we talking about?
We plan to take a backup every few hours, lets say 4 hrs. Whats the best practice around MySQL backups or database backups in general.
I think that the best way is using mysqldump.
Normally I create a cron task to run in a time of little traffic, it generate a dump naming with a timestamp_databasename_enviroment.sql, so it verify if there are old backups and compact it.
I think that is a good form to do database backups.
If your data size is huge then its better to use
MySQL enterprise backup tools.it takes online backup and it will not impact live services.
xtraback is also like MySQL enterprise backup from percona .
One user has said to me
Applying incremental db backups is
tedious, and a royal pain if you miss
a step. I wouldn't bother with the
approach on SQL Server or MySQL -
that's what transaction logs are for,
so you don't need to incorporate it
into your data model
So if i have transactions on mysql or sql server i can have a script to backup any data modified after or between date X and Y? I ask because i am currently designing tables so i can do an increment dump instead of a full.
Yes, you could backup the transaction logs rather than incorporate logic into your data model, providing the database supports it. Your previous question said that you were developing on SQLite...
Speaking from a SQL Server background, it can use transaction logs for both restoration and replication of a database. An ideal setup would have three RAID drives setup - a mirror for the OS, RAID 5 (or better) for the data, and RAID 5 (or better) for the transaction logs. The key part is the transaction logs being on their own RAID setup for optimal performance (not competing with read/write for data) and failover (because RAID is not a backup). For more info - see link.
MySQL transaction logs turns up info on the MySQL Binary Log, which also references replication so I figure there's a fair amount of carryover in approach.
On SQL Server: The key factor is the SLA time of recovery. A full a disaster recovery starts from the latest full backup, applies the latest differential backup, the applies all the log backups after the latest differential backup. If you're missing differential backups from your recovery plan, then you must start from the full backup and then apply all log backups.
The differential backup thus reduces the recovery time by eliminating the need to apply all log backups taken between the last full backup and the last differential backup.
If your database is small, differential backups don't add much advantage because the recovery time is small to start with. But on large databases it makes a difference, as the log backups can be quite large and going through days of log adds up to the recovery time. Adding differential backups can cup back the recovery time by few hours.
I'm not sure I follow your argument about designing tables with differential backup in mind, the two subjects are orthogonal.