| 1 |
Gruesse! |
| 2 |
* Max Bloch <max.bloch@××××××.de> schrieb am [22.12.06 10:02]: |
| 3 |
> Hallo allerseits, |
| 4 |
> |
| 5 |
> ich bin auf der Suche nach Ratschlägen für eine automatisierte |
| 6 |
> Backup-Lösung meines Desktop-Rechners. Im Moment mache ich noch Backups |
| 7 |
> per Hand. |
| 8 |
|
| 9 |
Ich habe persönlich zwei Lösungen im Gebrauch, die ich jeweils auch |
| 10 |
empfehlen kann: |
| 11 |
|
| 12 |
a) backuppc http://backuppc.sourceforge.net |
| 13 |
Ist eine Disk-basierte Netzwerkbackup-Lösung (fire & forget). Einfach zu |
| 14 |
konfigurieren, die Clients werden intelligent gesichert um Disk-Space zu |
| 15 |
sparen. Auf der Client-Seite keine Software außer rsync/tar/ssh notwendig. |
| 16 |
Für mich der Nachteil: schlechte Implementierung für "externe" Backups, |
| 17 |
also die Full+Incr-Backups "außerhalb" zu haben. Die vorgesehene |
| 18 |
Archiv-Lösung kann lediglich Vollbackups auf externe Medien sichern |
| 19 |
(Tape, CD/DVD,...). |
| 20 |
Da böte sich aber an, den Backup-Pool auf einer USB/FireWire-Festplatte |
| 21 |
zu haben, die durch geschickt gewählte Backup-Zeiten auch außerhalb |
| 22 |
mitgenommen wird. |
| 23 |
|
| 24 |
b) bacula http://www.bacula.org/ |
| 25 |
Ist für Streamer ausgelegt, kann aber auch auf anderen Medien sichern. |
| 26 |
Die Konfiguration ist nicht trivial, da es eine "große" Backup-Lösung |
| 27 |
ist. Für eine "wirkliche" Datensicherung bzw. Restore auf Tapes IMHO |
| 28 |
aber die beste Lösung unter Linux. |
| 29 |
|
| 30 |
Zu Clients, die nicht ständig im Netz sind: |
| 31 |
Du könntest zum einen deine Backup-Lösung von der 24h-Server-Seite her |
| 32 |
so erweitern, daß per cron z.B. alle Stunde geprüft wird (ping z.B.) ob |
| 33 |
Clients erreichbar sind, daß Backup starten und bei Erfolg den Client in |
| 34 |
eine finish-Datei aufnehmen, die der cronjob halt auch prüft und die |
| 35 |
jeden Tag z.B. resettet wird. |
| 36 |
|
| 37 |
backuppc ist per default auf so ein Szenario ausgelegt. Bei bacula ist |
| 38 |
der Default eher auf ständig erreichbare Rechner ausgerichtet, Jobs |
| 39 |
können aber auch eine lange Laufzeit haben in der versucht wird, den |
| 40 |
Client zu erreichen. (Damit "kämpfe" ich gerade, da ich gerne nach dem |
| 41 |
Abstauben einer 20GB-Streamers backuppc gegen bacula austauschen möchte. |
| 42 |
Oder backuppc um eine bessere Streamer-Unterstützung erweitern möchte). |
| 43 |
|
| 44 |
Viele schwören auch auf backup2l (bin nicht sicher, ob das Paket unter |
| 45 |
gentoo so heißt, konnte nur unter Debian nachsehen.) Damit habe ich aber |
| 46 |
keine Erfahrung. |
| 47 |
|
| 48 |
> Eine verschlüsselte Übertragung zum remote Backup Host ist für mich |
| 49 |
> zwingend notwendig. |
| 50 |
|
| 51 |
Bei a) geht die Übertragung per rsync oder tar, was beides über ssh |
| 52 |
verschlüsselt wird. |
| 53 |
b) verwendet eigene Deamons für die Clients, die Verbindung kann über |
| 54 |
TLS verschlüsselt werden. |
| 55 |
|
| 56 |
> Am liebsten wäre mir jedoch eine Lösung die ich ausschließlich auf der |
| 57 |
> Shell konfigurieren könnte. |
| 58 |
|
| 59 |
a) wird zentral per Text-Konfig konfiguriert. |
| 60 |
b) Text-Config zentral plus Client(s). |
| 61 |
|
| 62 |
> Übertragungen zum Backup Host sollten komprimiert sein um Bandbreite |
| 63 |
> zu sparen. |
| 64 |
|
| 65 |
Ist IMHO bei beiden nicht vorgesehen, lediglich auf der |
| 66 |
Server/Backup-Seite kann komprimiert werden. |
| 67 |
|
| 68 |
> |
| 69 |
> Gruß Max |
| 70 |
|
| 71 |
Gruß |
| 72 |
Gerhard |
| 73 |
-- |
| 74 |
It's nice to be important... |
| 75 |
but it's more important to be nice. |
| 76 |
|
| 77 |
-- |
| 78 |
gentoo-user-de@g.o mailing list |
Archives