Yeah, but under my scheme, all log files would be present (with some
or all of them compressed) before the backup starts, which I believe
is different than what you're proposing - that is, starting backups
with some logs missing.

Kurt

On Thu, Aug 12, 2010 at 14:18, Matt Moore <[email protected]> wrote:
> Good plan Kurt but, to add, if I may never move logs without first using 
> eseutil /mk on the chk file to determine the check point and which logs can 
> be moved safely.  Save them in a safe place and then run the backup.  The % 
> free space is kind of a moving target as we don't know how much mail is 
> received at any given time but 10% should get them into backup range, 15%+  
> better.
>
> M
>
> -----Original Message-----
> From: Kurt Buff [mailto:[email protected]]
> Sent: Thursday, August 12, 2010 1:55 PM
> To: MS-Exchange Admin Issues
> Subject: Re: Log Drive Full
>
> Cool. I believe that's what MBS was getting at.
>
> If it were me, I'd move a few hundred of the latest log files to a
> different partition, then start compressing the oldest log files, a
> few hundred at a time, and when you have a bunch of them compressed
> (maybe a thousand or so) move the files back that you placed
> elsewhere, and keep going with your compression, until you have free
> disk space equal to some significant fraction of your total partition
> space - I'd guess about 10% free, but others will have a better answer
> on that exact number. At any rate, once that amount of free space is
> obtained, backups will work, and log files will disappear.
>
> This will take some time, but it's certainly a very clean way of
> getting this done.
>
> I definitely wouldn't highlight the log directory and compress the
> entire directory. - that will cause other problems.
>
> Stay the course.
>
>
> Kurt
>
> On Thu, Aug 12, 2010 at 13:41, Chris Blair <[email protected]> wrote:
>> Windows built in compress
>>
>
>
>
>
>


Reply via email to