Rocket U2 | UniVerse & UniData

Expand all | Collapse all

universe backup

  • 1.  universe backup

    Posted 10 days ago
    what is the best strategy to backup universe database?
    we plan to use uvbackup tool. Will this impact performance?

    ------------------------------
    Abdus Thommil
    Tech Architect
    Flextronics International Management Services Ltd
    San Jose CA United States
    ------------------------------


  • 2.  RE: universe backup

    Posted 9 days ago
    Edited by Jon Kristofferson 8 days ago
    Abdus,

    Best practice is to quiesce the database before the backup. The uvbackup utility offers the ability to extract records from a universe file. You may also chose to use other backup utilities and restore files to a separate file area and copy records from the backup copy to the production copy. To quiesce universe you will either need to get the users to logoff the system and stop background process and stop universe. For older systems this may be the only way to backup the system. Universe has a pause/resume functionality that can be used with either *nix snapshots or windows shadow copies to minimize the impact to users. The process would be pause universe, create the snapshot/shadow copy of the universe database directories, resume universe and then mount and backup the snapshot/shadow copies.

    As for the performance, backing up the database is an additional I/O load on the disk system, so yes there will be an impact. The performance will vary based on the bandwidth of your disk subsystem.


    ------------------------------
    Jon Kristofferson
    Pick Programmer
    JonKristofferson.com
    Elgin IL United States
    ------------------------------



  • 3.  RE: universe backup

    PARTNER
    Posted 5 days ago
    Hi Abdus,

    uvbackup vs. binaries backup 

    1/ uvbackup perform a read of all record on uv files you provide or discovered from OS (-walk) and send it where you redirect it.
    This is slower than a OS's binaries copy, for sure. But :
    - it guarantee a record level check of uvfile intergrity in the same time.
    - It's light - only the existing data are saved.   
    - I'm used to create a '.uvb' file per account to preserve.
    - Then you can manage  the '.uvb' files by day/week/month/year zipped on tape or cloud. 
    - Uvbackup offer a uvrestore capabilities which do in-place or renamed restore of  one file, one record, ... or everything in-place/renamed
    - You can restore a file on all uv plateform because uvrestore re-create the uvfile with 'create-file' on the current plateform.
    - You can use uvbackup as a incremental backup.  Each record added/modified from last uvbackup are saved. Then you can script to uvbackup once a week the full accounts and each day perform a incremental - really quick method. 
    - You can perform a uvbackup as users works on the system - for sure there is a risk at 'business transaction level' but no risk at binaries file/group level - if 'business transaction'  is critical - by addition, I suggest to use Transaction Processing and Transaction Logging . 
    - About performance impact, it's like one uvuser who read all records sequentially,  not more. If you have a large number of account, you can perform uvbackup on multiple parallel process. 
    I you are interested, I can share a basic (UV.MULTI.BACKUP) I use to organise uvbackup account by account, started on os schedule. 

    2/ other methods are binaries copies - all of them. 
    Yes 'you can' perform it at anytime but you risk binaries corruption at restore (T30-Dynamics have headers in-memory while working -  you must logout all users, Files can be updated at group level while you backup,  ... )  then you must SUSPEND and LOGOUT the user's activities including phantoms before backup which implies to restart sessions.
    Ok, today giga are not so relevant but a binaries copy is much larger than a uvbackup.
    To restore, you must work at os file level, then you receive a identical  binaries ... if you want to restore an account you can  rename the parent directory, ok, BUT all internals headers references the old path - : VOC, Indexes, Partfiles, ... be carefull to manage theses definitions before using the restored data. 

    my two pence.


    ------------------------------
    Manu Fernandes
    ------------------------------