DB2 restore incremental backup tablespace to different db - db2

I have server1 and server2 in my environment, both have db2 v11.1 installed.
I have already done an online tablespaces (TS1, TS2, TS3) incremental backup of my database GS_DB and obtained the below 3 images.
Image1 at timestamp1: 20190215162151 (full online backup of TS1,TS2,TS3)
Image2 at timestamp2: 20190215162254 (incremental online backup of TS1,TS2,TS3)
Image3 at timestamp3: 20190215162725 (incremental online backup of TS1,TS2,TS3)
In server1, suppose I want to restore my db to image2 (20190215162254), I can do:
db2ckrst -d GS_DB -t 20190215162254 -r tablespace
Suggested restore order of images using timestamp 20190215162254 for database gs_db.
====================================================================
restore db gs_db tablespace ( TS1, TS2, TS3 ) incremental taken at 20190215162254
restore db gs_db incremental taken at 20190215162151
restore db gs_db incremental taken at 20190215162254
====================================================================
If I follow the order and restore to the existing GS_DB in server1, it is working fine.
Now I transferred 3 images to server2 and created an empty database GS_DB in server2, then try to use the above command to restore tablespaces TS1,TS2,TS3 to GS_DB in server2:
db2 restore db gs_db2 tablespace ( TS1, TS2, TS3 ) incremental taken at 20190215162254
SQL2560N The table space restore operation failed because the target database is not identical to the source database.
Already stuck at the first command, does it mean we cannot restore tablespace backup image across two different db? Any way I can do it?
Thanks in advance!

Every database has an unique internal identifier called Seed. You can't create another database with the same Seed as the existing one, even you create it with the same name. These databases are different from the DB2's point of view.
Citation from the Restoring to an existing database article:
The database manager assigns the seed when you create the database.
Db2® always uses the seed from the backup image.
You can restore a table space into an existing database only if the table space exists and if the table spaces are the same, meaning that you did not drop
the table space and then re-create it between the backup and the
restore operations.
The database on disk and in the backup image must
be the same.
So, yes, you are not able to restore tablespace backup image across two different db in the way you try.
Read about the Database schema transporting feature.

Related

How to restore postgresql backup file with different name

I have taken a backup of a table in pgadmin by rightclick->backup. Now i want to restore that backup with different name so that existing table isn't get affected.
Note - I can rename the existing table and restore the backup file. But often the db server hangs when i rename the active table in production. So this doesn't work for me.

pg_dump and friends: backup and restore using tablespace

Given a database dump how to specify a tablespace to be used by all tables during restore? The database has multiple tablespaces used by its table. Old tablespaces should be ignored (they are not relevant on new computer) and all tablespaces my by replaced by a new one.
dump with "--no-tablespaces" parameter to have tablespaces-free dump - but you can also use the same parameter on pg_restore if you cannot change dump commands
set global parameter "default_tablespace" on target DB to what is needed for restore (for example by using alter database xxxxx set DEFAULT_TABLESPACE='xxx')
run all pg_restore tasks
if necessary reset default_tablespace to original value

How to recover or recreate orginal Postgres database after dropping it?

I accidentally dropped original postgres database after installing postgreSQL software. Postgres user is still there, \du superuser. How to recover or recreate original postgres database?
https://www.postgresql.org/docs/current/static/sql-createdatabase.html
just run
create database postgres;
it will create db with default template (which is "template1"). If you did not modify it - it will be same is previous "postgres" db
You can only recover it if you have some previous backup of that database, by restoring that backup and then applying WAL files upto the time when drop database statement was issued.
There is no other way to recover a dropped database.

Postgres backup on top of existing database

If I have a backup, I know I can typically do psql dbname < infile
but if I have an existing database and I want to write the backup on top, is there a simple way?
In other words, I have a database that's currently live, and I have a backup. The database crashed and now it only has a few rows, so I want to add my backup rows to the rows currently in the database.

Postgres: Dumping and restoring a live database

I'm having some trouble backing up and restoring a database in pgAdmin.
With pgAdmin, the backup is pretty simple.
If I try to restore the data to my live database, I get all kinds of foreign key errors and duplicate data. So the only way for me now is to drop all constraints, drop all tables and run the restore.
Is there a simpler way to restore a live database? My systems are not directly connected, I'm using file transfer to copy over the backed up db dump.