Re: [gentoo-user] Writing a bash script or thinking about it anyway.

["Christian Könitzer" <chkab@gmx.ch>]

a question to b):
Can you tell me a fs that supports snappshots (I'm planing to set up a 
new server so you can choose a new fs... (now I am using reiserfs)) and 
maybe how to use it (link)? So if you say "or LSM" does this mean I can 
achieve this also woth LVM? How?
thx...

If you have some more tips, my current server runs on a single HDD and a 
daily rsync to another computer makes my backup. In my new server I'd 
like to improve as much as possible for as less money and energy as 
possible (since it's only for me...) so I thought about RAID as well. 
Today I'm using very old standard desktop hardware and for the new one I 
like to use also standard hardware so I don't know if I can afford a 
RAID-5 card or so... and I never made software RAID... do you have some 
recommendations (links?)? thx

cheers
Christian

Am 22.12.2009 13:11, schrieb Jesús Guerrero:
> On Tue, 22 Dec 2009 12:20:46 +0100, Christian Könitzer<chkab@gmx.ch>
> wrote:
>    
>> I agree with Jesús but recommend you to use rsync for backup purpose.
>> Simple google for rsync backup script.
>> And this link explains why:
>> http://www.sanitarium.net/golug/rsync_backups.html
>>
>> There are a lot backup scripts using rsync out there and most of them
>> are written in bash so it's anyway a good idea to learn a bit bash ;)
>>      
> That's basically it. I also agree that rsync is nowadays the way to go for
> general purpose backups, unless...
>
>    a) the volume can't be mounted while the backup is running (not the
> case)
>    b) your fs supports snapshots (or you use LVM)
>    c) you have an rcs based solution, like svn, git or whatever else
>
> The snapshot option is the absolute safest because it ensures that all the
> files will be consistent, and the tar based solution is probably the worst
> of them unless you truly can guarantee that the files are not being written
> concurrently while you do the backup (i.e. the fs is not being used at all
> or it's mounted read only). A good practice in any case is to capture the
> exist status of any given tool you are going to use to ensure that no error
> happened. Discovering that a backup is incomplete or corrupt when you need
> it is a bit unpleasant to say the least.
>
> Bash can be used for that, just to put a simple example. As you say,
> regardless of the solution of your choice to do the actual backup there's a
> lot of room for improvement, automation, error loging, verification, etc.
> using shell scripting.
>
>
>