Db2

Db2

Connect with Db2, open source, and other data experts to gain value from your data, share insights, and solve problems.

 View Only

  • 1.  Restoring VERY old Db2 Backups

    Posted 14 days ago

    I am hoping someone has dealt with this topic and has an easy answer.

    We are required to keep our Db2 backups for 35 years. (Not sure why, but sometimes, the government just has rules, let's just leave it at that).  So, I have never thought about it, but I was recently asked the question, "10 years from now, if we get a request to restore a backup taken today, would we be able to?".

    Well, I had a couple of thoughts that came to me that would inhibit the ability to restore, but the one I am wondering if any of you have dealt with is about Db2 Versions and restoring a database.  I have restored a v11.1 database to a v11.5 installation, and it does work.  But how far back could I expect to be compatible?  Could I restore a v9 or v10 database to v11.5 or even to v12?  How far back can a Db2Upgrade work?

    Any thought on this would be very helpful.  Thanks in advance.



    ------------------------------
    Edward Spencer
    ------------------------------


  • 2.  RE: Restoring VERY old Db2 Backups

    Posted 14 days ago

    Here are some of the migration strategies:

    1. V9.7 -> V10.5  (Backup/Restore);
    2. V10.5 -> V11.5 (backup/restore)

    or:

    1. Unload data from V9.7 (export or db2move);
    2. Run db2look to create script to re-create all db2 objects;
    3. run a/m script in V11.5 to create database and all objects;

    4. reload all data (import or LOAD).

      Try looking at Db2  load from cursor , by connecting cursor remotely.  Remember to reset any sequence, identity columns , etc. ... etc

      Actually -  most of the time (unless migrating from V11.x to V11.y (x <y)) - I would recommend rebuilding database(s) - one can catch some old artifacts no longer needed and review authorization/privileges to conform to current company security requirements ...


    ------------------------------
    Jan Nelken
    Db2 (LUW) DBA
    Open for work
    Katowice or Krakow
    +48 783 109 863
    ------------------------------

    Original Message


  • 3.  RE: Restoring VERY old Db2 Backups

    Posted 14 days ago

    I do hope those are offline backups for LUW, as you can't use online backups to restore to later versions. You also can't roll-forward logs through Db2 versions, as I'm sure you know.

    You also have fixpacks and changes between versions that may affect your ability to restore - 10.5 log and lsn changes come to mind.

    Anything older than 11.1 has to be restored/upgraded to Db2 10.5 Fix Pack 7 or later first, then upgraded to the later version.  (11.5 and 12.1 say the same thing) https://www.ibm.com/docs/en/db2/11.1.0?topic=servers-recovering-through-db2-server-upgrade

    I had to ponder this issue a few years back for a financial institute.  My thoughts then were that you would need to archive the matching Db2 installation media alongside those backups, or you may well struggle with the restores. Also whatever build info applied to the servers and/or database installations.  Other problems then arise in that you need a compatible OS for the Db2 installation, compatible hardware etc.  You may be able to get around that with VM images, but it will be messy.  If it is just the data that needs to be retained for 35 years, then export to CSV, compress and store with the DDL for the tables. Db2 backups from older versions are going to be tedious if you need to retrieve them 10+ years from now. Not to mention all the security holes from using old versions.

    Short answer - 10 years, maybe, but with effort.  More than that you may very well need your friendly neighbourhood IBM support to help out with installation images etc.

    Cheers



    ------------------------------
    Greg Palgrave
    ------------------------------

    Original Message


  • 4.  RE: Restoring VERY old Db2 Backups

    Posted 14 days ago
    Hi Edward,

    platform please?

    There are OBIDs and PSIDs of relevance here. The best option is to have the original DB2 Catalogs backed up to go with your backups. On z/OS we can restore to newly defined objects with some translation. Other platforms offer other things, and a set of container images with the right releases come to mind.

    best regards,



    Original Message


  • 5.  RE: Restoring VERY old Db2 Backups

    Posted 14 days ago

    For the reason stated in the replied responses your best option if you must retain this data that long would be to Unload the data for each table into file along with a  2nd file of DDL (DB2Look to copy the DDL).  When I have done this I copy the whole database DDL then issue IXF exports on the tables.   These export are not fast depending on the size of the object and could cause some contention issues.    

    As stated (Due to releases, online vs offline, fixpacks, OS migrations, Changes/Depreciation to the SQL ) the backup can't be uses and are worthless at this point.  If for some reason if you would need to recover the old information you would need the software/fixpack for LUW not to mention the Computer environment to install the software on as the software may not be able to be installed on modern day hardware.



    ------------------------------
    Douglas Partch
    CEO
    Database Nerds
    Omaha NE
    ------------------------------

    Original Message


  • 6.  RE: Restoring VERY old Db2 Backups

    Posted 13 days ago

    Hi Edward,

    all of it is said already. Export the data with DDL and hopefully with a text description of the data model. All binary stuff won't survive that long. Actually a former customer of mine (gov too) is doing this in that way.

    35 years ago for Db2 LUW this would be OS/2 with extended edition. DB2 for Windows wasn't out then. A friend of mine was successful to get OS/2 running in a VMware container, but sometimes such software might not run on nowadays hardware anymore.

    The data from the first landing on the moon is still available, but almost unreadable as the data fields and hardware is not available anymore.

    So export to ASCII (or UTF-8!) is the way to go.

    Cheers



    ------------------------------
    Roland Schock
    IBM Champion and IBM Gold Consultant
    ------------------------------

    Original Message


  • 7.  RE: Restoring VERY old Db2 Backups

    Posted 6 days ago
    Edited by Jan Nelken 6 days ago

    Roland, this is trivial - in few hours you can have production database SAMPLE operational :-) 



    ------------------------------
    Jan Nelken
    Db2 (LUW) DBA
    Open for work
    Katowice or Krakow
    +48 783 109 863
    ------------------------------

    Original Message


  • 8.  RE: Restoring VERY old Db2 Backups

    Posted 5 days ago

    Oh my word! That brings back so many memories! I loved OS/2. I chose that over Windows 3.1 for my first PC!

     

    Regards,

    Marcus Davage CEng CITP MBCS

    Lead Product Developer
    Intelligent Z Optimization and Transformation
    BMC Software Ltd

     My Digital Pin IBM Champion 2025 badge image. Experience. Advanced level. Issued by IBM

     




    Original Message


  • 9.  RE: Restoring VERY old Db2 Backups

    Posted 6 days ago

    Db2 follows "n-2" policy i.e. it can restore 2 versions below to current version e.g. 10.5 -> 11.5 (but only OFFLINE allowed for this), for 11.1 -> 11.5 (both offline and online). However, platform has to be the same. If your requirement is 35 years and cross-platform then as others have suggested "db2look -e -l -> unload or export in IXF format" is the way to go and keep the data around. 

    Hope this helps.

    Thanks,

    Rajib Sarkar



    ------------------------------
    Rajib Sarkar
    ------------------------------

    Original Message


  • 10.  RE: Restoring VERY old Db2 Backups

    Posted 5 days ago

    Others in the thread have given good advice on the specifics of Db2 data migration, but please do put some thought into the entire software and hardware stack required to access 35-year-old data. For example:

    • Are you able read from the media are the backups stored on? E.g. if your backups are on magnetic tape, do you have a compatible tape drive?
    • Do you have access to the Db2 versions in your restore chain and the operating systems that those Db2 versions run on and the hardware that those operating systems run on? Old operating systems are typically full of security holes, so do you have an air-gapped machine room where those systems are not connected to the internet?
    • Relatedly, does a restore chain from your source platform to a modern Db2 platform even exist? (If you're on Solaris or HPUX you have some work ahead of you... if you're on SCO Unix you are pretty much doomed.)

    There are two main strategies for approaching these questions.

    1. Maintain your own museum of retro hardware. If you need to run queries against a year 2000 version of Db2 data and you have a 2000-vintage platform to run on, the chore is straightforward. (Although maintaining the hardware/software stack is not straightforward -- see above.) This is basically the approach that Jan Nelken shows for accessing DB2/2 v1.0 data.
    2. Migrate the data from the old platform to a new platform. Depending on circumstances, this could be several individual migrations, and depending on the specifics of your migration (32->64 bit, Solaris->AIX, ESE vs DPF, etc) this could be straightforward or difficult. It is a business decision on your part whether you want to actively migrate your historical data so it is always available on an up-to-date Db2 platform or whether to do it only on demand.

    You have to consider the risk and expense of (1) babysitting ancient hardware, (2) doing a yearly migration/test cycle, (3) running into migration problems while the auditor is standing there tapping his or her foot. But whatever you decide to do, TEST IT TO MAKE SURE IT WORKS. (This is standard advice for any recovery policy but is especially important if you want to avoid having the government mad at you.)



    ------------------------------
    David Mooney
    ------------------------------

    Original Message


Related Content