Hi, Im trying to take a database backup. one of the files is 26 GB. I
am using cp -pr to create a backup copy of the database. after the
copying is complete, if i do du -hrs on the folders i saw a difference
of 2GB.

The weird fact is that the BACKUP folder was 2 GB more than the
original one!

when i did du -hrs * inside each of the 2 folders and compared the
output, i found the culprit. it was a file temp.dbf which was 26 GB on
the source(original) folder and 28 GB in the BACKUP folder. I tried the
copy procedure twice and I am getting the same result.

does anyone have any explanation for this. please let me know. I want
to make sure everything is right here in the copy.

PS:- Solaris SPARC 23 BIT.

Thanks

0ktalmagik <0ktalmagik@gmail.com> wrote:
> Hi, Im trying to take a database backup. one of the files is 26 GB. I
> am using cp -pr to create a backup copy of the database. after the
> copying is complete, if i do du -hrs on the folders i saw a difference
> of 2GB.
> 
> The weird fact is that the BACKUP folder was 2 GB more than the
> original one!
> 
> when i did du -hrs * inside each of the 2 folders and compared the
> output, i found the culprit. it was a file temp.dbf which was 26 GB on
> the source(original) folder and 28 GB in the BACKUP folder. I tried the
> copy procedure twice and I am getting the same result.
> 
> does anyone have any explanation for this. please let me know. I want
> to make sure everything is right here in the copy.
> 
> PS:- Solaris SPARC 23 BIT.
> 
> Thanks
> 

Are you copying a live file, or something in use by the database?
What does ls -l show for file size for original and copy?

In article <1149375551.171299.25960@c74g2000cwc.googlegroups.com>,
0ktalmagik <0ktalmagik@gmail.com> wrote:
>Hi, Im trying to take a database backup. one of the files is 26 GB. I
>am using cp -pr to create a backup copy of the database. after the
>copying is complete, if i do du -hrs on the folders i saw a difference
>of 2GB.
>The weird fact is that the BACKUP folder was 2 GB more than the
>original one!

What does "ls -ls" show for the original and the copy?

Database files are frequently sparse, they have holes that have
never been written to and don't occupy actual disk space.  Eg:
	% dd if=/dev/zero of=t1 bs=1k count=1 seek=10k
	% cp t1 t2
	% ls -ls t1 t2
	  40 -rw-r--r--   1 jgp      10486784 Jun  5 17:17 t1
	10256 -rw-r--r--   1 jgp      10486784 Jun  5 17:18 t2
	% du -s t1 t2
	40      t1
	10256   t2
t1 is only 40k on disk even though the final byte is at lseek
position 10486784.  One copied it grows to 10M since the holes
get filled in.

I believe ufsdump/ufsrestore are the only tools standard tools that
preserve holes in files.

Star ( http://cdrecord.berlios.de/old/private/star.html ) handles them.
-- 
Jim Prescott - Computing and Networking Group	jgp@seas.rochester.edu
School of Engineering and Applied Sciences, University of Rochester, NY

In article <e627dh$g4v@harn.ceas.rochester.edu>,
Jim Prescott <jgp@harn.ceas.rochester.edu> wrote:

>I believe ufsdump/ufsrestore are the only tools standard tools that
>preserve holes in files.
>
>Star ( http://cdrecord.berlios.de/old/private/star.html ) handles them.

If you use a pre S-2.6 or a recent Solaris, star is able to correctly copy
holes too. With star there is no need to be root in order to do this (at least
not on a recent Solaris version - the old Solaris hole interface forces you to
be root too).

-- 
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
      js@cs.tu-berlin.de		(uni)  
      schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily