Unix Server Partitionierung & Dateisystem Layout


29

Es gibt viele widersprüchliche Informationen zur Partitionierung von Unix-Servern im Internet, daher benötige ich einige Ratschläge zur weiteren Vorgehensweise.

Bisher war mir auf den Servern in unserer Testumgebung die Partitionierung egal und ich konfigurierte eine einzelne monolithische /Partition sowie eine Swap-Partition. Dieses Partitionsschema scheint für unsere Produktionsserver keine gute Idee zu sein. Ich habe hier einen guten Ausgangspunkt gefunden , aber die Details scheinen sehr vage zu sein.


Grundsätzlich habe ich einen Server, auf dem ich einen grundlegenden LAMP-Stack ausführen werde (Apache, PHP und MySQL). Es muss Datei-Uploads (bis zu 2 GB) verarbeiten. Das System verfügt über ein RAID 1-Array mit 2 TB.

Ich plane einzustellen:

/         100GB 
/var     1000GB (apache files and mysql files will be here), 
/tmp      800GB (handles the php tmp file)
/home      96GB
swap        4GB

Hört sich das vernünftig an, oder mache ich die Dinge zu kompliziert?


1
Was ist dein Endziel? Was genau versuchst du zu erreichen?
Scott Pack

9
Wie auch immer Sie sich entscheiden, es aufzuteilen, ich würde vorschlagen, LVM zu verwenden, um Ihre Partitionen zu definieren und dann konservativen Speicherplatz zuzuweisen, wobei ein Teil des Speicherplatzes nicht zugewiesen wird. Wenn Sie dann entscheiden, dass Sie irgendwo mehr Speicherplatz benötigen, können Sie einfach LV und Dateisystem erweitern.
ktower

Antworten:


33

Eine Sache, die Sie beim Layout Ihrer Partitionen beachten sollten, sind Fehlermodi. In der Regel lautet diese Frage wie folgt: "Was passiert, wenn Partition x voll ist?" Liebste voretaq7 brachte die Situation mit einer vollen /Anzahl von schwer zu diagnostizierenden Problemen. Schauen wir uns einige spezifischere Situationen an.

Was passiert, wenn Ihre Partition, in der Protokolle gespeichert sind, voll ist? Sie verlieren Überwachungs- / Berichtsdaten und werden manchmal von Angreifern verwendet, um ihre Aktivitäten zu verbergen. In einigen Fällen authentifiziert Ihr System neue Benutzer nicht, wenn es ihr Anmeldeereignis nicht aufzeichnen kann.

Was passiert auf einem RPM-basierten System, wenn /vares voll ist? Der Paketmanager installiert oder aktualisiert keine Pakete und schlägt je nach Konfiguration möglicherweise unbeaufsichtigt fehl.

Das Auffüllen einer Partition ist besonders dann einfach, wenn ein Benutzer in der Lage ist, darauf zu schreiben. Für Spaß, führen Sie diesen Befehl und sehen , wie schnell man eine ziemlich große Datei machen: cat /dev/zero > zerofile.

Es geht auch über das Auffüllen von Partitionen hinaus. Wenn Sie Positionen an verschiedenen Einhängepunkten platzieren, können Sie auch deren Einhängeoptionen anpassen.

Was passiert, wenn /dev/nicht mit gemountet wird noexec? Da /devdavon ausgegangen wird, dass es normalerweise vom Betriebssystem verwaltet wird und nur Geräte enthält, wurde es häufig (und wird manchmal immer noch verwendet), um schädliche Programme auszublenden. Wenn noexecSie diese Option deaktivieren, können Sie die dort gespeicherten Binärdateien starten.

Aus all diesen und weiteren Gründen wird in vielen Härtungsanleitungen die Partitionierung als einer der ersten auszuführenden Schritte erörtert. Wenn Sie einen neuen Server erstellen, ist die Partitionierung der Festplatte fast genau das erste, worüber Sie sich entscheiden müssen, und oftmals das schwierigste, das Sie später ändern können. Es gibt eine Gruppe mit dem Namen " Center for Internet Security" , die zahlreiche leicht lesbare Konfigurationshandbücher erstellt. Sie können wahrscheinlich eine Anleitung für Ihr bestimmtes Betriebssystem finden und alle Details sehen, die dort stehen.

Wenn wir uns RedHat Enterprise Linux 6 ansehen, lautet das empfohlene Partitionsschema wie folgt:

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var                    
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec

Das Prinzip hinter all diesen Änderungen besteht darin, zu verhindern, dass sie sich gegenseitig beeinflussen, und / oder zu begrenzen, was auf einer bestimmten Partition getan werden kann. Nehmen Sie /tmpzum Beispiel die Optionen . Das heißt, dass dort keine Geräteknoten erstellt werden können, von dort aus keine Programme ausgeführt werden können und das set-uid-Bit für nichts gesetzt werden kann. Es ist von Natur aus /tmpfast immer von der Welt beschreibbar und oft eine spezielle Art von Dateisystem, das nur im Speicher vorhanden ist. Dies bedeutet, dass ein Angreifer es als einfachen Staging-Punkt verwenden könnte, um bösartigen Code zu löschen und auszuführen. Wenn das System dann abstürzt (oder einfach neu startet), werden alle Beweise gelöscht. Da die Funktionalität von /tmpkeine dieser Funktionen erfordert, können wir die Funktionen leicht deaktivieren und diese Situation verhindern.

Die Protokollspeicherorte /var/logund /var/log/audit-bereiche sind abgetrennt, um sie vor Erschöpfung der Ressourcen zu schützen. Darüber hinaus kann auditd einige spezielle Aufgaben ausführen (normalerweise in Umgebungen mit höherer Sicherheit), wenn sich der Protokollspeicher zu füllen beginnt. Durch Platzieren auf der Partition wird die Ressourcenerkennung verbessert.

Um genauer zu sein und zu zitieren mount(8), genau das sind die oben verwendeten Optionen:

noexec Ermöglicht keine direkte Ausführung von Binärdateien auf dem bereitgestellten Dateisystem. (Bis vor kurzem war es ohnehin möglich, Binärdateien mit einem Befehl wie /lib/ld*.so / mnt / binary auszuführen. Dieser Trick schlägt seit Linux 2.4.25 / 2.6.0 fehl.)

nodev Interpretiert keine Zeichen oder blockiert keine speziellen Geräte im Dateisystem.

nosuid Lassen Sie nicht zu, dass die Bits set-user-identifier oder set-group-identifier wirksam werden. (Dies scheint sicher zu sein, ist aber in der Tat ziemlich unsicher, wenn Sie suidperl (1) installiert haben.)

Unter Sicherheitsaspekten sind dies sehr gute Optionen, da Sie damit Schutzmaßnahmen für das Dateisystem selbst durchführen können. In einer hochsicheren Umgebung können Sie sogar die noexecOption hinzufügen /home. Dies erschwert Ihrem Standardbenutzer das Schreiben von Shell-Skripten zur Datenverarbeitung, beispielsweise zum Analysieren von Protokolldateien, verhindert jedoch auch, dass er eine Binärdatei ausführt, die die Berechtigungen erhöht.

Beachten Sie auch, dass das Standard-Ausgangsverzeichnis des Root-Benutzers lautet /root. Dies bedeutet, dass es sich im /Dateisystem befindet, nicht in /home.

Wie viel Sie genau für jede Partition vergeben, hängt stark von der Systemauslastung ab. Ein typischer Server, den ich verwaltet habe, erfordert selten eine Interaktion mit einer Person. /homeDaher muss die Partition überhaupt nicht sehr groß sein. Dies gilt auch, /varda darin eher kurzlebige Daten gespeichert werden, die häufig erstellt und gelöscht werden. Ein Webserver wird jedoch in der Regel /var/wwwals Spielwiese verwendet. Dies bedeutet, dass sich dieser entweder auch auf einer separaten Partition befinden muss oder /var/dass er groß sein muss.

In der Vergangenheit habe ich Folgendes als Basis empfohlen.

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

Diese müssen überprüft und an den Zweck des Systems und die Funktionsweise Ihrer Umgebung angepasst werden. Ich würde auch empfehlen, LVM zu verwenden und nicht die gesamte Festplatte zuzuweisen. Auf diese Weise können Sie Partitionen problemlos erweitern oder hinzufügen, wenn dies erforderlich ist.


1
Die noexecBeobachtung ist im Allgemeinen wichtig - Es wird empfohlen, /tmpmit dem noexecFlag zu mounten , um zu verhindern, dass böswillige Benutzer Rootkits über Sicherheits-Exploits des Browsers hochladen. Ähnlich /homewird es oft gemountet, nosuidda es keinen Grund gibt, dass setuid-Binärdateien vorhanden sind. Re: /devund noexecauf viele (aber nicht alle) moderne Systeme /devist oft ein devfsDateisystem und wird nicht zulassen , Benutzer erstellen / speichern reguläre Dateien auf allen (Unter FreeBSD es gibt „ Operation not supported“, auf Ubuntu das udevDateisystem gemountet auf /devkönnen Sie reguläre Dateien erstellen. ).
Voretaq7

2
@ voretaq7: Ja, die Verwendung /tmpals Sprungbrett macht großen Spaß, da es immer da und fast nie gesperrt ist.
Scott Pack

Vielen Dank für diese Ratschläge. Ich werde nach Noexec suchen, da es die Sicherheit verbessert!
Buzut

12

Wenn Sie das zugrunde liegende RAID-Array ignorieren (in dieser Frage finden Sie weitere Informationen zu RAID-Array-Ebenen und zu deren Verwendung ), konzentrieren wir uns auf die Kernfrage:
"Wie soll ich die Dateisysteme meines Unix-Servers anordnen?"


Was ist los mit einer riesigen /Partition?

Wie Sie in Ihrer Frage festgestellt haben, verwenden viele Linux-Distributionen (insbesondere die "Desktop" -Distributionen wie Ubuntu) ein sehr einfaches Dateisystem-Layout: /und [swap].

Dieses Schema hat den Vorteil der Einfachheit - es ist großartig für DOS / Windows-Benutzer, die an ihren Heim-PC mit "der Festplatte" als einem großen monolithischen Container ( C:\) gewöhnt sind, in den Sie Ihre Daten ablegen, und Sie müssen sich keine Sorgen machen Sie müssen nur sicherstellen, dass Sie nicht über genügend Speicherplatz auf den Dateisystemen verfügen und (zumindest theoretisch) alles in Ordnung ist.

Das Single-Dateisystem - Schema hat mehrere Nachteile , obwohl - die am häufigsten zitierte Nachteil ist , dass Unix - Systeme sind in der Regel sehr schlecht reagieren , wenn das Root - Dateisystem füllt sich (bis zu dem Punkt zu booten verweigern), und wenn alles schriftlich an /(die Wurzel) Ein wegweisendes Programm oder ein Benutzer kann das gesamte System herunterfahren.
Ein einzelnes großes Dateisystem kann im Falle eines Systemabsturzes und einer nachfolgenden Beschädigung des Dateisystems ebenfalls zu einem Totalverlust führen.

Die oben genannten Probleme sowie ein ausgeprägter Organisationssinn führen dazu, dass Unix-Server in der Regel mehrere Dateisysteme haben.


Wie zerlegt man das Unix-Dateisystem?

Hoffentlich sind Sie davon überzeugt, dass mehrere Dateisysteme sinnvoll sind. Die Frage ist nun, wie Sie das System in logische Blöcke aufteilen und wie Sie entscheiden, wie viel Speicherplatz jeder erhält.
Die Antwort ist, dass Sie wissen und verstehen, was Ihr Betriebssystem wo ablegen wird. Der Ausgangspunkt für dieses Verständnis ist die hierManpage. Die meisten Unix-Systeme kommen mit ( man hiervon einem Linux-System und man hiervon einem BSD-System ), und das plus Ihre lokalen Kenntnisse darüber, was der Code, den Sie installieren, tun wird, wird Sie bei der Erstellung eines vernünftigen Partitionierungslayouts unterstützen.

Ich werde hier ein allgemeines Partitionsschema beschreiben, aber dieses Schema sollte immer geändert werden, um Ihren spezifischen Bedürfnissen zu entsprechen.

Ein allgemeines Unix-Partitionierungsschema

/
    The "root partition", /, does not usually need to be very large.
    It holds the basic items needed to boot the system, mount other filesystems
    and get you to a running, usable, multi-user environment.  It's also what
    is available to you when you bring up the system in single-user ("recovery")
    mode.  
    The contents of / should not change or grow substantially over time.

    NOTE: Anything that doesn't go on one of the other partitions described
          below will wind up taking space on the root partition (/).

/var
    The /var filesystem holds variable data -- log files, email, and on some
    systems databases (like MySQL or Postgres) store their data files here.  
    `/var` should be "Big Enough" to hold all the data you intend to cram into
    it.  I generally advise 10GB for systems that won't have a database or email
    server (just logs).  If you are building a database or mail server you
    should obviously make `/var` larger, or carve out separate filesystems for
    the database/mail data.

/usr
    The /usr filesystem holds "userland" programs, data, manual pages, etc.
    This is where things like the Firefox browser binary live.  On systems that
    will have a lot of large user applications this filesystem may be very large
    (100GB or more), and on stripped-down servers it may be relatively small.  
    A good rule of thumb is that the /usr filesystem should be twice as large
    as you need it to be in order to fit your initial installation of programs.

/home
    The /home filesystem holds user home directories, and on desktop systems is
    the largest and most prone to filling up.  When you download files from the
    internet, create spreadsheets, store a music library, etc. that data is
    stored in your home directory, and it adds up fast.
    It's important to allow enough room under /home for the "accumulated junk"
    you will gather over time, even on servers -- ad-hoc tarball backups, 
    package files you copied over to install, and the like.

Spezielle Dateisysteme

/tmp and /var/tmp
    The temporary scratch space (/tmp) is "special" -- on most Unix systems
    the contents of /tmp are cleared on reboot, and on many modern systems
    /tmp is a special "tmpfs" (RAM) filesystem for better performance.
    /var/tmp is usually "persistent temporary files" (like vi recovery
    files), and is not cleared on reboot
    The same general rule applies as for all other filesystems: Make sure
    your temporary scratch filesystems are big enough to hold the stuff you
    want to put in them.

[swap]
    Swap Space is used by the kernel when you are running low on RAM --
    The old general rule of thumb was to have at least twice as much swap
    as you did RAM, however on modern systems it's usually sufficient to
    have "enough" swap -- 2GB is a practical lower limit, and an amount
    between half the installed RAM and the total installed RAM is usually
    adequate.
    On modern systems with relatively huge RAM pools (12G and up) it is
    probably not practical to use the system if it's swapping heavily
    enough to warrant the old "Twice the installed RAM" rule.

2
Die beiden von Ihnen genannten Gründe sind heute weitgehend veraltet. ext [234] reserviert etwas Platz für root und lässt nicht zu, dass Benutzerprogramme alles ausnutzen, damit das System keine Probleme mit nicht genügend Speicherplatz bekommt. Alle modernen Dateisysteme verwenden Journaling, damit sie nachher nicht beschädigt werden ein Unfall.
Psusi

2
@psusi Der für den Root-Benutzer reservierte Speicherplatz (normalerweise 5-10% der Dateisystemgröße) hilft Ihnen nicht, wenn der Root-Benutzer die Dateien schreibt, die die Festplatte füllen (wie dies bei Protokolldateien häufig der Fall ist). Es ist auch falsch anzunehmen, dass ein Dateisystem, nur weil es im Journal gespeichert ist, immer vor Beschädigung geschützt ist - Journaling erhöht die Robustheit, garantiert jedoch nicht die Sicherheit (insbesondere, wenn Sie auf einen unentdeckten Fehler im Dateisystem- / Journaling-Code stoßen und das Journal verwischen - Die ReiserFS-Leute können einige großartige Geschichten darüber aus den Anfängen dieses Dateisystems erzählen.
Voretaq7

2
Ein intaktes zu haben /usroder /varnicht zu helfen, wenn /es beschädigt ist. Ebenso /hilft es nicht (viel) , ein intaktes zu haben, wenn /homees beschädigt ist. In beiden Fällen müssen Sie die Daten aus dem Backup wiederherstellen. Ganz zu schweigen davon, dass solche Fehler eins zu einer Million sind, es sei denn, Sie führen eine neue / instabile fs aus.
Psusi

4

Die Praxis, das Dateisystem so aufzuteilen, stammt aus der Zeit, als es noch keinen Software-Raid gab und die Festplatten klein waren. Sie mussten also mehrere davon verwenden, und daher bestand die einzige Möglichkeit, dies zu tun, darin, das Dateisystem aufzubrechen und legen Sie verschiedene Verzeichnisse auf verschiedenen Laufwerken. Der andere historische Grund dafür war, dass Sie leicht eine Partition aushängen und dumpdiese sichern konnten, was mit dem Root nicht möglich war. Dieses Tool ist heutzutage weitestgehend in Ungnade gefallen und kann stattdessen für einen LVM-Snapshot verwendet werden, sogar für den Stamm.

Es gibt keinen Grund mehr, dies zu tun. Der einzige Grund dafür ist, dass Sie beispielsweise verhindern möchten, dass /tmpdie gesamte Festplatte voll ist.

Dieser Grund ist heutzutage größtenteils irrelevant, da es auf der Strecke geblieben ist, Benutzern allgemeinen Shell-Zugriff zu ermöglichen, und heutzutage Server dedizierte Dienste wie Web- oder Mailserver ausführen. Da Sie keine zufälligen Benutzer haben, die in der Lage sind, beliebige Befehle auszuführen, müssen Sie sich im Allgemeinen keine Sorgen machen, dass diese versuchen, Ihr Dateisystem zu füllen (und selbst wenn Sie dies getan haben, hatten Sie Festplattenkontingente, um dies zu stoppen).

In Bezug auf die zu verwendende RAID-Stufe müssen Sie berücksichtigen, dass der Hauptzweck des RAID-Angriffs nicht der Schutz von Daten (für die Backups vorgesehen sind) ist, sondern die Aufrechterhaltung der Verfügbarkeit. Wenn Sie /tmpein Raid0 durchführen, fällt Ihr Server immer noch aus und Sie müssen es reparieren, wenn eine der Festplatten ausfällt. Sie können auch raid10 anstelle von raid1 verwenden, um eine bessere Leistung zu erzielen.

Ein sehr guter Grund, das Dateisystem NICHT aufzulösen, ist, dass bei falschen Zuordnungen ein Teil des Dateisystems voll sein kann, obwohl an anderer Stelle genügend freier Speicherplatz vorhanden ist. Das zu korrigieren, kann schwierig sein, es sei denn, Sie verwenden LVM und belassen nicht zugewiesenen Speicherplatz.


4
Es gibt viele Gründe, ein Unix-Dateisystem weiterhin auf herkömmliche Weise aufzubauen. Wenn es keinen Grund dafür gäbe, hätten wir jetzt aufgehört - Sysadmins sind nicht DAS , was an arkanen Traditionen
hängt

1
@ voretaq7, dann nenne einige. Wenn Sie nicht können, dann ist es töricht, blind anzunehmen, dass es etwas geben muss.
Psusi

1
Es wäre den Abstimmenden ein Anliegen, tatsächlich ein Gegenargument zu liefern, anstatt blindlings die konventionelle Weisheit zu verteidigen.
Psusi

2
Verhindert, dass / var / log alles aufnimmt, indem es auffüllt. Beschränkt die Beschädigung auf ein Dateisystem. Vereinfacht Backups - ob Snapshots oder Mount-Traversal-Regeln, man möchte oft nach unterschiedlichen Zeitplänen sichern. Vereinfacht das Imaging / Upgrades. Ermöglicht die Auswahl der auf Dateisystemen basierenden Leistung im Zusammenhang mit der Aufgabe.
Jeff Ferland

1
@JeffFerland, das ist bestenfalls ein schwacher Grund, / var / log auf eine eigene Partition zu setzen, aber nicht für die anderen Partitionen. Wenn Sie nicht immer noch dumpverschiedene Teile des Dateisystems sichern, müssen diese Teile nicht auf verschiedenen Partitionen liegen. Upgrades interessieren nicht so oder so. Imaging ist auch keine sehr gute Methode, um Dinge zu tun.
Psusi

3

Ein Großteil der Partitionierungsinformationen wurde generiert, als Speicherplatz knapp war. Infolgedessen sehen Sie für eine Reihe von Fällen relativ kleine Partitionen. Die erforderlichen Partitionsgrößen variieren je nach Servernutzung. Die Variablen neigen zu sein /tmp, /var, home, /opt, und /srv. /usrneigt zu einer vernünftigen und stabilen Größe. Der /Speicherplatz für kann einige oder alle anderen Partitionen und deren Speicherplatzanforderungen enthalten. Die Größe hängt wirklich davon ab, was Sie mit dem System machen.

Ich würde erhöhen swapund montieren /tmpauf tmpfs. Sie /tmpwerden dann Swap als Backup-Speicher verwenden, aber den verfügbaren Speicher verwenden. Ihre Größe /tmpsieht extrem hoch aus, verarbeitet aber abgebrochene Uploads, die nicht bereinigt wurden.

Ich würde erwägen, die MySQL-Dateien zu verschieben /srv. Dies ist eine relativ neue Ebene in der Festplattenhierarchie.

Wenn Sie Ihre endgültigen Anforderungen nicht kennen, sollten Sie LVM verwenden und Ihre Partitionen erweitern, um sie aufzufüllen.


Seien Sie vorsichtig beim Erhöhen des Swaps - Es ist gut, "genug" Swap zu haben, aber wenn Sie zu viel Swap haben, werden Sie ihn niemals verwenden (weil zu dem Zeitpunkt, zu dem Sie so stark tauschen, die Systemleistung einfach zu schmerzhaft ist). Ich würde sagen, dass das in der Frage vorgeschlagene 4G wahrscheinlich "genug" für einen LAMP-Stack ist - wenn Sie 4G Swap verwenden (und diese Daten tatsächlich ein- und auslagern), werden Sie wahrscheinlich auch am Telefon angeschrien, weil Die Website ist langsam :)
voretaq7

1
@ voretaq7 Es ist egal, welche Größe Swap ist, wenn Sie für aktive Programme verwenden. Die Verwendung für tmpfs, bei denen große Dateien auf die Festplatte geschrieben werden, kleinere Dateien jedoch im Arbeitsspeicher verbleiben, ist eine sinnvolle Verwendung von Swap. Es erspart das Schreiben jeder Datei auf die Festplatte, wenn diese an einer anderen Stelle abgelegt werden soll. Ich schlug vor, den Swap-Platz zu vergrößern, da anscheinend ein großer /tmpPlatz erforderlich ist.
BillThor

Warum nicht eine normale Datei zum Tauschen verwenden? Waren sie schon lange nicht mehr so ​​schnell wie eine dedizierte Swap-Partition?
Chris Smith

@ChrisSmith Eine reguläre Datei sollte fast so schnell sein wie eine dedizierte Partition, aber möglicherweise nicht zusammenhängend auf der Festplatte, was zu geteilten E / A-Anforderungen führt. Dies kann durch Streifen ausgeglichen werden. Außerdem ist es relativ einfach, eine Auslagerungsdatei versehentlich zu löschen. Die gelöschte Datei wird erst sichtbar, wenn das System neu gestartet wird und der Auslagerungsspeicher nicht mehr verfügbar ist.
BillThor

@BillThor Dies ist wahr - wenn Sie tmpfsSwap als Backing Store verwenden und erwarten, dass Sie Swap aktivieren , sollten Sie "genug" Swap haben, um Ihre tmpfs-Anforderungen zu erfüllen, plus eine entsprechende Reserve für das System. (Daran denke ich normalerweise nicht, da das einzige System, auf dem ich tmpfsarbeite, so konfiguriert ist, dass kein Swap ausgeführt wird, da es einen RAM-Überschuss aufweist und ich den temporären Speicherplatz für winzige Dateien verwende, die schnell erstellt / gelöscht werden :)
voretaq7

2

Abhängig von Ihrer Architektur möchten Sie / tmp möglicherweise nicht wirklich verwenden, da es nach jedem Neustart gelöscht wird. Wenn sich Ihre Site mit der eventuellen Verarbeitung von Uploads befasst, ist es möglicherweise eine Idee, diese an einen anderen Speicherort (über php.ini) zu verschieben. in dem du es zu einem beliebigen mount point machen kannst.

Wie bereits erwähnt, wird dringend empfohlen, LVM zu verwenden und nach Bedarf zu erhöhen.

Ich würde auch eine dedizierte Partition für MySQL-Daten empfehlen (Sie können diese weiterhin unter / var / lib / mysql einhängen).


Es ist im Allgemeinen eine gute Idee anzunehmen, dass die Dateien /tmpspäter möglicherweise nicht mehr vorhanden sind - erspart Ihnen später unangenehme Überraschungen :-)
voretaq7
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.