Remsh and named pipes for Remote Backup

[Yogeeraj]

Hello experts,

We have 2 servers a K250 and a L1000. Unfortunately, we do not have a tape drive on the L-class.

I previously used the following commands to backup some of my files:
-----------------------------------------------
dd if=/dev/rmt/0m|remsh k250 dd of=/dev/rmt/0m
tar cvf /dev/rmt/0m
-----------------------------------------------
It works fine.

But now i need to use the uvf switch, but strange enough this does not work.

I really need this options to do an online Image backup of my Oracle Database. Normally my backup script should contain the following instructions:
-----------------------------------------------
--
--PFS_TBS_FD /d06/oradata/cmtdb/pfs_tbs_fd01.dbf 1224 MB
--
ALTER TABLESPACE PFS_TBS_FD BEGIN BACKUP
/
!tar uvf /dev/rmt/0m /d06/oradata/cmtdb/pfs_tbs_fd01.dbf
ALTER TABLESPACE PFS_TBS_FD END BACKUP
/
--
--PFS_TBS_KN /d03/oradata/cmtdb/pfs_tbs_kn01.dbf 1024 MB
--
ALTER TABLESPACE PFS_TBS_KN BEGIN BACKUP
/
!tar uvf /dev/rmt/0m /d03/oradata/cmtdb/pfs_tbs_kn01.dbf
ALTER TABLESPACE PFS_TBS_KN END BACKUP
/
--
-----------------------------------------------
I have also observed that my two servers were configured with 2 different UTC. So that when i check my dates i have the following:
-----------------------------------------------
K250: home/yd>date
Thu Dec 20 13:24:30 MRU 2001
K250: home/yd>date -u
Thu Dec 20 10:24:33 UTC 2001
K250: home/yd>cat /etc/TIMEZONE
TZ=MRU-3
export TZ
K250: home/yd>echo $TZ
MRU-3

L1000: home/deg>date
Thu Dec 20 13:27:52 MRU 2001
L1000: home/deg>date -u
Thu Dec 20 17:27:56 UTC 2001
L1000: home/deg>cat /etc/TIMEZONE
TZ=MRU+4
export TZ
L1000: home/deg>echo $TZ
MRU+4
-----------------------------------------------
I believe that because of this, the date/timestamp on my NFS mounted files systems are not correct. Also, when i check the content of the files backuped to my DDS tape, i see files created ahead of time!!
-----------------------------------------------
L-oracle8i: d01/app/oracle/admin/cmtdb/arch>ll
total 222300
-rw-r--r-- 1 oracle8i dba 8953856 Dec 19 15:23 arch_1_2156.arc
-rw-r--r-- 1 oracle8i dba 20971520 Dec 19 17:03 arch_1_2157.arc
-rw-r--r-- 1 oracle8i dba 20972544 Dec 19 22:29 arch_1_2158.arc
-rw-r--r-- 1 oracle8i dba 20972544 Dec 20 08:23 arch_1_2159.arc
K250: home/yd>tar tvf /dev/rmt/0m
rwxr-xr-x 101/101 4622 Dec 13 15:58 2001 ./arch_redolog.sh
rwxr-xr-x 101/101 3079 Dec 10 09:41 2001 ./init_redolog.sh
rw-r--r-- 0/3 8953856 Dec 19 22:23 2001 ./arch_1_2156.arc
rw-r--r-- 0/3 20971520 Dec 19 00:03 2001 ./arch_1_2157.arc
rw-r--r-- 0/3 20972544 Dec 19 05:29 2001 ./arch_1_2158.arc
rw-r--r-- 0/3 20972544 Dec 20 15:23 2001 ./arch_1_2159.arc
K250: home/yd>date
Thu Dec 20 10:36:48 MRU 2001
-----------------------------------------------

Please help me sort out these problems.

I hope that i have not confused you all.

Regards
Yogeeraj
HAPPY NEW YEAR and MERRY CHRISTMAS

[harry d brown jr · Accepted solution]

Yogeeraj,

The problem you are encountering is caused by using a named pipe. tar on your L-class won't be able to determine where the end of the previous archive is, therefore it really won't work. You have at least three choices:

(1) use fbackup - it will backup from serverL to serverK.
(2) get gnu's tar, which allows you to tar from one machine to a device on another
(3) write the tar backup to a FILE locally on your L-class, then rcp it to your K, or dd it to your K's tape drive.

live free or die
harry

[Steven Gillard_2]

I assume that /dev/rmt/0m is a named pipe on the Lclass?

I am not surprised that the u option to tar does not work. This option causes tar to replace a file if the modification time is newer - which implies the tar command is going to read from the archive first. With your setup that read is going to fail because tar cannot retrieve information from the actual archive on the tape via the named pipe.

If you want that functionality you will probably have to write a script which first performs a tar tvf on the tape via remsh, and uses this output to decide which files should be added with the c option to tar.

With respect to your time problem, that is a situation that you will want to rectify. UTC should be the same on all systems - having it different is definitely going to cause incorrect timestamps to appear especially when NFS is in use.

The steps to fix the problem will depend on whether you want to run a clock forwards of backwards. If you need to run one of the clocks forward, then this can be done by stopping Oracle, changing the TZ variable and then running the date command. I would then perform a reboot so all applications pick up the TZ change.

To run the clock back is more complicated. You will need to use the date command with the -a option to slowly adjust the time, which will take a while if your clock is a few hours out. This can be done while applications are running but they will start displaying incorrect time information. Once the UTC is correct you should change TZ and reboot the system.

Remember, the impact of doing this depends on your application. If your apps are very time sensitive then you will need to plan this carefully! And once you do fix the clocks I strongly recommend running ntp to avoid this type of problem in the future.

Hope this make sense. Good luck!

Regards,
Steve

[Volker Borowski]

Hi Yogeeraj,

the most obvious way out would be to use a no-rewind device and write a NEW archive to the tape each time. The benefit will be that you will be quicker upon restore, because if you loose filesystem /d06 you can "mt" directly to the fileset in charge.

Would be like this:

tar cvf - /dir/dbfile1 | remsh target dd of=/dev/rmt/0mn
tar cvf - /dir/dbfile2 | remsh target dd of=/dev/rmt/0mn
tar cvf - /dir/dbfile3 | remsh target dd of=/dev/rmt/0mn

You then have three archives on the tape, which you can restore with

remsh target dd if=/dev/rmt/0mn | tar xvf -
remsh target dd if=/dev/rmt/0mn | tar xvf -
remsh target dd if=/dev/rmt/0mn | tar xvf -

or, if you only like to have the third set

mt -t /dev/rmt/0mn fsf 2
remsh target dd if=/dev/rmt/0mn | tar xvf -

I think the append will not work over a pipe.
Volker