[TriLUG] Linux Backup Strategies

[Glen Ford]

Aaron S. Joyner wrote:

> Samba is plenty-capable of handling >2GB files - I use the 
> functionality on a regular basis.  On the other hand, if the 
> underlying filesystem can not, things can get ugly.  As long as you're 
> on a modern filesystem in Linux (ext3, reiser, etc), with a reasonably 
> recent version of samba (>2.0) then you should not run into a 2GB file 
> size limitations.  If that's not the case, do let us know.
>
> Aaron S. Joyner
>
>
> Brian Henning wrote:
>
>> ...so then has the 2GB single-file size smb 'bug' been fixed?  I 
>> recall many
>> moments of frustration surrounding a similar project, where the smb 
>> transfer
>> seemed to stall (read: everything ground to a halt), and I found that 
>> the
>> reason was that smb puked on files larger than 2 gigabytes..  I don't 
>> know
>> if that's still an issue, but if it is, you'll need to use a utility (or
>> tar's built-in ability) to segment your images into <2GB chunks.  (Be 
>> aware
>> that, as far as my limited knowledge goes, tar's volume-sizing 
>> ability does
>> not include sequential naming, so you'll have to wrap it in some other
>> script to rename each chunk after tar finishes with it)
>>
>> Cheers,
>> ~Brian
>>
>> ----- Original Message ----- From: "Aaron S. Joyner" <aaron at joyner.ws>
>> To: "Triangle Linux Users Group discussion list" <trilug at trilug.org>
>> Sent: Wednesday, June 16, 2004 7:37 AM
>> Subject: Re: [TriLUG] Linux Backup Strategies
>>
>>
>>  
>>
>>> dd if=/dev/hda of=/path/to/samba/share/image.dmg
>>>
>>> To dump a full-sized image of your disc to the samba share, the above
>>> command will do the trick.  On the other hand, if you'd prefer a more
>>> elegant solution (which only works over ftp) check out the g4u package.
>>> If space over speed is a concern, you can also compress the image 
>>> like so:
>>>
>>> dd if=/dev/hda | gzip > /path/to/samba/share/image.dmg
>>>
>>> As an additional concern, if you'd like not to take up more space in 
>>> the
>>> image than necessary, at the expense of not being able to "undelete"
>>> anything you may have already deleted (not such a big concern, imho) -
>>> you can clear out all of the once-used space on the drive, like this...
>>>
>>> dd if=/dev/zero of=/zerofile.tmp ; rm /zerofile.tmp
>>>
>>> If you have more than one partition, you'll need to create a zero file
>>> like the one above, for each partition.  A bash script to automate that
>>> based on /etc/fstab shouldn't be more than about 6 lines.  Keep in 
>>> mind,
>>> that of course if you have more than one disc in the computer you'll
>>> need to do it for each disc, and of course you may need to adjust the
>>> /dev/hda references above if you're not using a single ide drive 
>>> located
>>> as the primary master.
>>>
>>> Personally, I wouldn't do it image-style as this suggests.  I would use
>>> tar or dump, as it creates a more concise image, and gives you the
>>> flexibility of doing incrementals in the future.  Also, tar or dump 
>>> will
>>> give you the ability to easily do individual file restore.  As another
>>> step in the direction of elegance, Jeremy presented on rsync backups
>>> using rsbackup at the May meeting.  It's yet another "better" solution,
>>> although depending on your purposes it may be cumbersome over smb.
>>>
>>> All of this was covered in Jeremy's and Jason's recent backup
>>> presentation.  The presentation itself should be searchable in the
>>> archives, sometime around the 2nd tuesday of May.  Hope that's a start!
>>>   
>>
>> :)
>>  
>>
>>> Aaron S. Joyner
>>>
>>>   
>>
>>
>>
>>  
>>
>
I thought 2gig file size limit had to do with the 32bit operating system.

/glen


-- 
Glen Ford
gford at idiom.com