[kwlug-disc] backups capped at 2 gigs

[Khalid Baheyeldin]

This points to a limit on the user that runs cron, or the shell being
different (e.g. bash vs. sh).

On Mon, Jul 12, 2010 at 8:55 PM, Insurance Squared Inc. <
gcooke at insurancesquared.com> wrote:

>  OK, now that's weird.  I just cut and pasted the commands from the batch
> file to the command line and ran them directly.  Everything worked.  I've
> got a 35gig file  on the destination drive, as expected and hoped for.
> Running it via the cron limits the file size to about 2gigs.
>
> What the heck difference does it make going via cron vs. manual?  A 2 gig
> limit there doesn't make any sense.  I must be missing something.
>
>
>
>
> On 12/07/10 07:30 PM, Khalid Baheyeldin wrote:
>
> On Mon, Jul 12, 2010 at 7:24 PM, Insurance Squared Inc. <
> gcooke at insurancesquared.com> wrote:
>
>> That command worked with no error.  (I didn't see the error message
>> generated by tar because it's happening late at night.)
>
>
> Capture the output of tar to a file
>
> tar .... > /logfile.txt 2>&1
>
> This way you can see the error.
>
>
>> But I'm doing it manually right now - and it's already at 15gigs.  So it's
>> clearly NOT tar that's the problem.  It must be truncating after the tar
>> happens.
>>
>
> Or it could be the user, or shell that does the backup that is limited.
>
> Or cron runs under another user ID or shell?
>
>
>> So that's narrowing it down to the mv command or the destination drive
>> (once the files are zipped, I move them to another physical drive.
>
>
> It would be odd for a mv to just truncate.
>
> Again, capture the output from that command and see if there are errors.
>
>
>> That gives me archives by date).  I'm guessing that the filesystem type
>> (linux native) is going to be the ultimate problem here.  I'm not sure why
>> that drive is mounted as type linux native.  Something auto-generated I
>> expect.  We'll see soon if that's the problem.
>
>
> Yeah, that is an odd file system type to have.
>
> We know it is ext2 or ext3, because the tune2fs command worked on it.
>
>
>> (sometimes the solutions just require a second set of eyes prodding at
>> it).
>
>
> Agreed.
>
>
>>
>>
>>
>>
>>
>>
>> On 12/07/10 07:06 PM, Khalid Baheyeldin wrote:
>>
>>> dd if=/dev/zero of=/somedir/somefile bs=1048576 count=2049
>>>
>>  g
>>
>>
>> _______________________________________________
>> kwlug-disc_kwlug.org mailing list
>> kwlug-disc_kwlug.org at kwlug.org
>> http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org
>>
>
>
>
> --
> Khalid M. Baheyeldin
> 2bits.com, Inc.
> http://2bits.com
> Drupal optimization, development, customization and consulting.
> Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
> Simplicity is the ultimate sophistication. --   Leonardo da Vinci
>
>
> _______________________________________________kwlug-disc_kwlug.org mailing listkwlug-disc_kwlug.org at kwlug.orghttp://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org
>
>
> --
> Glenn Cooke
> Insurance Squared Inc.
> (866) 779-1499
> www.insurancesquared.com
>
> Insurance Agent Discussion Forum:www.americaninsurancebroker.com
>
>
> _______________________________________________
> kwlug-disc_kwlug.org mailing list
> kwlug-disc_kwlug.org at kwlug.org
> http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org
>
>


-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20100712/02a81d3d/attachment.htm>