Mal wieder ZFS und Hardwarefragen ;)

minimike

minimike

Berufsrevolutionär
Hi

Der neue Job fordert mich richtig. Ich muss die Hardware für eine Backuplösung planen und das alles schon ab dem dritten Tag.
Unser Hausdealer ist Thomas Krenn und da habe ich mich in die Hardware verguckt

http://www.thomas-krenn.com/de/prod...le-cpu/3he-intel-single-cpu-sc836-server.html

Als OS soll FreeBSD oder RHEL 6 drauf. FreeBSD 8.3 ist mir lieber.

Auf der Kiste läuft dann Bacula und PostgreSQL für Bacula. Sowie noch einige Webtools für Bacula damit nicht nur ich sondern auch andere damit umgehen können.

Nun geht es darum das Budget zu optimieren. Sollte ich mir da noch einen extra Raidcontroller kaufen? Da wäre der optionale von LSI bei Krenn.

Und ich habe da noch Highpoint in Errinnerung. Gibt es da einen der 16 Platten mit FreeBSD intern unterstützt? Sowie etwas das 2 SAS 600 Geräte extern ansprechen kann.

bei 16 Platten was wäre besser? Ein HW Raid oder doch besser ZFS weil ich dann writecaching auf den Platten habe?

Bei reinem ZFS ohne HW Raid, was wäre dann die beste Konfiguration Betreff der Redundanz? Vor allem irgendwann könnte ich ja dann online

und ich habe gesehen das die großen Platten ab 2 TB 4K Sektoren haben. Muss ich da bei ZFS noch etwas beachten?
 
hi

fuer zfs ist kein raidcontroller noetig , eher sogar kontraproduktiv.
wenn du z.b. lsi 9211-i bekommsts , ohne raid firmware, ist es perfekt.

was das aufteilen der platten betrifft wuerde ich bei dem genannten scenario 2 pools
machen .
1x raidz1 fuer bacula
1x ein oder mehere mirrors fuer die db je nach kapazitaet.

insgesamt nur 15 platten verwenden 1x host spare.

wenn du freebsd9 nimmst , habe ich hier laufen , musst du dich um das 4k thema
nicht kuemmern .

holger
 
Also über den Cache eines RAID Controllers freut sich ZFS natürlich. Beim Lesen ist ZFS allerdings nicht drauf angewiesen, weil es massiv den Arbeitsspeicher als Lesecache benutzt. Beim Schreiben kann der Cache eines RAID Controllers helfen. Zumindestens unter Solaris gab es bestimmte Controller die ZFSs Flushbefehle direkt an die Platten weiter gaben anstatt ihr durch die BBU gesichertes RAM zu verwenden und dennoch das Writecaching der Platten deaktiviert haben. Das merkt man schnell, weil es quälend lahm ist.

Es schadet beim Einsatz von ZFS allerdings das RAID durch den Controller zu erledigen. Damit werden ZFSs Selbstheilungsmöglichkeiten außer Kraft gesetzt, Performancegewinne zunichte gemacht und ZFS zu einem bequemen LVM degradiert.
 
Hallo,

da das resilvern bei großen Platten viele Stunden dauert würde ich eher ein Raid-z2 wählen, die Hotswap Platte ist dann eher eine Geschmacksfrage?

Gruß ré
 
Oh ja GEOM funktioniert in der Theorie wunderbar und gibt brav an ZFS weiter was die Platten ihm vorlügen. In der Praxis muss man leider auch mit FreeBSD 9.0 noch etwas nach helfen.
 
minimike schrieb:
Hi

Der neue Job fordert mich richtig. Ich muss die Hardware für eine Backuplösung planen und das alles schon ab dem dritten Tag.
Unser Hausdealer ist Thomas Krenn und da habe ich mich in die Hardware verguckt

http://www.thomas-krenn.com/de/prod...le-cpu/3he-intel-single-cpu-sc836-server.html

Als OS soll FreeBSD oder RHEL 6 drauf. FreeBSD 8.3 ist mir lieber.

Auf der Kiste läuft dann Bacula und PostgreSQL für Bacula. Sowie noch einige Webtools für Bacula damit nicht nur ich sondern auch andere damit umgehen können.

Nun geht es darum das Budget zu optimieren. Sollte ich mir da noch einen extra Raidcontroller kaufen? Da wäre der optionale von LSI bei Krenn.

Und ich habe da noch Highpoint in Errinnerung. Gibt es da einen der 16 Platten mit FreeBSD intern unterstützt? Sowie etwas das 2 SAS 600 Geräte extern ansprechen kann.

bei 16 Platten was wäre besser? Ein HW Raid oder doch besser ZFS weil ich dann writecaching auf den Platten habe?

Bei reinem ZFS ohne HW Raid, was wäre dann die beste Konfiguration Betreff der Redundanz? Vor allem irgendwann könnte ich ja dann online

und ich habe gesehen das die großen Platten ab 2 TB 4K Sektoren haben. Muss ich da bei ZFS noch etwas beachten?
Zum Vergrößern anklicken....

Ganz grundsätzlich... auch wenn Du die Raidfeatures nicht nutzt...... ein LSI Contzroller besser zwei, für den Fall das einer ausfälllt.. tut niemals weh.

Besser wär es aber.... wenn Du dir zwei Disk Shellfs hinstellst... die nicht Serverintern sind... über FC HBA anbinden und den Backup Zpool über die Shellfs spiegeln und dazu pro Shellf mindestens zwei Pfade.

Wenn Du es wirklich professionel machen willst, setzt du die Shellfs auch an zwei unterschiedliche Standorte, nicht ins gleiche Rack!

Wenn es schon Thomas Krenn als Lieferant sein soll... würde ich mir auch ernsthaft überlegen... ob ich nicht ein Nexentastor hinstellen.... damit kannst Du Dir einen Haufen Frickelei sparen.

Das lässt sich dann auch bei Bedarf mit weiteren Shellfs erweitern und ist definitiv keine Frickel sondern eine professionelle Lösung.
 
Zuletzt bearbeitet:
Zu 4k Sektoren: FreeBSD hat eine "Known to be good"-Liste und versucht mit der und ein wenig Magie zu erkennen, ob die "512 Byte" sagende Platte nicht doch 4k Sektoren hat. Das klappt auch recht gut, aber eben nicht immer.
 
Hi,
joar, wobei das mit "nicht immer" dann halt in dem Fall wo`s ned klappt Bärenscheiße ist - von daher würde ich IMMER die Werte vorgeben wenn ich se sicher kenne um das Problem oifach zu vermeiden.
Beste Grüße
Bummibär
 
Danke für eure Tips!

Bei 32 TB a 16 x 2 TB mit ZFS reichen da 8 GB Ram oder sind da 16 GB - 32 GB besser?
Auf dem System laufen nur die beschriebenen Anwendungen. Also nicht wirklich viel. Das einzige was da Dampf braucht ist ZFS.

Warum ich mich gegen einen Raidcontroller entscheiden möchte? In den vergangenen Monaten habe ich bei meinem alten Job zwei ältere Installationen verloren. Der Raidcontroller ist ausgefallen und es hat bis zu vier Tage gedauert die alten Dinger zu organisieren. Einmal hatten wir sogar noch eine Ersatzkarte. Allerdings mit einer älteren Firmware. Dadurch wurde vermutlich der Raid zerballert. Die Server waren länger offline und wir konnten in jedem Fall das Backup einspielen. Trotzdem hatten die Kunden kein Verständniss für die Downtime.

Das Unternehmen wo ich jetzt arbeite wagt gerade den evolutionären Sprung vom Kleinbetrieb zu einem mittelständischen Unternehmen. Und da in Zukunft noch einiges kommt will ich gerne dabei sein. Ich habe die Chance von Grund auf die Zukunft aktiv mitzugestalten. Nicht als Befehlsempfänger sondern als Visionär.
 
Hi,
wenn dem so ist würde ich mal in Richtung Supermicro schauen. Da gibts das eine oder andere Board wo bärig viel Möglichkeiten hat - z.B. bis zu 256 GB Ram und zwei CPU-Bärlis. Als Storage mit ZFS wäre das wenn Du selbst gestalten willst und nichts Fertiges kaufen sicher derzeit die beste Lösung. Beim RAM gillt der alte Bärengrundsatz: Ram ist durch nichts zu ersetzen außer durch mehr RAM oder schnelleres RAM oder größeres und schnelleres RAM - d.h. viel hilft viel. Also würde ich da nicht gleckern wegen ein paar Euro und oifach mal ordentlich was neistecken. Ich würde hier schon eher zu 64 GB RAM mindestens tendieren, wobei das technisch grundsätzlich mit 16 schon auch geht. Interessanter ist dort eher die Wahl der HD Art / Schnittstelle und des richtigen Controllbären bzw. zwei Controllbären je nachdem ob mer SATA spielt oder mit SAS spielt. Zum vernünftig arbeiten ist die Bestückung mit mehr als einem Controllbären und mit zusätzlichen SSD für Cache und Log und Co und mit viel RAM natürlich eine deutlich bessere Idee. Hier stellt sich natürlich abär auch immer die Frage ob man nicht sofort was gescheites kauft wo fertig ist statt das Rad neu zu erfinden obwohl es das schon gibt in der Hoffnung es würde runder werden.

Insbesondere bei ZFS darauf achten, dass der Controllbär / die Controllbären NICHT mit HW-Raid Modis betrieben werden ! - das geht entweder mit spezieller Firmware darauf oder mit Controllbären wo mer die HDs direct durchschleifen kann ohne HW Raid (wobei Letzteres meist unnötig teuer dann wird). Wichtig ist auch darauf zu achten, dass Firmware Updates der Festplatten durch den Controllbären hindurch möglich sind ! - es nutzt nichts wenn mer schöne Controllbären hat mit ZFS und nette Platten und nicht in der Lage ist bei Firmware Bugs der HDs diese zu aktualisieren.

Klare Empfehlung wenn Du bauen willst:
- 2x SAS2 Controllbären nehmen zu je 8 HD mit SAS2 und 24/7 Freigabe und 64 MB Cache pro HD. Bein den Controllbären auf Firmware ohne HW-Raid Funktion in diesem Fall natürlich dann achten. LSI z.B. mit spezieller Firmware oder Areca mit Direct Access Mode werden hier gerne genommen - wobei LSI preislich günstiger wäre.

- mind. 64 GB RAM-Bären neistecken (z.b. 4 x 16 GB ECC), wobei die Modulgröße natürlich je nach Board pro Slot die maximale sein sollte, das der maximale Aufrüstungszustand möglich ist später ohhne die bisherigen Module tauschen zu müssen.

- mind. Xeonbärlis oder Opteronbären verbauen, da die bissel Wurst au vom Brot ziehen. Wenn koi große CPU Last erwartet wird kann mer hier natürich au eher auf de Stromverbrauch (max TDP) bärig achten.

- mind. zwei Netzteile (redundant) - ausfallen kann immer mal was und ohne Strom läuft bekanntlich bärig garnix.

- Ersatzteile vor Ort bärig vorhalten, welche baugleich sans. Insbesondere bei de Controllbären natürlich wenn mer Firmware Updates z.B. macht die au auf de Ersatzteile entsprechend gleich durchführen, damit das immer auf dem identischen Stand ist. Au wenn es lästig ist abär nur so kanns klappen.

- ZIL Cache / Log usw. möglichst uf SSDs auslagern bärig, da der Durchsatz und die Zugriffszeit bärig deutlich günstiger sans. Hier hat sich in de Praxis Intel und FusionIO bisher ganz gut bewährt. Die Größe hier ist nicht der einzig entscheidende Punkt - bei der Auswahl ist Durchsatz und Zugriffszeit bärig ebenso wichtig.

- alle HD möglichst in HotSwap Rahmen verbauen mit schöne Backplane, damit mer bei Ausfall fix ran kümmts ohne große Probleme und Zeitaufwand. Das kostet nur oi mal Geld und erspart Dir später viel Ärger. Ich kann es nicht oft genug sagen: Jungs/Mädels BESCHRIFTEN !!!!! - oder Controllbären & Backplanes nehmen wo die HDs identifizieren können und optisch signalisieren können - trotzdem BESCHRIFTEN !!!!

- Auf korrekte Kühlung der Komponenten bärig fein achten - zu viel Hitze ist was worauf die garned gut reagieren - se werden es Dir mit langer Haltbarkeit dann danken.

- Den alten Grundbärensatz beachten, das ein Raid noch lange koi Backup ersetzt. Ja ich weiss, das ist klar abär ich höre in letzter Zeit immer wieder von Fällen im Chan wo es koi Backup gab sondern Snapshots und co die dann im Eimer waren.

Gruß Bummibär
 
Zuletzt bearbeitet:
Anekdoten weisen darauf hin das SAS Expander sich im Fehlerfall nicht mit SATA Platten vertragen. Solltest du wirklich SATA Platten verbauen wollen dann verzichte auf Backplanes mit SAS Expandern (oder gar SATA Portmultipliern). Solange ein Port pro Platte auf allen Kabel durch gereicht wird dürften keine Expander im Spiel sein. SAS wird gerne als 4 Ports pro Kabel verlegt erst recht außerhalb des Gehäuses. Ich bin mir allerdings nicht sicher ob überhaupt jemand 4HE Gehäuse mit 40+ 3.5" Einschüben ohne Expander günstig anbietet.
 
Dem Bären kann ich nur zustimmen. Insbesondere was das Thema Neuerfindung des Rades angeht.

Raid ist kein Backup.... alles richtig, g, aber Backup ohne Tape Libraries ist auch kein seriöses Backup sondern Frickelscheiss. Backup nur auf einen einzigen Filer ist ebenfalls grob fahrlässig.. normalerweise sieht man zu das man sowas über Kreuz macht und nicht auf ein Blech. Auch nicht über den gleichen Netzwerk oder SAN Switch.

Backup Infrastruktur kostet Geld, ob mit proprietärer oder nicht proprietärer Software ist völlig wumpe.
 
Hi,

joar zwecks Backup am besten oifach bärig regelmäßig sichern und das ganze auf einem möglichst zweiten Ziel ablegen, wo nach Möglichkeit sogar an einer anderen Location oder zumindest räumlich getrennt steht. Das Thema Brandbärenschutz sollte man bei wichtigen Daten natürlich auch nicht vernachlässigen, da gerade bei Brandfällen oft nur Backups übärleben die eben an einem anderen Standort waren.

Empfehlung des Bären:
- Backups in gleichen Zeitabständen bärig erstellen
- Datenkonsistenz / Datenintigrität jeweils prüfen ! - z.B. mittels sha1 / sha256 Hash Werten
- korrekte Sicherungsmethoden wählen, je nachdem was zu sichern ist - also z.B. für Datenbanken möglichst einen Dump erzeugen, Files z.B. eher in Archiven oder per Rsync und co ....
- Backups grundsätzlich immer wo extern aufbewahren
- die Methode mit welcher Sie erstellt wurden dokumentieren
- die Software wo verwendet wurde archivieren - damit eine Rücksicherung jederzeit möglich ist
- das hierzu passende OS sichern, damit auch das später immer zur Verfügung steht
- Datenformate / Filesysteme verwenden, welche möglichst dokumentiert sind - um zu gewährleisten das die später auch noch gelesen werden können ( also z.B. KEIN NTFS oder so Unfug !)
- möglichst auch regelmäßig prüfen ob es sich vollständig fehlerfrei zurücksichern lässt
- Methoden verwenden die möglichst mit wenig Aufwand eine Rücksicherung zulassen
- qualitativ gute Datenträger verwenden - kein Billigmist wo ständig Datenfehler produziert
- möglichst auf Storage Libraries setzen, z.B. mit Autoloader (vorzugsweise mit Barcode Methoden auch arbeiten wenn man sehr viele Bänder hat - die Beschriftung alleine ist da nicht immer nur das einzig sinnige Mittel)

Zwecks Expander und Portmultipliern würde ich grundsätzlich sagen "das kommt darauf an" - es gibt da einiges was sehr gut funktioniert abär weniger Durchsatz hat als eine direkte Anbindung pro Port zu je einer HD. Das hängt primär davon ab was man für Hardware hat und in wieweit der Datendurchsatz hier eine Rolle spielt.

Wer auf Nummer Sicher gehen will verzichtet auf solche Dinge einfach ganz und verbindet eine HD jeweils mit einem Port direkt - gerne auch übär Backplanes. Im Zweifel setztz man hier oifach mehrere Controllbären parallel ein - vorzugsweise mit PCIe x8 oder mit PCI-X - je nach Mainboard. Aufpassen ! - wenn man mehr als 2 nutzt da es Fälle gibt wo das technisch zu Problemen führt - also VORHER beim Hersteller informieren wieviele Controllbären der Bärenart jeweils parallel unterstützt werden in einem Brett bzw. in oi OS.

Beste Grüße
Bummibär
 
Zuletzt bearbeitet:
Ergänzung zum Bären. ;)
Folgende Fragestellungen hab ich mir irgendwann mal zusammen gebröselt.

*Grundsätzliches
- Was will ich sichern........
- Wie restore ich das wieder???
- Ermittlung der im Haus verwendeten Schütterapplikationen (z.B. Exchange, DB2, whatever)
- Brauche ich dedizierte Backup Agenten und bietet mir das die ausgewählte Backupsoftware?
- Hat die Applikation schon ein Tool was das Backup vereinfacht? Z.B. Oracle RMAN
- Was bezahlt auch der Kunde?
- Kann der Kunde sich HA leisten?
- Kann ich die Betriebsicherheit gewährleisten?
- Gibt es Herstellersupport, oder muss ich mich auf Mailinglists verlassen?
- Wie ist die SLA?

- Beherrscht auch jemand anders im Haus die evaluierte Backup Methode/Software?
Besonders wichtig wegen Urlaubsplanung (kein Witz)

** Systemwiederherstellung
- ... brauch ich Baremetal?
Oder ist es einfacher ein StandardImage über PXE; Wanboot TFTP, HTTP (whatever) von einem Installserver aufs Blech zu blasen dann den Restore anzuschmeissen?

*Infrastruktur
- Muss ich mit Hitzeproblemen rechnen?
- Hab ich eine USV?
- Sind meine Standorte weit genug auseinander (K Fall) ?
- WIe groß ist das aktuelle Volumen?
- Mit wieviel Wachstum ist in den nächsten 24 Monaten zu rechnen?
- Hab ich ein dediziertes Backupnetz, mit dedizierten Netzwerkswitchen?
- Was mach ich bei einem Ausfall des Backupservers?
- Gibt es einen funktionierenden internen DNS, oder besser mehrere?
wenn nicht liebt der liebe Gott eine sehr gut gepflegte /etc/hosts!


Worauf man besonders achten muss.... gibt es auf den Windows Clients Software die dem verwendete Backup Agenten evtl. in die Suppe spuckt? Z.B. Norton.
Incompleted Backups sind gerade bei Windows Maschinen nicht so ungewöhnlich.

- Wie lange hebe ich Backups auf.... oder wie lange kann ich sie anhand der Infrastruktur und dem ermittelten Wachstum vorhalten?

Sprich Retention Policy
Browsing Policy
Denke immer an den User der vor sechs Monaten ein Excelsheet erstellt hat und es ein Dreiviertel Jahr später nicht mehr findet....


- Testen von Incremental/Differential Backups, für den Katastrophenfall, kriegt man die wieder unfallfrei zusammen?


Archivierung....
- Was muss gesetzlich archiviert werden?
--- Sprich z.B. Geschäftliche Mails
- Wie lange ist die Aufbewahrungszeit?
-- Im Krankenkassenumfeld z.B. 30 Jahre
- Dann muss Centera her...

Das sind alles Punkte die man bedenken sollte, weil man sonst selbst mit einem Fuss im Gefängnis steht, insbesondere der Punkt Archivierung.

Letzte und abschliessende Frage, aber sehr entscheidend:
Ist die Evaluierte Backup Methode wirklich die richtige für alle Fälle, oder entscheide ich mich aus den falschen Gründen für ein Produkt, z.B. Ideologie/Sympathie?

Nur damit ich hier nicht falsch verstanden werde... man kann sich nämlich durch Not invented here Syndrom... oder falsche Motivation ganz schnell für das verkehrte Produkt entscheiden und damit ziemlich schnell auf der Schnauze liegen, wenn es wirklich mal brennt.

Dafür ist eine Planung gerade im Vorfeld mit das vernünftigste was man nicht nur für den Betrieb sondern auch für sich selbst tun kann.
 
Also primär bevorzuge ich Bacula. Am Mittwoch kommt noch ein Consultant der DassIT zu mir ins Büro. Ich erhoffe mir zeitlich schneller vorran zu kommen. Zudem bekomme ich dann eine Schulung sowie sofort in den von mir qualitativ angestrebten Zustand einzusteigen.

Bei Baculasystems habe ich mir Angebote eingeholt. Diese erachte ich aber als lächerlich. Zu hoher Preis und kaum Leistung.

Wenn Bacula nicht in Frage kommt habe ich ein Angebot von Zmanda schon in der Tasche
Zmanda bietet Barmetal-Recovery von MacOSX Linux und Windows. Online Backups von MySQL und PostgreSQL. Backups von Exchange und VMware ESX. Und natürlich auch ein normales Recovery. Die geplante HW wird unterstützt. Also alles was ich brauche. Knackpunkt ist die Backuppen mit TAR. Das überzeugt mich nicht zu 100%

Baulich habe ich einen klimatisierten Serverraum. Der ist auch nach Brandschutzbestimmungen gebaut worden. In dem Raum habe ich einen Spezialtresor für die Bänder der einen gewissen Zeitraum auch sehr schwere Brände überstehen kann. Da aber in dem Raum nichts ist was Brennen kann ist der erst mal nur psychologisch da.

Bacula und Amanda kann ich skalierbar aufbauen. Erst mal die kleine Lösung und weitere Einheiten kann ich dazu stellen.
 
Zuletzt bearbeitet:
Hi,

bärigen Dank an solarix und crest für die Ergänzungen.

Joar, Datensicherheitsschrank mit entsprechende Feuerschutz is natürlich, wie beim Bären au, das Mittel der Wahl wenn`s vor Ort vorgehalten werden soll oder aus irgendwelchen Gründen vorgehalten werden muss.

Bacula ist sicher was wo Du allein hinbekommst mit etwas Einarbeitung. Als wenn Dir das zusagt ist das keine blöde Idee.

Gruß Bummibär
 
minimike schrieb:
Also primär bevorzuge ich Bacula. Am Mittwoch kommt noch ein Consultant der DassIT zu mir ins Büro. Ich erhoffe mir zeitlich schneller vorran zu kommen. Zudem bekomme ich dann eine Schulung

Wenn Bacula nicht in Frage kommt habe ich ein Angebot von Zmanda schon in der Tasche
Zmanda bietet Barmetal-Recovery von MacOSX Linux und Windows. Online Backups von MySQL und PostgreSQL. Backups von Exchange und VMware ESX. Und natürlich auch ein normales Recovery. Die geplante HW wird unterstützt. Also alles was ich brauche. Knackpunkt ist die Backuppen mit TAR. Das überzeugt mich nicht zu 100%

.
Zum Vergrößern anklicken....
Backup mit TAR ist nichts verkehrtes, im Gegenteil, selbst Veritas Netbackup benutzt selbst intern TAR. D.h du kriegst den Kram im Zweifelsfall ohne
Client rausgeblasen. Ganz im Gegensatz zum Beispiel zu Legato Networker, der das Open
Tape Format benutzt, dafuer aber andere Vorteile hat.
An Deiner Stelle wuerde ich mir noch Angebote von EMC fuer Legato einholen oder von Veritas fuer Netbackup.
Allein schon aus dem Grund das deine Vergleichsmoeglickeiten besser sind.
Und Du im Zweifelsfall noch mal an der Preisschraube drehen kannst.
Eins noch.. Lass Dir den Baremetal Kram praktisch demonstrieren. Es gibt genuegen Helden die behaupten das ihr Zeug das kann und praktisch dann voll auf
Die Nase fallen, selbst schon erlebt bei der Wiederherstellung eines Solaris Clusters.
 
hi

ich wuerde mir auch 2x ueberlegen 2 backup loesungen haben zu wollen.
der aufwand ist zeitlich und personell nicht unerheblich.

holger
 
Wiso? Eine Software die doppelt sichert. Primär auf Platte und sekundär auf Band. Die Daten habe ich dann garantiert verfügbar. Geht mir neben der Infrastruktur auch der Backupserver flöten kann ich das alles von Band aus dem Safe wieder zurückspielen. Und ist die gesammte HW schrott z.B. durch Brand oder Sprinkleranlage kann ich das notwendigste auch schnell wo kaufen gehen. Natürlich werde ich noch für den Fall der Fälle ein paar USB-Sticks kaufen und vorbereiten um die Backuplösung mit minimalen Aufwand reinitialisieren zu können.
 
Zuletzt bearbeitet:
minimike schrieb:
Wiso? Eine Software die doppelt sichert. Primär auf Platte und sekundär auf Band. Die Daten habe ich dann garantiert verfügbar. Geht mir neben der Infrastruktur auch der Backupserver flöten kann ich das alles von Band aus dem Safe wieder zurückspielen. Und ist die gesammte HW schrott z.B. durch Brand oder Sprinkleranlage kann ich das notwendigste auch schnell wo kaufen gehen. Natürlich werde ich noch für den Fall der Fälle ein paar USB-Sticks kaufen und vorbereiten um die Backuplösung mit minimalen Aufwand reinitialisieren zu können.
Zum Vergrößern anklicken....

moin

das geht mit bacula .

man dort auch nur normal "dateien" kopieren so das sie nur auf einer seperate
platte liegen .

es ist generell egal welches medium du verwenderst solange der storage daemon von bacula laeuft . ( nur bei bandlaufenwerken muss man auf
kompatiblietaet achten ).

holger
 
mark05 schrieb:
moin

das geht mit bacula .

man dort auch nur normal "dateien" kopieren so das sie nur auf einer seperate
platte liegen .

es ist generell egal welches medium du verwenderst solange der storage daemon von bacula laeuft . ( nur bei bandlaufenwerken muss man auf
kompatiblietaet achten ).

holger
Zum Vergrößern anklicken....

Das kann jede bessere Backupsoftware, die Backupsoftwarehersteller würden ja ein trauriges Bild abgeben, wenn die das nicht könnten.
Abgesehen davon. das Problem der Kompatibilität hast ja überall. Meistens wird da gerade
bei Storage, oder Tape Libraries auf die üblichen verdächtigen optimiert.

Z.B. Storagetek, Exabyte, HP, Quantum, Tandberg und I'll Be Mental.

Aber ich würde mir halt ernsthaft überlegen wenn ich schon etwas neu aufbaue, welche Seuche ich mir ins Haus hole, gemeinhin ist es ja so das jede Backupsoftware ihre Zicken hat, und man sich da genau ankucken sollte welche Krankheit will ich haben.
Außerdem ist das ganze immer eine sehr sehr langfristige Entscheidung.
Auch im Hinblick auf die Plattform, Bacula an sich läuft ja ziemlich locke flockig auf Linux und FreeBSD. Unter OpenSolaris hab ich auch mal einen Bacula Server aufgebaut, der auch sehr zuverlässig läuft, den SUNW.gds Agenten für Bacula zu bauen war auch nicht der Stress. Das ganze schwenkt und tut seinen Job. Aber gerade bei Exchange Sicherungen
müsste mir noch einer zeigen das es da einen brauchbaren Agent gibt.
Wobei das bauen des Clients für Mac OS auch recht gut ging.
Nervig am Bacula fand ich nur die Definition der Filesets/Savesets.
Dort sind andere wirklich nen ganzen Zacken weiter.

Beim TSM fand ich es immer anstrengend das der Client praktisch auf dem Client konfiguriert wird und nicht im Backup Server selbst.

Bacula und Legato gehen praktisch den anderen Weg. Allerdings kann man beim Legato auch am Anfang Verständnisprobleme haben, bis man schnallt das der gesamte Backupvorgang über den Scheduler konfiguriert wird und nicht über die Gruppen, was ja an sich logischer wäre.

SEP Sesam wäre ja auch noch eine Alternative die man sich ankucken könnte.

Abgesehen davon sind die Lizenzmodelle gerade bei den Großen Drei, extrem anstrengend.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben