Hallo Gemeinde

Ich beschäftige mich zur Zeit mit BackupExec 2010 und bin nun auf der Suche nach Informationen zur Vorbereitung der Servers auf dem BackupExec 2010 installiert werden soll.

Auf dem Server wird ja SQL Expresss SP3 installiert.
Ist es ratsam wie für einen "vollwertigen" SQL Server auch 4 Disks einzurichten?

1 Platte für System
1 Platte für DB
1 Platte für Log´s
1 Platte für SQL Backup

Der Server wird virtualisiert (vSphere4) installiert.
Die Platten auf denen dann die Backups von BackupExec draufkommen werden mit iSCSI angehängt.

Habe im Internet keine Infos über ein "Best Practice" zu diesem Thema gefunden.

Könnt Ihr mir da weiterhelfen?
Habt Ihr mir Links zu diesem Thema oder Tipps aus der Praxis (wäre natürlich noch besser)

Ich danke Euch jetzt schon.


Grüässli rosco

Bin jetzt nicht sicher, ob ich Dich richtig verstanden habe: der BackupExec-Server wird virtualisiert? Wozu?

Der SQL-Server hat bei BackupExec eher eine untergeordnete Rolle was die Performance anbelangt. Wichtig sind Datendurchsatz übers Netzwerk. Auf dem SQL werden "nur" Medieninformationen und Logs gespeichert.

Er wird virtualisiert, da hier die ganze Serverumgebung auf Blade-Systemen virtualisiert läuft.

Also reicht es wenn ich den Server so aufbaue:

1 Platte System
1 Platte DB/Logs

Backup der DB direkt auf einen iSCSI Folder.

Verstehe ich das so richtig?

Ich hoffe ihr habt mindestens zwei voneinander getrennte Serverräume. Anonsten hast du ja im Fall eines Servercrashes (Hardware) dann auch keinen Backup Server mehr?
Oder sind die iSCSI Platten im selben Raum wie alles andere auch? Dann hast du z.B. bei einem Brand- oder Wasserschaden gar nichts mehr.
Es gibt also gute Gründe gerade den Backup Server nicht zu virtualisieren.

Meines erachtens reicht es, wenn du den SQL Express auf die gleiche Platte installierst wie die Backupsoftware.

In einer High Performance Umgebung wo man sich Gedanken über sowas machen müsste würde man wohl auch eher NetBackup einsetzten.

Gruss

Das mit dem Virtualisieren des Backup Servers ist so eine Sache. Eignetlich ist es kein Problem, jedoch ist der I/O sehr hoch und meist nicht zu empfehlen wenn er Virtuell ist. Wichtig ist einfach noch, dass du die Datenbank mit auf das Backupmedium schreibst, sonst wirdst du sehr lange haben um bei einem Crash alles wieder zugreifbar zu machen...

Und ich hoffe dass Ihr die Backups irgendwo anders lagert... Bsp: 2x Datadomain DD610 (B2D mit Dedub beim Schreiben) eine lokal im Serverraum und ein in einem Entfernten RZ oder in einem Entfernten Gebäude... (so machen wir das)

Grüsse

IncSys

Ich kann da meine Vorschreibern nur bei pflichten ich würde Backupexec auf einer physischen Hardware installieren. In der Version 2010 gibt es nette Agenten für die Vitalisierung. Weiter würde ich den Systemstate auch nicht über Symantec sichern lassen, bei meinen Installation brach immer wieder der Durchsatz zusammen, ich habe den Systemstate dann via vbadmin gelöst.

Hallo Leute

Ich kann Euch beruhigen...
Wir haben je 2 Gebäudetechnisch getrennte Serverräume an 3 Standorten.

Die Daten werden nicht im selben Raum gebackupt in dem die Server laufen.
Die Räume sind über LWL miteinander verbunden.

Aber aus "politischen" Gründen sind bei uns 3 BackupExec Server nötig.
Einen pro Standort.

Es ist aber gut vorstellbar das die 3 BackupExec Server in Zukunft (ca. 2-3 Jahren) über einen Management Server zusammengeschlossen werden.

Daher möchte ich jetzt schon vorarbeiten und an jedem Standort die Backup´s in etwa gleich einrichten.

Und das mit dem Gebäude abbrennen... dafür ist vorgesorgt. Jeder Standort kann die Dienste / Last (was Informatik angeht) tragen und zu Verfügung stellen.
Virtualisierung sei Dank .-)



Grüässli rosco

Schliesse mich da Schubo an. SQL auf selbe Disk wie OS und BE. Abgesehen davon: Wenn Du virtualisierst, wirst Du ja wohl kaum fixe Disks zuordnen sondern irgend ein LUN auf einem SAN, oder?
Ich sehe keinen vernünftigen Grund, BE zu virtualiseren. Es braucht riesen IO-Durchsatz und belastet so das System unnötig. Wenn schon professionell, dann direkt vom Storage backupen.