1 |
a question to b): |
2 |
Can you tell me a fs that supports snappshots (I'm planing to set up a |
3 |
new server so you can choose a new fs... (now I am using reiserfs)) and |
4 |
maybe how to use it (link)? So if you say "or LSM" does this mean I can |
5 |
achieve this also woth LVM? How? |
6 |
thx... |
7 |
|
8 |
If you have some more tips, my current server runs on a single HDD and a |
9 |
daily rsync to another computer makes my backup. In my new server I'd |
10 |
like to improve as much as possible for as less money and energy as |
11 |
possible (since it's only for me...) so I thought about RAID as well. |
12 |
Today I'm using very old standard desktop hardware and for the new one I |
13 |
like to use also standard hardware so I don't know if I can afford a |
14 |
RAID-5 card or so... and I never made software RAID... do you have some |
15 |
recommendations (links?)? thx |
16 |
|
17 |
cheers |
18 |
Christian |
19 |
|
20 |
Am 22.12.2009 13:11, schrieb Jesús Guerrero: |
21 |
> On Tue, 22 Dec 2009 12:20:46 +0100, Christian Könitzer<chkab@×××.ch> |
22 |
> wrote: |
23 |
> |
24 |
>> I agree with Jesús but recommend you to use rsync for backup purpose. |
25 |
>> Simple google for rsync backup script. |
26 |
>> And this link explains why: |
27 |
>> http://www.sanitarium.net/golug/rsync_backups.html |
28 |
>> |
29 |
>> There are a lot backup scripts using rsync out there and most of them |
30 |
>> are written in bash so it's anyway a good idea to learn a bit bash ;) |
31 |
>> |
32 |
> That's basically it. I also agree that rsync is nowadays the way to go for |
33 |
> general purpose backups, unless... |
34 |
> |
35 |
> a) the volume can't be mounted while the backup is running (not the |
36 |
> case) |
37 |
> b) your fs supports snapshots (or you use LVM) |
38 |
> c) you have an rcs based solution, like svn, git or whatever else |
39 |
> |
40 |
> The snapshot option is the absolute safest because it ensures that all the |
41 |
> files will be consistent, and the tar based solution is probably the worst |
42 |
> of them unless you truly can guarantee that the files are not being written |
43 |
> concurrently while you do the backup (i.e. the fs is not being used at all |
44 |
> or it's mounted read only). A good practice in any case is to capture the |
45 |
> exist status of any given tool you are going to use to ensure that no error |
46 |
> happened. Discovering that a backup is incomplete or corrupt when you need |
47 |
> it is a bit unpleasant to say the least. |
48 |
> |
49 |
> Bash can be used for that, just to put a simple example. As you say, |
50 |
> regardless of the solution of your choice to do the actual backup there's a |
51 |
> lot of room for improvement, automation, error loging, verification, etc. |
52 |
> using shell scripting. |
53 |
> |
54 |
> |
55 |
> |