Jump to content

monstermania

Members
  • Gesamte Inhalte

    1.393
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von monstermania

  1. Moin, auch wenn ich nicht DOSO bin will ich nochmal meinen Senf dazugeben. Von welchen Datenmengen gehst Du bei der Archivierung aus? Werden die Daten sauber nach Zeiträumen getrennt, so dass Du z.B. einzelne Jahre gezielt Langzeitarchivieren kannst? Sind alle Daten in der Datenbank enthalten, oder werden in er Datenbank nur Indexinformationen gespeichert und die eigentlichen Dokumente in einer separaten Dateistruktur? Habt Ihr gesetzliche Voraussetzungen für die Langzeitarchivierung zu erfüllen (z.B. Aufbewarungszeitraum)? Tape ist kein WORM Medium!!! Je nach Vorgaben, kann eine Langzeitarchivierung extrem komplex werden Dann nochmal zur QNAP Was verstehst Du unter einer QNAP aus dem HighEnd-Segement? Klar, QNAP stellt auch Enterprise-Lösungen her. Ich kann nur davor warnen eine QNAP aus dem SOHO-Bereich (z.B. Serie x69Pro) mit wichtigen Produktivdaten zu betreiben! Passiert immer mal wieder, dass sich der RAID-Verbund eines solchen QNAP verabschiedet. Einfach mal im QNAP-Forum umsehen. Und dann sind die Daten weg! Als Backupspeicher ist eine QNAP ganz OK. Aber wirklich wichtige Daten würde ich lieber auf einem Medium speichern, was z.B. eine mehrjährige Herstellergarantie hat! Gruß Dirk
  2. Moin, man soll einen SQL-Server nicht auf einem DC installieren. Das ist richtig. Man kann das aber sehr wohl machen! MS lieferte mit dem SBS sogar ein System wo DC, Exchange und SQL auf einem System liefen! Grundsätzlich würde ich ein SOHO NAS (QNAP) nicht für ein produktiv genutztes Storage einsetzen. Als Testlab mag das OK sein. Pack in Deinen Server ein lokales RAID-System mit Hot-Spare (SAS). Und natürlich einen echten Raid-Controller mit Cache und BBU. Eine QNAP kannst Du dann Prima für das Backup nutzen. Dafür reicht dann je nach Datenmenge auch ein 2 Platten-NAS (RAID-1). Offside Backup kannst Du dann mit externen USB-Platten realisieren (Copy2USB). Was meinst Du mit Archivierung? 10 Jahre ist eine lange Zeit! Gerade in der IT sind das Welten. Um was für Daten die archiviert werden müssen handelt es sich? Gruß Dirk
  3. Moin, ich finde die Anzahl der DC in einem Unternehmen hat nichts mit Virtualisierung zu tun, sondern ausschließlich mit der Größe bzw. den Anforderungen. Bei den klassischen SBS Kunden gab/gibt es i.d.R. nur den 1 Server. Ob dieser nun virtuell oder native läuft ist völlig egal. Bei einem Hardwaredefekt geht so oder so nichts mehr! Ich habe seit 2010 keine nativen Installationen bei Kunden mehr gemacht bzw. an Kunden ausgeliefert. Der SBS lief immer auf einem ESXi Hypervisor. Ist einfach ein großer Administrativer Vorteil, da ein Hardwaretausch extrem vereinfacht wird. Bei größeren Kunden stellt sich die Frage nach mehreren DC gar nicht, da es eh immer mehrere gibt. Ob diese dann native oder virtuell laufen kommt dann wieder auf die örtlichen Voraussetzungen an bzw. ist auch eine Glaubensfrage der Admins :). Bei uns laufen alle DC virtuell. Allerdings läuft ein DC auf dem lokalen Storage eines VMHosts (RAID1). Alle anderen DC laufen auf dem SAN. Dieser Host ist auch der einzige mit lokalen Platten. Die anderen Hosts sind ohne Platten und starten VMWare per SD-Karte. Damit ist sichergestellt, dass im Falle eines totalen Crash des SAN zumindest die Anmeldedienste noch laufen. Dann könnten die Mitarbeiter zumindest noch im Internet surfen. :) Gruß Dirk PS: Ach ja, wenn das SAN crasht müsste ich wohl meinen Urlaub abbrechen. Da nutzt der evtl. laufende DC dann auch nichts...
  4. Moin, ich würde mir den Einsatz der Windows Faxserverrolle sparen. Funktioniert nur noch absolut rudimänter! Für Microsoft spielt Fax keine große Rolle mehr, daher wurde der Faxserver nur sehr halbherzig auf 64 Bit portiert. Gerade im Zusammenhang mit der Nutzung der Telefonbücher eines Clients (z.B. Outlook) und des Faxservers gibt es massive Probleme. Der Zugriff auf die Adressbücher funktioniert nur, wenn der Client sowohl ein 64 Bit OS hat und auch das Office 64 Bit ist! Wir setzten hier GFI FaxMaker ein. Übrigens auch unter VMWare mit einem Bintec. Gruß Dirk
  5. Moin, Moin, ich gehe mal davon aus, dass es sich bei den Platten im Fujitsu SAN um NL-SAS gehandelt hat. Insgesamt kann an den Werten ganz gut den Performance-Unterschied zwischen echten SAS und NL-SAS ablesen. Man muss natürlich dabei beachten, dass das IBM SAN doppelt so viele Spindeln hatte wie dass Fujitsu SAN. Inwieweit solche Benchmarks generell vergleichbar sind lasse ich mal außen vor. Aber eine Tendenz ist zumindest gut erkennbar. Gruß Dirk
  6. Hmmm, bei VMWare sind 6 LAN Ports pro Host für HA Best Practice... Was bei MS Besteht Pratice ist?
  7. z.B. Lizenzen für MS Office
  8. Sorry, aber HA bezieht sich i.d.R. auf die Server. Eine Hochverfügbarkeitslösung auch noch für die Clients dürfte wohl bei den meisten Kunden das Budget sprengen. Allein um ein komplettes Unternehmen gegen Strohmausfall zu schützen. Und das wäre ja zumindest der 1. Schritt... Gruß Dirk
  9. Moin, also ein Testlab ist für die Ermittlung der IOPS m.E. nicht gerade Aussagefähig. Schließlich ist auf einem Testlab normalerweise kaum Last. Deine Modellrechnung mit 250 IOPS halte ich schon für ganz OK. Darauf kannst Du auf jedem Fall aufbauen. Solltest Du doch langsam dazulernen!? :) Mal als Beispiel aus der Praxis. Wir haben bei 3 Hosts mit ca. 30 VM's und ca. 50 Usern rund 1000 IOPS last. Und ja, das sind Werte, die im Echtbetrieb ermittelt wurden (Exchange 2007, mehrere SQL2005/2008/2012, usw.). Unser Storage hat aber deutlich mehr Luft als die 20% die Du aufgeschlagen hast. Einfach weil wir damit die nächsten Jahre auskommen wollen. Gruß Dirk
  10. Meinst Du das im Ernst? Wie lange bis Du im IT Bereich tätig? Tape Autoloader sind ja nun so was von Retro, die gab es schon zu meinen Anfangszeiten in der IT. Und das ist mir Verlaub gesagt schon etwas her. :rolleyes: Ach ja, wenn Du Veeam Backups auf BAN speicherst kannst Du ausschließlich die native Kapazität pro Band ansetzten (LTO5=1,5 TB, LTO6=2,5TB). Da Veeam bereits das Backup komprimiert bringt die Kompression des Laufwerks nichts mehr. Jo, LTO braucht einen kontinuierlichen Stream. D.H. Dauerleistung über mehrere Stunden! Allerdings sind 100 MB/s bei LTO-6 deutlich zu wenig. Unser LTO-5 braucht bereits über 140 MB/s. Bei LTO6 kann man von ca. 160 MB/s ausgehen. Das sollte nicht nur das NAS, sondern auch das Netzwerk und der Server an dem das Laufwerk hängt mitspielen.
  11. Jo, dem muss aber die höhere Datendichte bei großen SATA Platten gegenüber SAS-Platten berücksichtigen. Das gleicht die höhere Drehzahl in gewisser Weise wieder aus. Ich verweise da nur auf die Datenblätter der Hersteller. Von der reinen synthetischen Transferrate nimmt sich das nicht viel. Moin, i.D.R. nutzen wir ein SAN von einem der großen Hersteller (HP, IBM, Dell). Da ist man dann eh auf die Platten angewiesen die der jeweilige SAN Hersteller mitliefert. In einem solchen SAN funktionieren dann auch meist nur Platten, die durch den SAN Hersteller mit einer extra Firmware ausgestattet wurden. Von daher ist es mir als Anwender ziemlich Schnuppe von wem die Platten im SAN im Endeffekt hergestellt wurden. Ich schaue ja in einem neuen VW auch nicht nach, von wem die Bremsbeläge oder der Ölfilter gefertigt wurden. Gruß Dirk
  12. Na, wenn dem Kunden 1 Monat reicht und Ihm die Konsequenz daraus auch wirklich klar ist, dann ist ja Alles in Ordnung. Klar bei 6 TB bei einem Offsite-Backup läuft es meist auf eine Tape-Library (z.B. LTO 5) hinaus. Ist zumindest bei uns so realisiert. Wer will schon manuell ein Band wechseln, wenn es voll ist. Hat dann immer noch den günstigsten Preis pro GB. Bei meiner letzten Veeam Schulung habe ich mal interessehalber gefragt, wer denn eine Offsite-Sicherung bei seinen Kunden macht. Hat mich wirklich etwas schockiert, dass wir fast die Einzige Firma waren, die auch noch auf Band sichert. Fast alle Kollegen sichern nur noch auf Backupstorage. Evtl. bin ich da etwas Konservativ, aber das hat mir schon einige Male der Ar...ch gerettet :D. Gruß Dirk
  13. Und Peter, auch gelesen und verstanden!? Na dann ist ja jetzt Alles klar.
  14. Kannst Du machen und was versprichst Du Dir davon? Evtl. mal darüber nachdenken... Wenn das soooo einfach wäre würde das wohl jeder Hersteller machen. Aber nein, die sind ja sooo gemein. Verkaufen einem natürlich lieber die teuren SAS-Platten anstatt Ihrem Kunden einfach SSD Cache zu verkaufen. Aber Peter sei Dank werden diese mafiösen Methoden bald keine Chance mehr haben! Wir werden bald alle StarWind VirtualSAN mit SATA-Platten und SSD Cache in unseren Firmen einsetzen :rolleyes: Kurz gesagt: SSD Cache im SAN oder NAS kann sinnvoll sein, muss es aber nicht. Gruß Dirk
  15. @DocData Sorry, ich habe die Ironie-Tags vergessen. :D Rein von der synthetischen Transferrate nehmen sich SATA und SAS wirklich nicht so viel, sofern es sich um einen kontinuierlichen Datenstrom handelt (siehe Datenblätter der Hersteller). Bei einem Datenstream spielt dann die Seektime fast gar keine Rolle. Das ist auch die Gefahr, dass Leute wie der Peter einfach nur in ein Datenblatt schauen aber die eigentliche Problematik nicht verstehen. Interessant wird es eben erst bei vielen verteilten Zugriffen bei denen die Köpfe ständig neu positioniert werden und das Queueing eine Rolle spielt. Dann spielt eine SAS mit 10/15K Platte in einer völlig anderen Liga. Gruß Dirk
  16. Moin, es gibt entweder SAS-Platten oder sog. NL-SAS-Platten. NL-SAS ist im Prinzip nichts weiter als SATA-Platten mit einem SAS-Interface und Enterprise Features (z.B. auf Dauerbetrieb ausgelegt). Weitere Unterscheide SAS bzw. NL-SAS kann man aber auch problemlos googeln. Alle großen Platten > 1,2 TB sind m.W. definitiv alle NL-SAS Platten. Performancetechnisch nehmen sich NL-SAS und SATA nicht viel, allerdings sind NL-SAS auf jedem Fall einer SATA Platte vorzuziehen! IOPS kann man berechnen. Je nach Bedarf der Anwendungen und Budget des Kunden kann man dann SAS oder NL-SAS einsetzten. Kann man ja im SAN auch mischen. Ein Array mit schnellen SAS und ein Array mit NL-SAS. In einem guten SAN kann man auch einen zusätzlichen SSD-Cache integrieren in dem dann häufig im Zugriff befindliche Daten vorgehalten werden. Alles eine Frage der Anforderungen und des Budgets. Ach ja, so viel langsamer als SAS sind NL-SAS bzw. SATA gar nicht, wenn Du die reine Datenübertragungsrate meinst ;). Aber bei den IOPS werden eben nicht nur die Übertragungsrate sondern viele andere leistungsbestimmende Faktoren berücksichtigt. Z.B. die Zugriffszeit. Und da ist eine Platte mit 15k eben deutlich fixer als eine Platte mit 7.2K! Und ja, je mehr spindeln um so mehr IOPS. Gruß Dirk
  17. Moin, mir sträuben sich da so bei einigen Aussagen die Nackenhaare... 1 Monat reicht Dir! Aber reicht das auch dem Kunden? Für alle seine Daten? Kam bei uns schon häufiger mal vor, dass auch Daten von vor 2-3 Monaten wieder gebraucht wurden (CAD Zeichnungen). Daher sichern wir einige Daten so, dass ein Zugriff über 6 Monate gewährleistet wird. Andere Daten bei uns werden auch nur 1 Monat vorgehalten. 1 Monat kann u.U. zu kurz sein (z.B. Urlaube, Krankheit, usw.). Das sollte wirklich genau mit dem Kunden abgestimmt werden. Habe diesbezüglich schon so einige Überraschungen bei Kunden erlebt, wenn dann plötzlich die erforderlichen Daten nicht mehr im Backup zu finden waren. Wie ist die Offline-Sicherung der Daten geplant bzw. realisiert? Ein reines Backup auf Medien, die jederzeit verfügbar sind (z.B. ein NAS), sind in meinen Augen kein wirkliches Backup. Ein böswilliger Mensch könnte sowohl die Produktivdaten als auch den Backupspeicher löschen! Soll ja Alles schon mal vorgekommen sein. Bei NAS denke ich sofort an QNAP oder ähnliches. Die Dinger (QNAP) finde ich echt gut und habe die auch selbst öfters eingesetzt und nutze eine hier im Unternehmen (nein, nicht als Backupspeicher :D) . 5 Jahre Laufzeit würde ich da jetzt nicht unbedingt einplanen schon gar nicht damit rechnen. Zumal bei einem Backup recht intensiv auf so ein Teil und damit auf die Platten zugegriffen wird. Da es auf die Teile keinen Wartungsvertrag gibt und hier auch meist SATA-Platten im Einsatz ist das auch mehr so eine günstige Lösung, die mir gewisse Bauchschmerzen verursacht. Zumal bei den heutigen Plattengrößen mittlerweile die theoretische Bitfehlerrate eine Rolle zu spielen beginnt. Die liegt bei den SATA-Platten mindestens um den Faktor 10 größer bzw. schlechter als bei Enterprise SAS-Platten. Von daher lieber etwas kleiner beginnen und dann nach 2-3 Jahren nach Bedarf eine neue größere Lösung mit neuer HW beschaffen oder gleich eine entsprechende Enterprise-Lösung mit Garantie beschaffen! Auch hier sollte das Pro/Contra genau mit dem Kunden abgestimmt werden! Klar, ich denke fast jeder sichert heutzutage auf ein Storage (SAN, NAS). Machen wir auch nicht Anders und ist auch wirklich bequem. Trotzdem sollte man m.E. immer noch die Daten regelmäßig auf externe Datenträger übertragen und diese dann auch extern, sicher gelagert sein. Ob das nun täglich/wöchentlich/monatlich geschieht überlasse ich der Paranoia bzw. der Wichtigkeit der Daten. Auch eine Auslagerung von Backupdaten bzw. Teile davon in ein externes Rechenzentrum mag da eine Lösung sein (Cloud-Backup). Schließlich gibt es in jedem Unternehmen Daten, deren Aktualität bzw. Vorhandensein existentiell wichtig für das Unternehmen sind, während der Verlust anderer Daten möglicherweise durchaus vertretbar sein mag. Gruß Dirk
  18. @all Sorry, aber wie ich bezugnehmend auf iSCSI/SMB schrieb, nutze ich Windows-Backup schon seit vielen Jahren nicht mehr. Von daher war mir nicht klar, dass WB keine inkrementellen Sicherungen auf einem Share unterstützt. Ein Argument mehr sich nach einer Alternative zu WB umzusehen. Gruß Dirk
  19. Moin, muss es unbedingt iSCSI auf dem QNAP sein? Reicht doch auch eine SMB-Freigabe. Dann hättest Du nicht das Problem mit der doppelten Datenmenge auf dem QNAP. Ich habe hier vor einiger Zeit mal etwas mit unserem kleinem QNAP herumgespeilt (219PII). Einen nennenswerten Geschwindigkeitsunterschied zwischen iSCSI/SMB konnte ich hier nicht feststellen. Allerdings habe ich das Windows Backup schon seit einigen Jahren nicht mehr genutzt. Bezüglich eines Restore kann ich daher keine Aussage treffen. Grundsätzlich ist der Ansatz mit 3 rotierenden Medien für das externe Backup schon mal ein guter Ansatz. Ich würde jedoch ein täglichen Wechsel von 2 Medien bevorzugen. Im Worst Case verliert man dann die Daten von max. 3 Tagen (das Wochenende). Jeweils am Wochenende tauscht man dann das freie Medium mit dem extern gelagerten Medium aus. Ob das Medium nun 50 oder 2 km weit weg gelagert wird ist m.E. nicht so wichtig. Klar, bei einem Atombombeneinschlag wären 2 km eher schlecht. ;) Entscheidend ist, dass das Medium sicher verwahrt wird. Sind ja schließlich alle Unternehmensdaten drauf. Gruß Dirk
  20. monstermania

    Veeam Backup

    Moin, also wir haben hier einen Quantum Loader mit 16 Schächten (LTO-5) der per SAS an unseren Backupserver angebunden ist. Wir machen mit Veeam zunächst B2D und anschließend C2T. Funktioniert problemlos mit Veeam. Veeam kann sowohl die ganze VM als auch einzelne Files oder einzelne Elemente aus Applikationen (AD, Exchange 2010/2013, MS-SQL, SharePoint) wieder herstellen. Für ein direktes wiederherstellen von z.B. Exchange-Mails aus dem Backup in die laufende Umgebung wird jedoch 'Enterprise' benötigt! 'Standard' kann Exchange Elemente z.B. nur in eine PST-Datei wiederherstellen, die dann wieder manuell bei dem User importiert werden müssten. Auch Virtual-Lab hast Du nur mit 'Enterprise' Mit der Lizenzierung für Veeam Essentials irrst Du m.E. Veeam Essentials wird IMHO pro Host lizenziert (max. 2 Sockel pro Host). Mag sein, dass Du nur 3 Host á 1 Sockel hast. Du musst dann aber trotzdem die 3 Hosts lizenzieren. Gruß Dirk
  21. Moin, bei SLA auf Software haben wir immer nur eine definierte Erreichbarkeit/Reaktionszeit vereinbart. Etwas Anderes wäre auch vermessen, da wir Standardsoftware vertreiben (ERP, DMS, CRM). Viele Probleme lassen sich ja auf Fehler in der Standardsoftware des jeweiligen Herstellers zurückführen und müssen seitens des jeweiligen Herstellers behoben werden. Da hängt man dann beim Kunden/Hersteller sowieso zwischen den Stühlen :rolleyes:. Manchmal dauert es ja schon Tage/Wochen um einen SW-Hersteller überhaupt dazu zu bewegen ein Problem genau zu untersuchen. Klar, immer ist erst mal der Kunde oder der FH schuld! Wir haben schon Mehrfach den Fall gehabt, dass wir bei Problemen nach Freigabe durch den Kunden die Kundendatenbank an den Hersteller weitergeben durften. Dazu muss dann der Kunde eine evtl. Kostenübernahmeerklärung und der Hersteller Verschwiegenheitserklärung unterschreiben. Allein das Procedere dauert u.U. schon mehrere Tage. Wenn es sich dann doch tatsächlich herausstellt, dass die Software einen Fehler hat muss dieser erst mal behoben und ein entsprechendes Update veröffentlicht werden. Kann mehrere Wochen oder gar Monate dauern. :cry: Mein Highlight ist immer: Der Fehler wird nicht mehr in der aktuellen Version der Software behoben. Aber in der neuen Version ist der Fehler gefixt! :shock: Schön, dem Kunden dann erklären zu müssen, warum er jetzt das Update auf die neue Version machen soll bzw. muss! Aber macht ja nix, der Kunde zahlt ja Wartungsgebühren... Gruß Dirk
  22. Moin, wir setzten Veeam seit Oktober als Ersatz für BE2010R3 im Unternehmen ein. Veeam selbst kenne ich bereits seit einigen Jahren. Veeam ist sicherlich z.Zt. das führende Backupprodukt wenn man es mit einer rein virtuellen Infrastrukur zu tun hat. Im Gegensatz zu den oft vollmundigen Versprechungen anderer Hersteller funktioniert das Backup/Restore virtueller Maschinen mit Veeam einfach. Veeam arbeitet ohne Agenten und kann trotzdem sowohl einzelne Elemente aus Sicherungen (z.B. einzelne Dateien, AD-Directory, Exchange Elemente (bei 2010/2013) und MS-SQL, SharePoint) als auch den ganzen Server sehr leicht wieder herstellen. Eine VM lässt sich im Bedarfsfall direkt aus dem Backup heraus starten, so dass die Zeiten für ein Recovery minimiert werden. Bei einer Veeam Enterprise Lizenz kann man u.a. ein Virtual-Lab einrichten um z.B. den Backup/Restore wichtiger Maschinen regelmäßig automatisch testen zu können. Die Testumgebung fährt dann die notwendigen Server in richtiger Reihenfolge automatisch im Virtual-Lab hoch. Per Scripting werden dann Zugriffe auf die wieder hergestellten Server getestet (z.B. AD, Exchange, Datenbanken, usw.). Bei uns hat sich die Laufzeit des Backups gegenüber BE2010R3 mit VM Agenten auf ca. 1/3 reduziert. Die Datenmenge des Backups hat sich halbiert, so dass wir jetzt einen wesentlich längeren Backupzeitraum direkt auf dem Backupserver vorhalten können (Veeam nutzt Dedup und Komprimierung). Veeam bietet ein voll Funktionsfähige Version zum Download an (30 Tage). Größtes Manko von Veeam: Wenn man noch Blechserver sichern muss ist Veeam leider nicht geeignet. Die eigentlichen Hosts lassen sich somit nicht mit Veeam sichern. Das ist m.E. aber auch nicht erforderlich, da ein neuer Host innerhalb weniger Minuten installiert ist. Ach ja, VeeamOne ist eine nette Zugabe zum überwachen der virtuellen Infrastruktur. Gruß Dirk
  23. Moin, also wir haben SLA immer nach Hard- und Software getrennt, da der Hardwaresupport eigentlich immer über den Hersteller erworben wird. Je nach Kundenanforderung zwischen 4h Mission-Critical bis zu NBD für die Hardware. Softwaresupport dann ebenfalls nach Kundenwunsch, wobei ja erstmal die Hardware wieder laufen muss bevor der Software SLA greift. Bei so etwas sollte man immer auch an Murphys-Law denken. Habe selbst schon mal erlebt, dass ein Servictechniker versehentlich die falschen Platten aus dem RAID des Kunden gezogen hatte -> komplette Daten des Kunden futsch! Mussten einen kompletten Restore machen. Der Kunde hat einen kompletten Arbeitsstag an Daten verloren, die anschließend mühsam nachgearbeitet werden mussten. Schadenersatz seitens des HW-Herstellers gab es keinen! So entsteht aus einem Routinefall ganz schnell eine Katastrophe... Gruß Dirk
  24. Moin, die Problematik bezüglich Backup/Restore ist Dir ja inzwischen klar geworden. Wichtig ist eben bei jedem Backupkonzept das Restore. Grundsätzlich sollte man immer einen kompletten Satz Backupdaten außer Haus aufbewahren (Brand, Diebstahl, usw.). Ein QNAP kann Backup2USB. Du kannst also Dein QNAP so einrichten, dass Du die Daten vom QNAP auf eine externe USB-Festplatte sicherst. Wenn Du mehrere Festplatten im Wechsel nutzt kannst Du auch den Zeitraum der mögl. Datenwiederherstellung verlängern. 2 Wochen ist m.E. viel zu wenig (z.B. Urlaub von Mitarbeitern). Auch das gehört zum Backupkonzept: Wie lange müssen welche Daten wiederhergestellt werden können? Gruß Dirk
  25. Moin, genauso wie Du Dir zum Thema Sicherheit Gedanken machst, solltest Du Dir auch zum Thema Lizenzierung Gedanken machen! Windows ist wegen der Lizenzproblematik nicht unbedingt die optimale Wahl für einen FTP Server. Gruß Dirk
×
×
  • Neu erstellen...