Forum Discussion

tunisGharbi's avatar
11 years ago

vvr block-level backup

i have a primary site with 2 nodes Solaris 10 ( same config for the secondary site)

i'd like to synchronise data between the 2 sites using block-level backup

My query is the procedure to backup data : which command under solaris 10, scripts, ....

  • Just to add, in less you have a really slow link and/or a lot of data, synchronising over the network (using autosync which involve just starting replication with "-a" flag) is usually the best method, as even though it may take a few days to sync over the network, it can take this long to arrange getting tapes off site and transported to new site and imported into backup software catalogs, plus of course the time to backup and restore, and using autosync over the network is a lot less hassle.

    Mike

7 Replies

  • Thanks Mike

    Please let me know if i use the network method or block-level with chekpoint.

    May be the network is more better for my case but what about the error message that i have

     

    best regards.

  • thanks Mike 

    i have a lot of data:  2  RVG,  each RVG has 2 volumes  about 400GB for each one

    the network bandwith is about 10 to 40 mb/s

    when i synchronise with network it seems to be ok

    but when i  check the synchro by this command:

    vradmin -g DG_x -verify syncrvg myRvg Mvvr_secondary

    I have the following error:

    VxVM VVR vxrsync INFO V-5-52-10190 Verification of the remote volumes found differences.

    even if  i  ommit tis message when i test the remote site it seems to be ok but when i lunch rman

    i have the following error:

    Corrupt Block Found

             TSN = 2, TSNAME = SYSAUX

             RFN = 3, BLK = 1043, RDBA = 12583955

             OBJN = -1, OBJD = 3748, OBJECT = , SUBOBJECT =

             SEGMENT OWNER = , SEGMENT TYPE =

    Hex dump of (file 3, block 1043) in trace file ....

    Corrupt block relative dba: 0x00c00413 (file 3, block 1043)

    Bad header found during buffer read

  • Just to add, in less you have a really slow link and/or a lot of data, synchronising over the network (using autosync which involve just starting replication with "-a" flag) is usually the best method, as even though it may take a few days to sync over the network, it can take this long to arrange getting tapes off site and transported to new site and imported into backup software catalogs, plus of course the time to backup and restore, and using autosync over the network is a lot less hassle.

    Mike

  • You need to backup the device, rather than mountpoint, so if you have:

    /dev/vx/dsk/mydg/data mounted on /data 

    then you need to back up "/dev/vx/dsk/mydg/data", not /data.   

    How you select the device, rather than mount point to backup will depend on the backup software you are using, but I have no expertise in backup software, but you can use the UNIX "dd" utility:

    dd if=/dev/vx/dsk/mydg/data bs=4096 of=device_path_of_media_you_can_remove_from_server

    And to restore use:

    dd if=device_path_of_media_you_backed_up_on bs=4096 of=/dev/vx/dsk/mydg/data

     

    Mike

  • thanks Mike

     

    I'd like more details about step 2 please : Perform a block-level backup of the data volumes in the Primary RVG

    could you please help me about this? how to perform a block-level backup

    Thx.

    GHARBI

  • See "Using block-level backup and Storage Checkpoint" section in VVR admin guide:

    1. Start a Primary Storage Checkpoint using the vxrvg checkstart command:
    # vxrvg -g diskgroup -c checkpt_name checkstart local_rvgname

    2 Perform a block-level backup of the data volumes in the Primary RVG.

    3 End the Storage Checkpoint in the SRL when the backup is complete by using the vxrvg checkend command:
    # vxrvg -g diskgroup checkend local_rvgname

    4 Restore the backup to the Secondary data volumes.

    5 Start replication using the Storage Checkpoint after the restore on the Secondary completes:
    # vradmin -g diskgroup -c checkpt_name startrep local_rvgname sec_hostname

    After the RLINKs are attached, the Secondary remains inconsistent until it
    has received all of the accumulated updates up to the checkend. While the
    Secondary is inconsistent, the inconsistent flag is set on the Secondary
    RLINK. After all updates up to the checkend have been received and applied
    at the Secondary, the inconsistent flag is cleared.

     

    Mike