Another benefit of the image/snapshot is that it would eliminate the
huge burden that the file-level backup has on you TSM DB. For example;
if that filespace has 1 million files that results in 1 million entries
in the DB, since the image or snapshot is a single object there is only
a single entry
I'm wondering if a Fastback type (block level incremental image) backup might
be the answer. Backing up changed blocks might be faster than trawling the
filesystem, and the ability to mount a point in time image would provide you
with file level restore as well as DR image recovery.
Just a thou
Snapshots/image backups?
Don't think about the backup, think about the restore RTO/RPO.
What kind of restore scenarios do you have, how much data (in time) can you
afford to lose and what is your acceptable restore time?
Will you ever need to restore individual files? I'm not familiar with
Black
>> On Tue, 27 Apr 2010 10:20:44 -0700, Robert Clark
>> said:
> Where should you go? There has to be a good bar near campus.
Yeah, that. But before you go, print out some web pages on Sakai.
I have (or once had) the dubious honor of being the admin of the
fastest disaster-recovery of any enter
Where should you go? There has to be a good bar near campus.
Start off with an OS family with notoriously slow stat calls, and then add
the I/O latency of virtualization? Hey, at least it isn't running under
Open Solaris?
I would look at turning on journal based backup. To initially establish a
v
Can you RAR or tar/gzip the entire directory and then backup that one file? Is
adding more RAM to the box an option?
Some file server optimizations ( not tested by me ):
http://msmvps.com/blogs/sp/archive/2009/04/24/windows-file-server-performance-optimization.aspx
Ray
-Original Message
If you have problems running dir/s you might have system issues already.
Would take a look at the memeff diskcache option, but this will take up
some free disk space.
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp?topic=/
com.ibm.itsmfdt.doc/ans5331.htm
Regards,
K.
-
