Does that imply then that a TMC backed up sparse file could not be
restored to the same device it came off of? Would TMC attempt to
restore
all 26G?
Yes, and yes. Bitten by that one on Solaris too.
--
For LINUX-390
On Wednesday 21 July 2010 18:26, Sterling James wrote:
What's compression set to? I know that has other implications, also. Look
at the makesparsefile option for restore.
Tivoli Storage Manager backs up a sparse file as a regular file if client
compression is off. Set the compression option to
Hi listers,
On a SLES8 guest we have found that file /var/log/lastlog is reported to
be 26G. Also the /var/log/faillog is reported to be 2G. But, the /var is
located on a 3390 model 3. So that disk, that also contains other
directories, is only 2.3 G. Command df shows that the / is 83% in use.
On Wednesday 21 July 2010 05:03, van Sleeuwen, Berry wrote:
On a SLES8 guest we have found that file /var/log/lastlog is reported to
be 26G. Also the /var/log/faillog is reported to be 2G. But, the /var is
located on a 3390 model 3. So that disk, that also contains other
directories, is only 2.3
Hello Edmund,
Sparse files. OK. Then the next question, how can I store a 26G file in
a machine that isn't that large? And to add to this, why does the
filesystem backup really dump 26G into our TSM server?
So it looks like the data is going somewhere.
Berry.
Op 21-07-10 15:41, Edmund R.
RSYNC is your friend.
rsync -a -S sourcedir/. targetdir/.
where -S means handle sparse files intelligently. TAR also has an
option for handling sparse files.
-- R;
On Wed, Jul 21, 2010 at 11:59, Berry van Sleeuwen
berry.vansleeu...@xs4all.nl wrote:
Hello Edmund,
Sparse
On Wednesday 21 July 2010 11:59, Berry van Sleeuwen wrote:
Sparse files. OK. Then the next question, how can I store a 26G file in
a machine that isn't that large? And to add to this, why does the
filesystem backup really dump 26G into our TSM server?
Because it isn't really using 26GB of disk
Sparse files. OK. Then the next question, how can I store a 26G file in
a machine that isn't that large?
Because sparse files are just a bunch of pointers -- the data doesn't really
exist. It's just diddling around with the directory inode.
And to add to this, why does the
filesystem backup
Thank you all for your replies. It's clear to me, we were dumping zero's.
Regards, Berry.
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390
Does that imply then that a TMC backed up sparse file could not be
restored to the same device it came off of? Would TMC attempt to restore
all 26G?
On 07/21/2010 12:14 PM, David Boyes wrote:
Sparse files. OK. Then the next question, how can I store a 26G file in
a machine that isn't that
On Wednesday 21 July 2010 17:48, Dave Jones wrote:
Does that imply then that a TMC backed up sparse file could not be
restored to the same device it came off of? Would TMC attempt to restore
all 26G?
I would expect so. If it doesn't know enough to preserve the sparseness of a
file as it backs
I might just add that despite it's manpage assertion, rsync isn't too
intelligent about it at all.
My (non z) testing indicated that if you re-use the same target file, after
the initial run cp is significantly more efficient. The initial run for
both is comparable as the target needs to be
files to minimize network transaction
time and maximize server storage space.
Thanks
From:
Edmund R. MacKenty ed.macke...@rocketsoftware.com
To:
LINUX-390@VM.MARIST.EDU
Date:
07/21/2010 04:58 PM
Subject:
Re: Files on disk
Sent by:
Linux on 390 Port LINUX-390@VM.MARIST.EDU
On Wednesday 21
13 matches
Mail list logo
