monstermania

Sehe ich ähnlich wie zahni. Egal welche AV-Software man auf dem Client einsetzt sollte man nicht Allzuviel vertrauen in die Erkennung aktueller (akuter) Bedrohungen haben. Je nach Bedrohungslage hat mal Produkt A oder Produkt B die Nase vorn! So etwas ist aber immer nur eine Momentaufnahme und kann keinesfalls Verallgemeinert werden. Wir nutzen hier Gdata Business auf den Clients und nur damit wären wir bisher bei akuten Email-Ransomwellen auf die Nase gefallen, da es einfach immer einige Stunden dauert, bis die Hersteller aktuelle Signaturen für Ihre Produkte nachliefen, die auch die neuesten Trojaner erkennen. Das lässt sich immer wunderschön an der Statistik der UTM / Mailgateway ablsesen. Neue Welle -> zunächst landen viele Mails in der Quarantäne -> nach einigen Minuten/Stunden -> gleichartige Mails werden von UTM oder Mailgateway bereits abgewiesen. Wir setzten daher auf eine Kombination mehrer Produkte/Strategien: - Spam- und AV-Filter auf der UTM - Downloadsperren für bestimmte Dateitypen auf der UTM - GData Mailsecurity-Gateway (ist seitens GData leider abgekündigt) - Transportregeln für Exchange -> Quaratänepostfach für Mails mit bestimmten Dateitypen/Kriterien - Mitarbeiterschulung/Mitarbeitersensibilisierung - GData Business auf den Clients - SRP (läuft noch in der Testphase) Insgesamt sind wir damit recht erfolgreich. Spamaufkommen für die User absolut minimal bzw. kaum vorhanden. Einmal am Tag ein Blick in die Quarantäne wo etwa 2-3 false Positives pro Woche auflaufen. Bisher kein einziger Trojaner- bzw Ransomwarebefall der durch eine Email ausgelöst wurde. Der GData auf den Clients hat schon seit Wochen keinen einzigen Alarm mehr ausgelöst. Insgesamt würde ich bei der Auswahl einer AV-Lösung für das Unternehmen insbesondere auf die zentrale Installation, Verwaltung und Konfiguration der Clients besonderen Wert legen. Es gibt einfach im AV-Berech nicht das ultimative Produkt!

Moin, ergänzend noch dazu die Frage an die GF/Abteilungsleiter stellen für welchen Zeitraum Backups der Daten vorgehalten werden müssen. Ein Vorhaltedauer von 3 Wochen halte ich z.B. für ein absolutes Minimum um auch mal einen normalen 2 Wöchigen Urlaub überbrücken zu können. Offsite-Backup!? Gruß Dirk

@dwelt Ich empfehle unbedingt zu Prüfen, ob ggf. auch ein MS Office-Paket benötigt wird! Aus meiner Vergangenheit weiß ich, dass diverse ERP-Lösungen ein MS Office-Paket voraussetzten (z.B. Excel, Outlook) um Mailversand zu machen oder Berichte zu exportieren. Wenn das ERP-System auf einem RDP-Server läuft, muss auch zwangsläufig das verbundene MS Office auf dem RDP-Server laufen. So etwas kann leicht zum Showstopper werden. MS Office auf einem RDP-Server müssen zwingend Volumenlizenzen/Office365 sein!

Du zäumst das Pferd falsch herum auf. ;) Nehmen wir einmal an, Ihr habt Eure 100TB Daten und auch eine Sicherung dafür. Nun tritt der Worst-Case Fall ein und Ihr müsst ein komplettes Disaster-Recovery machen. Wie lange darf es dauern, bis alle Daten wieder hergestellt sind!? 100 TB ist schon nicht so wenig, wenn man z.B. ein DR-Fenster von 24 Std. annimmt! Wie sieht es bezüglich eines Offsite-Backups aus!? Die richtige Software + Hardware für die Umsetzung des Backup/Restore-Konzepts ist das kleinste Problem, wenn das Konzept denn steht.

Jo, den https://regex101.com/ nutze ich auch gern. Lieder gerade im Microsoft-Umfeld nicht immer die 1. Wahl, da MS doch eine sehr eigene Regex-Syntax hat. Wenn ich etwas mit MS-Code nutzeich eigentlich immer: http://regexstorm.net/tester Der berücksichtigt auch die "MS-Specials" ;)

z.B. in einem Archivierungsysstem mit revisionssicheren Jahresarchiven. Da können dann nach nachdem das Jahresarchiv Revisionssicher gemacht wurde keine Altdaten gelöscht/geändert werden. Nichtsdestotrotz möchte man diese Archivdaten natürlich für ein Offsite-Langzeitbackup bereitstellen. Und wenn der Prozess vorsieht, das einmal im Jahr alle Altarchive einmalig auf das jeweils aktuelle Langzeitmedium gesichert werden kommt man halt auf ein regelmäßiges, Einmaliges Archivbackup. Ist Übrigens in diversen Teilbereichen durchaus normal, dass Dokumentationen über einen Zeitraum von 20 oder gar mehr Jahren aufgehoben werden müssen. Ich habe schon mit Schiffsausrüstern zusammen gearbeitet, wo wir deren technische Dokumentation der letzten 40 Jahre nach Bedarf von Papier in ein DMS überführt haben. Einfach weil diverse Anlagen über einen solch langen Zeitraum genutzt werden. Inzwischen blicken die Kunden selbst auf eine über 20 jährige Historie der elektronischen Archivierung zurück! Wenn ich allein schon daran denke, wie häufig sich die Medien für Lanzgeitarchivierungen in den letzten Jahren geändert haben (WORM, DAT, DLT, LTO) :rolleyes:

Das ist kein Widerspruch... :D Wer sich z.B. mit der Haltbarkeit von Bändern auskennt, weiß, dass Bänder z.B. entsprechend gelagert werden müssen um die Haltbarkeit seitens der Medienhersteller zu gewährleisten. Auch können sich z.B. durch neue Technologien die Anforderungen ergeben die Langzeit-Datensicherung regelmäßig auf Medien einer neuen Technologie zu übertragen (z.B. Platzeinsparung, oder Sicherstellung, dass im Unternehmen auch noch die entsprechenden Laufwerke zum einlesen der Backupmedien verfügbar ist, usw.). Eine Regelmäßigkeit ergibt sich ja bereits, wenn z.B. einmal im Jahr eine Sicherung der Archivdaten erfolgt. ;)

Moin, m.E. min. genau so wichtig wie die Frage zu stellen, wie solche Datenmengen gesichert werden ist die Frage wie die Datenmenge im Fehlerfall Wiederhergestellt werden kann. Die Beste Sicherung nutzt ja nichts, wenn eine Wiederherstellung einige Tage dauert, die Daten aber in Stunden benötigt werden. Wenn ich lese, dass die Daten als Backup auf einem NAS liegen, frage ich mich immer sofort, was ist mit einem Offsite bzw. Offline-Backup!? Auch kommst Du bei solchen Datenmengen locker den Bereich der natürlichen Bitfehlerrate einer üblichen HDD. Ohne ein entsprechend fehlertolerantes Filesystem auf den NAS (btfrs) würde ich da graue Haare bekommen... Aber ohne die Art der Daten zu kennen, ist es ein reines gestochere im Nebel und bringt weder Dir noch uns etwas. Ein große Datenmenge an sich bedeutet ja nicht Zwangsläufig dass jeden Tag eine große Datenmenge gesichert werden muss. Möglicherweise handelt es sich ja um reine Archivdaten, die zwar zum Zugriff bereit stehen müssen, aber sich gar nicht täglich ändern, so dass z.b. eine regelmäßige einmalige Sicherung vollkommen ausreichend ist. Gruß Dirk

Moin, bei einigen Firewalls gibt es die Möglichkeit WOL über die Firewall selbst zu machen. Ansonsten bliebe noch die Möglichkeit ein WOL über ein dauerhaft laufendes System im Netzwerk auslösen. Läuft z.B. eine Überwachung wie Nagios oder Zabbix könnte man z.B. darüber ein WOL initieren. Der User würde sich nach der VPN-Einwahl dann an der Oberfläche des Systems anmelden (Webbrowser) und kann dann seinen Rechner per WOL starten. Oder der User meldet sich einfach auf einem Windows Server im Netzwerk an, auf dem ein WOL-Tool läuft... Gruß Dirk

Kann den Kollegen nur beipflichten. War bei unserem Audit 2015 ganz ähnlich. Wichtig war, dass wir glaubhaft belegen konnten, dass die betreffenden VM's nicht häufiger als einmal alle 90 Tage zwischen den Hosts verschoben haben. Also unbedingt die Logs aufbewahren!

Wie das verkleinern des VDMK geht, weiß der TO offenbar! Hat er jedenfall in seinem Eingangspost geschrieben.

@Bill Mustermann Ja, wir reden wohl irgendwie aneinander vorbei. ;) Logischerweise muss der Backupserver auf einem Server bzw. OS laufen. Und klar, auch der Backupserver kann mal kaputt gehen oder nicht mehr booten. Aber das hat dann ja noch keine unmittelbaren Auswirkungen auf die Produktivumgebung der Firma! Wäre natürlich b***d, wenn man just in diesem Augenblick einige Daten vom Backup benötigt. Grundsätzlich aber bereits wie mehrfach hier geschrieben: Backupserver neu installieren und Restore der Backupserver-Konfiguration einspielen. Die Backupssysteme haben ja heute eigentlich alle eine Datenbank, die natürlich auch regelmäßig gesichert werden sollte! Ob ein Backupserver nun selbst gesichert werden sollte!? Ansichtssache. Ich sehe bei uns keine Notwendigkeit dafür. Dann müßte ich ja auch einen 2. Backupserver StandBy haben, damit ich bei einem HW-defekt sofort reagieren könnte...

Ich habe mit der Software gparted gute Erfahrungen gemacht. Nicht umsonst liegt das gparted.iso bei uns auf dem VMWare Host. ;) Grundsätzlich würde ich bei solch tiefgreifenden Änderungen immer zuvor ein Backup der VM machen!!! PS: Ein Snapshot ist kein Backup!

Hmm, das verstehe ich nicht so recht!? Wenn Backupinfrastruktur und Echtsystem auf getrennter HW laufen, kann genau so etwas nicht passieren! Oder habt Ihr Euren Backupserver auch auf Eurem Echtsystem laufen lassen? Ist ja inzwischen einige Male geschrieben wurden, dass Backup/Echtsystem getrennt betrieben gehören (möglichst auch räumlich getrennt)! Ansonsten hast Du ein typisches Henne, Ei-Problem :D

@all Danke Nein, PS ist keine Option (zumindest noch nicht :rolleyes: ). Kurz zur Erklärung was das Script macht bzw. machen soll. Ein Prüfstand erzeugt Protokolle (Diagramm als PDF- und Messwerte als CSV-Dateien). Diese werden vom Prüfstand automatisch in einem Ordner abgelegt. Aufgabe ist, für jedes Protokoll ein Formular (PDF) zu erzeugen, was an den Kunden geschickt wird. Dazu wird eine Word-Fomularvorlage mit den Werten aus der CSV-Datei und einem ERP-System (SQL-db) verknüpft/gefüllt und als Endabnahmeprotokoll als PDF gespeichert bzw. gedruckt. Mein eigentliches Problem war ja schlichtweg die Anzahl der CSV-Dateien im Ordner. Jeder Durchlauf des Scripts durch den Ordner braucht(e) mehr als 10 Minuten und dann kam im schlimmsten Fall gar nichts heraus, weil seit dem letzten Durchlauf gar keine neuen Prüfstandtests gemacht wurden! Und außerdem hat es immer mindestens die Zeit gebraucht, bis wieder ein Durchlauf gestartet werden kann... Eine "Lösung" für mein Problem zu finden war recht einfach. Ein simples 'xcopy quelle ziel /d:mm-dd-yyyy /y' im Script kopiert alle csv-Dateien => dem aktuellen Datum in ein Importverzeichnis. Das sind dann nur wenige Dateien am Tag. Darauf läuft dann erste meine VBS-Programmierung los. Da die verarbeiteten CSV-Dateien anschließend eh in einer Datenbank erfasst werden, ist es kein Problem die bereits beim letzten Durchlauf verarbeiteten CSV-Dateien aus dem Importordner zu löschen, ohne das ein Endabnahmeprotokoll erzeugt wird. Vielleicht nicht unbedingt die eleganteste Lösung, aber zumindest eine ohne viel Aufwand. :D Insgesamt braucht das Script jetzt nur ein paar Sekunden...

Folgendes Problem. In einem Ordner befinden sich rund 9000 CSV-Dateien (Anzahl weiter steigend). Ich will nur all die CSV-Dateien herausfinden, die in der letzten Stunde neu erstellt wurden. An sich kein Problem, aber durch die schiere Anzahl der Dateien im Ordner wird es so langsam zu einem Problem. Bereits jetzt benötigt ein Durchlauf über 10 Minuten. Das Problem, ist, dass das Script halt jede Datei im Order prüfen muss... For Each sFile In sFolder.Files Gibt es eine Möglichkeit per VBS die Dateien nach Datum vorzufiltern, so dass z.B. nur Dateien überprüft werden, die z.B. aus dem aktuellen Jahr sind? Gruß Dirk

@Gadget Als jahrelanger treuer "Kunde" bzw. Nutzer von BE kann ich Dir teilweise zustimmen. Ja, Backup Exec ist bzw. war nicht schlecht, hat aber als die Virtualsierung auch und immer mehr in den KMU-Bereich gekommen ist schlichtweg den Anschluss verloren. Ich würde heute wohl in keinem Projekt noch auf BE setzten. Dafür ist z.B. ein Produkt wie Veeam einfach zu stark! Wo BE traditionell extrem stark ist, ist der gesamte Tape-Bereich! Aber auch das wird immer weniger wichtig, da heutzutage i.d.R. B2D gemacht wird. B2T dient eigentlich nur noch zur Langzeitarchivierung bzw. Backup des B2D (B2D>B2T). Ich kann man gar nicht mehr darin erinnern, wann ich zuletzt mal ein Tape für ein Restore wirklich gebraucht habe (außer den regelmäßigen Testwiederherstellungen von Tape!). Das B2D bzw. der hat für ein Restore bisher immer gereicht.

Ich schreib jetzt mal folgendes: Du musst vom Restore her denken. ;) Alles Weitere ergibt sich aus den Anforderungen an die Datenwiederherstellung den das Unternehmen stellt. Beispiel: Wenn dass Unternehmen verlangt, dass Daten alle Daten der letzen 3 Monate jederzeit innerhalb von 4 Stunden wiederhergestellt werden müssen, dann muss der Backup-/Restoreprozess entsprechend darauf ausgerichtet werden. Je nach Anfordrungen muss dann eben auch das Backup redundant ausgelegt sein! Optimalerweise ist die Produktiv- und Backup-Infrastruktur eines Unternehmens in 2. Brandabschnitte unterteilt. Gibt es im Produktivbereich (Serverraum) einen Brandschaden, so ist idealerweise das Backup davon nicht betroffen. Gilt genau so umgekehrt. Und es braucht ein entsprechendes Offsite-Backup. Also ein Backup, dass regelmäßig komplett außerhalb der Firma gelagert wird, um z.B. bei einem kompletten Firmenabbrand alle Daten wieder herstellen zu können. Ob mehrere DC sinnvoll sind hängt von der Komplexität der Infrastruktur ab. Es kann durchaus schon Sinn machen bei 2 pysikalischen Servern auch 2 DC zu betreiben. Immerhin ist so bei einem Ausfall 1 Servers sichergestellt, dass sich alle User noch an der Domäne anmelden können und zumindest noch teilweise gearbeitet werden kann. On das Bei Di/Euch sinnvoll ist, kannst nur Du beantworten!

Hmm, mit konkreten Prozentangaben zur Verfügbarkeit wäre ich immer sehr, sehr vorsichtig. :cool: Mal so als Praxisbeispiel: An einem Samstag im April plant der örtliche Energieversorger hier eine Wartung an einer Trafostation im Gewerbegebiet. Geplanter Stromausfall für ca. 4 Stunden. Das bedeutet, dass wir unsere IT-Anlage komplett herunterfahren werden (geplant). Bis dann später Alles wieder läuft kann man noch ca. 2 Stunden dazu geben. Damit wären wir dann schon dran an den 99.95%-Verfügbarkeit für 2017, ohne das die IT überhaupt etwas dafür bzw. dagegen machen könnte (Doch: Notstromdiesel) :D Echte Hochverfügbarkeit ist für die meisten KMU schlichtweg aus Kostengründen nicht realisierbar und es läuft zumeist auf eine 'höchstmögliche' Verfügbarkeit im Rahmen des Budgets hinaus. Von daher kostet schon eine 98-99%ige Lösung ganz schön Geld, wobei der Kostenaufwand noch überschaubar bleibt. Bei jedem %-chen darüber steigen Kosten/Aufwand expotentiell an. Ansonsten kann ich Nils nur voll zustimmen. Haben wir genau so gemacht. Die GF konnte sich dann die kostenmäßig passende Lösung heraussuchen und kennt auch die Risiken die sich daraus ergeben.

a. Ja, aber der TO hat ganz klar von einem 300€ NAS geschrieben. Damit dürfte er wohl kaum Geräte von HP, Dell, oder einem sonstigen Enterprise-Hersteller gemeint haben. ;) b. Gibt es durchaus auch Geräte von QNAP/Synology die durchaus gewisse Enterprise-Qualitäten bzw. Fähigkeiten haben. Aber auch beginnen die Preise für ein NAS ohne Platten etwa um den Faktor 10 über den bereits genannten 300€. c. Halte ich auch von diesen "Enterprise-NAS" (siehe b) nicht allzuviel. AFAIK nach bietet kein DL diese "Enterprise"-Geräte inkl. einem entsprechendem Service an (z.B. Mission Critical 4h Vor Ort). Da lass ich mich allerdings gerne eines Besseren belehren. d. Ist FreeNas eine feine Lösung. Aber eben auch nur, wenn eine entsprechende Hardware darunter hängt. Ich kann mir ein FreeNas NAS für ein paar Hundert-Euro zusammen schustern. Ob so etwas dann im Ernstfall stabiler/besser ist als ein 'fertiges' NAS von Synology/QNAP der 300€ Klasse sei mal dahingestellt. Jeder wie er mag. Für mich gehört zu einer "Enterprise"-Hardware immer auch ein entsprechender Wartungsvertrag, der die Wichtigkeit der Systeme wiederspiegelt. PS: Wir haben hier selbst im Unternehmen 2 QNAP NAS in aktiver Nutzung. Funktionieren einwandfrei auch als VMWare Datastore (fürs Testlab). Liegen aber halt keine wichtigen Daten drauf.

Puuh, mir würde Angst und Bange werden bei so etwas! Unter 10% freien Speicher auf einem LUN würde ich als extrem kritisch einstufen. Das wären bei Deiner Konstellation 200GB. Und selbst das kann im Einzelfall viel zu zu wenig sein! Ich habe es selbst schon erleben dürfen, dass eine LUN während des Veeam-Backups 'vollgelaufen' ist. Einfach, weil der Admin vom SQL-Server eine db-Reorganisation während des Veeam-Backups hat laufen lassen! Dann stehen alle VM's, die auf dem LUN laufen. Die Frage ist natürlich auch, wie die VM's konfiguriert sind (Thin, Thick)? Ist natürlich extrem Kontraproduktiv, wenn z.B. jede VM pauschal 100GB Speicher bekommt, obwohl u.U. nur 40-50 GB tatsächlich belegt sind. Zum Thema NAS: Ja, so ein NAS (QNAP, Synology) lässt sich prima als Datenspeicher für VM-Hosts nutzen. Nur, spielt man da mit seinen Daten Russisch-Roulette! Ich würde niemals produktionskritische Daten einem NAS anvertrauen. Dazu muss man nur mal in die Foren gucken.

Hmm, wirf doch einfach einen Blick in das entsprechende Whitepaper von Symantec. http://www.symantec.com/content/en/us/enterprise/white_papers/backup-exec-15-exchange-en.pdf

@bill_mustermann Genau aus diesen Gründen sollte man keine produktiven Daten auf einem Synology NAS laufen lassen! ;) http://www.mcseboard.de/topic/209500-storage-f%C3%BCr-vmware-nas/ Ansonsten kann ich Norbert nur zustimmen. Hochverfügbarkeit ist mehr als nur etwas Hard- und Softwareware. Ohne richtige Auslegung der gesamten IT-Infrastruktur ist Hochverfügbarkeit nicht erreichbar. Dazu gehört neben kompletter Redundanz der Hardware auch die komplette räumliche Trennung in unterschiedliche Brandabschnitte/Stromversorgung, usw.

Hmm, hast Du geprüft, ob der reguläre Ausdruck richtig funktioniert? Ich prüfe meine das zunächst mal mit einem externen Testprogramm: http://regexstorm.net/tester Gruß Dirk

Ja, gibt es. In der c't Nr. 17 aus 2014 war ein Artikel, wie man von einem bestehenden Rechner ein Image zieht (wim). Geht komplett mit Windows Bordmitteln. Habe das Szenario bereits öfters genutzt um bestehende Rechner auf eine SSD zu imagen.