Da die Datei-Eintr\"{a}ge ca. 80 Prozent der Katalog-Datenbankgr\"{o}{\ss}e ausmachen,
sollten Sie sorgf\"{a}lltig ermitteln \"{u}ber welchen Zeitraum Sie die Eintr\"{a}ge aufbewahren wollen.
-Nachdem die Datei-Eintr\"{a}ge ge\"{o}scht wurden, ist es nicht mehr m\"{o}glich einzelne dieser Dateien
+Nachdem die Datei-Eintr\"{a}ge gel\"{o}scht wurden, ist es nicht mehr m\"{o}glich einzelne dieser Dateien
mit einem R\"{u}cksicherungs-Job wiederherzustellen, aber die Bacula-Versionen 1.37 und sp\"{a}ter
sind in der Lage, aufgrund des Job-Eintrags im Katalog, alle Dateien des Jobs zur\"{u}ckzusichern
solange der Job-Eintrag im Katalog vorhanden ist.
Aufbewahrungszeitr\"{a}ume werden in Sekunden angegeben, aber der Einfachheit halber sind auch
-eine Nummer von Hilfsangaben vorhanden, so dass man Minuten, Stunden, Tage, Wochen,
+eine Reihe von Hilfsangaben m\"{o}glich, so dass man Minuten, Stunden, Tage, Wochen,
Monate, Quartale und Jahre konfigurieren kann. Lesen Sie bitte das \ilink{Konfigurations-Kapitel}{Time}
dieses Handbuchs um mehr \"{u}ber diese Hilfsangaben zu erfahren.
Job-Eintr\"{a}ge in der Katalog-Datenbank aufbewahrt werden.
Wenn {\bf AutoPrune} in der Client-Konfiguration auf {\bf yes} gesetzt ist,
wird Bacula die Katalog-Eintr\"{a}ge der Jobs l\"{o}schen, die \"{a}lter als
-dieser Zeitraum sind. Beachten Sie, dass wenn ein Job-Eintrag ge\"{o}scht wird,
+dieser Zeitraum sind. Beachten Sie, dass wenn ein Job-Eintrag gel\"{o}scht wird,
auch alle zu diesem Job geh\"{o}renden Datei- und JobMedia-Eintr\"{a}ge aus dem
Katalog gel\"{o}scht werden. Dies passiert unabh\"{a}ngig von der Aufbewahrungszeit f\"{u}r Dateien,
infolge dessen wird die Aufbewahrungszeit f\"{u}r Dateien normalerweise k\"{u}rzer sein als f\"{u}r Jobs.
Wie oben erw\"{a}hnt, sind Sie nicht mehr in der Lage einzelne Dateien eines Jobs zur\"{u}ckzusichern,
wenn die Datei-Eintr\"{a}ge aus der Katalog-Datenbank entfernt wurden. Jedoch, solange der Job-Eintrag
im Katalog vorhanden ist, k\"{o}nnen Sie immer noch den kompletten Job mit allen Dateien wiederherstellen
-(mit Bacula-Version 1.37 und gr\"{o}{\ss}er). Daher ist es eine gute Idee, die Job-Eintr\"{a}ge im Katalog
+(ab Bacula-Version 1.37 und gr\"{o}{\ss}er). Daher ist es eine gute Idee, die Job-Eintr\"{a}ge im Katalog
l\"{a}nger als die Datei-Eintr\"{a}ge aufzubewahren.
Aufbewahrungszeitr\"{a}ume werden in Sekunden angegeben, aber der Einfachheit halber sind auch
-eine Nummer von Hilfsangaben vorhanden, so dass man Minuten, Stunden, Tage, Wochen,
+eine Reihe von Hilfsangaben m\"{o}glich, so dass man Minuten, Stunden, Tage, Wochen,
Monate, Quartale und Jahre konfigurieren kann. Lesen Sie bitte das \ilink{Konfigurations-Kapitel}{Time}
dieses Handbuchs um mehr \"{u}ber diese Hilfsangaben zu erfahren.
\end{verbatim}
\normalsize
-Abh\"{a}gig von der Gr\"{o}{\ss}e Ihrer Datenbank, wird dies mehr oder weniger Zeit und auch Festplattenplatz
+Abh\"{a}ngig von der Gr\"{o}{\ss}e Ihrer Datenbank, wird dies mehr oder weniger Zeit und auch Festplattenplatz
ben\"{o}tigen. Zum Beispiel, wenn ich in das Verzeichnis wechsle, wo meine MySQL-Datenbank liegt (typischerweise
-/var/lib/mysql) und diese Kommando ausf\"{u}hre:
+/var/lib/mysql) und dieses Kommando ausf\"{u}hre:
\footnotesize
\begin{verbatim}
bekomme ich die Ausgabe {\bf 620,644}, was bedeutet dass das Verzeichnis bacula 620.644 Bl\"{o}cke
von 1024 Bytes auf der Festplatte belegt, meine Datenbank enth\"{a}lt also ca. 635 MB an Daten.
Nachdem ich das {\bf mysqldump} ausgef\"{u}hrt habe, ist die dabei entstandene Datei bacula.sql
-{\bf 174.356} Bl\"{o}cke gro{\ss}, wenn diese Datei wieder mit dem Kommando {\bf mysql bacula < bacula.sql}
-in die Datenbank importiert wird, ergibt sich eine Datenbankgr\"{o}{\ss}e von nur noch {\bf 210.464}
+{\bf 174.356} Bl\"{o}cke gro{\ss}, wenn diese Datei mit dem Kommando {\bf mysql bacula \< bacula.sql}
+wieder in die Datenbank importiert wird, ergibt sich eine Datenbankgr\"{o}{\ss}e von nur noch {\bf 210.464}
Bl\"{o}cken. Mit anderen Worten, die komprimierte Version meiner Datenbank, die seit ca. 1 Jahr
in Benutzung ist, ist ungef\"{a}hr nur noch ein Drittel so gro{\ss} wie vorher.
Wenn Sie bemerken, dass das Schreiben der MySQL-Datenbank zu Fehlern f\"{u}hrt,
oder das der Director-Dienst h\"{a}ngt, wenn er auf die Datenbank zugreift,
sollten Sie sich die MySQL Datenbank\"{u}berpr\"{u}fungs- und Reparaturprogramme ansehen.
-Welches Programm Sie laufen lassen sollten, h\"{a}ngt von der von Ihnen benutzten Datenbank-
+Welches Programm Sie laufen lassen sollten, h\"{a}ngt mit der von Ihnen benutzten Datenbank-
Indizierung zusammen. Wenn Sie das Standardverfahren nutzen, werden Sie vermutlich {\bf myisamchk}
laufen lassen. F\"{a}r n\"{a}here Information lesen Sie bitte auch:
\elink{http://dev.mysql.com/doc/refman/5.1/de/client-utility-programs.html}
\normalsize
anzeigen lassen. Wenn die Spalte {\bf max\_data\_length} ca. 4 GB entspricht,
-dann ist dass das Problem. Sie k\"{o}nnen die maximale Gr\2{o}{\ss}e mittels:
+dann ist dass das Problem. Sie k\"{o}nnen die maximale Gr\"{o}{\ss}e aber mit:
\footnotesize
\begin{verbatim}
\normalsize
-Die myisam Data-Pointer-Gr\"{o}{\ss}e muss vor dem anlegen der Bacula-Katalog-Datenbank oder ihrer Tabellen
-gesetzt sein, um wirksam zu sein.
+Die myisam Data-Pointer-Gr\"{o}{\ss}e muss vor dem Anlegen der Bacula-Katalog-Datenbank oder ihrer Tabellen
+gesetzt werden, um wirksam zu sein.
-Die MAX\_ROWS und Pointer-Anpassungen sollten bei MySQL-Versionen > 5.x nicht n\"{o}tig sein,
+Die MAX\_ROWS und Pointer-Anpassungen sollten bei MySQL-Versionen gr\"{o}{\ss}er 5.x nicht n\"{o}tig sein,
somit sind diese \"{A}nderungen nur bei MySQL 4.x, in Abh\"{a}gigkeit von Ihrer Katalog-Datenbank-Gr\"{o}{\ss}e,
notwendig.
Beachten Sie bitte, dass es im Fall von SQLite erforderlich ist, die alte Datenbank komplett zu l\"{o}schen,
bevor die komprimierte Version angelegt werden kann.
-\section{Migrating from SQLite to MySQL}
-\index[general]{MySQL!Migrating from SQLite to }
-\index[general]{Migrating from SQLite to MySQL }
+\section{Migration von SQLite zu MySQL}
+\index[general]{MySQL!Migration von SQLite zu }
+\index[general]{Migration von SQLite zu MySQL }
-You may begin using Bacula with SQLite then later find that you want to switch
-to MySQL for any of a number of reasons: SQLite tends to use more disk than
-MySQL; when the database is corrupted it is often more catastrophic than
-with MySQL or PostgreSQL.
-Several users have succeeded in converting from SQLite to MySQL by
-exporting the MySQL data and then processing it with Perl scripts
-prior to putting it into MySQL. This is, however, not a simple
-process.
+Wenn Sie Bacula anfangs mit SQLite zusammen benutzt haben, gibt es sp\"{a}ter
+eine Reihe von Gr\"{u}nden, weshalb Sie eventuell auf MySQL umsteigen wollen:
+SQLite belegt mehr Festplattenplatz f\"{u}r dieselbe Datenmenge als MySQL;
+falls die Datenbank besch\"{a}digt wird, ist es mit SQLite problematischer als
+bei MySQL oder PostgreSQL, sie wiederherzustellen. Viele Benutzer sind erfolgreich
+von SQLite auf MySQL umgestiegen, indem sie zuerst die Daten exportiert haben und sie dann
+mit einem z.B. Perl-Script in ein passendes Format konvertiert haben, um sie in die
+MySQL-Datenbank zu importieren. Dies ist aber kein sehr einfacher Vorgang.
\label{BackingUpBacula}
-\section{Backing Up Your Bacula Database}
-\index[general]{Backing Up Your Bacula Database }
-\index[general]{Database!Backing Up Your Bacula }
-
-If ever the machine on which your Bacula database crashes, and you need to
-restore from backup tapes, one of your first priorities will probably be to
-recover the database. Although Bacula will happily backup your catalog
-database if it is specified in the FileSet, this is not a very good way to do
-it, because the database will be saved while Bacula is modifying it. Thus the
-database may be in an instable state. Worse yet, you will backup the database
-before all the Bacula updates have been applied.
-
-To resolve these problems, you need to backup the database after all the backup
-jobs have been run. In addition, you will want to make a copy while Bacula is
-not modifying it. To do so, you can use two scripts provided in the release
-{\bf make\_catalog\_backup} and {\bf delete\_catalog\_backup}. These files
-will be automatically generated along with all the other Bacula scripts. The
-first script will make an ASCII copy of your Bacula database into {\bf
-bacula.sql} in the working directory you specified in your configuration, and
-the second will delete the {\bf bacula.sql} file.
-
-The basic sequence of events to make this work correctly is as follows:
+\section{Sichern Ihrer Bacula Datenbank}
+\index[general]{Sichern Ihrer Bacula Datenbank}
+\index[general]{Datenbank!Sichern Ihrer Bacula }
+
+Falls jemals der Rechner auf dem Ihre Bacula-Installation l\"{a}uft abst\"{u}rzt,
+und Sie diesen wiederherstellen m\"{u}ssen, wird es einer der ersten Schritte sein,
+die Datenbank zur\"{u}ckzusichern. Obwohl Bacula fr\"{o}hlich die Datenbank sichert,
+wenn sie im FileSet angegeben ist, ist das kein sehr guter Weg, da Bacula die Datenbank
+\"{a}ndert, w\"{a}hrend sie gesichert wird. Dadurch ist die gesicherte Datenbank wahrscheinlich
+in einem inkonsistenten Zustand. Noch schlimmer ist, dass die Datenbank gesichert wird,
+bevor Bacula alle Aktualisierungen durchf\"{u}hren kann.
+
+Um diese Problem zu umgehen, m\"{u}ssen Sie die Datenbank sichern nachdem alle Backup-Jobs
+gelaufen sind. Zus\"{a}tzlich werden Sie wohl eine Kopie der Datenbank erstellen wollen,
+w\"{a}hrend Bacula keine Aktualisierungen vornimmt. Um das zu erreichen, k\"{o}nnen Sie
+die beiden Scripte {\bf make\_catalog\_backup} und {\bf delete\_catalog\_backup} benutzen,
+die Ihrer Bacula-Version beiliegen. Diese Dateien werden, zusammen mit den anderen Bacula-Scripts,
+automatisch erzeugt. Das erste Script erzeugt eine ASCII-Kopie Ihrer Datenbank namens {\bf bacula.sql}
+in dem Arbeitsverzeichnis, dass Sie in der Konfiguration angegeben haben. Das zweite Script
+l\"{o}scht die Datei {\bf bacula.sql} wieder.
+
+Die grundlegenden Arbeitsschritte damit alles korrekt funktioniert, sind folgende:
\begin{itemize}
-\item Run all your nightly backups
-\item After running your nightly backups, run a Catalog backup Job
-\item The Catalog backup job must be scheduled after your last nightly backup
+\item alle Backup-Jobs laufen lassen
+\item wenn alle Jobs beendet sind, wird ein Catalog Backup-Job gestartet
+\item Der Catalog Backup-Job muss nach den anderen Backup-Jobs laufen
-\item You use {\bf RunBeforeJob} to create the ASCII backup file and {\bf
- RunAfterJob} to clean up
+\item Benutzen Sie {\bf RunBeforeJob} um die ASCII-Sicherungsdatei zu erstellen und
+ {\bf RunAfterJob} um sie wieder zu l\"{o}schen
\end{itemize}
-Assuming that you start all your nightly backup jobs at 1:05 am (and that they
-run one after another), you can do the catalog backup with the following
-additional Director configuration statements:
+Angenommen Sie starten alle Ihre Backup-Jobs nachts um 01:05, k\"{o}nnen Sie das Catalog-Backup
+mit der folgenden zus\"{a}tzlichen Director-Dienst-Konfiguration ausf\"{u}hren lassen:
\footnotesize
\begin{verbatim}
-# Backup the catalog database (after the nightly save)
+# Catalog-Datenbank-Backup (nach der n\"{a}chtlichen Sicherung)
Job {
Name = "BackupCatalog"
Type = Backup
RunAfterJob = "/home/kern/bacula/bin/delete_catalog_backup"
Write Bootstrap = "/home/kern/bacula/working/BackupCatalog.bsr"
}
-# This schedule does the catalog. It starts after the WeeklyCycle
+# Diese Schedule starten das Catalog-Backup nach den anderen Sicherungen
Schedule {
Name = "WeeklyCycleAfterBackup
Run = Level=Full sun-sat at 1:10
}
-# This is the backup of the catalog
+# Das FileSet f\"{u}r die ASCII-Kopie der Datenbank
FileSet {
Name = "Catalog"
Include {
\end{verbatim}
\normalsize
-Be sure to write a bootstrap file as in the above example. However, it is preferable
-to write or copy the bootstrap file to another computer. It will allow
-you to quickly recover the database backup should that be necessary. If
-you do not have a bootstrap file, it is still possible to recover your
-database backup, but it will be more work and take longer.
+Stellen Sie sicher, dass, wie in dem Beispiel, eine Bootstrap-Datei geschrieben wird.
+Bevorzugterweise wird eine Kopie dieser Bootstrap-Datei auf einem andern Computer gespeichert.
+Dies erlaubt eine schnelle Wiederherstellung der Datenbank, falls erforderlich. Wenn Sie
+keine Bootstrap-Datei haben, ist es trotzdem m\"{o}glich, erfordert aber mehr Arbeit und dauert l\"{a}nger.
\label{BackingUPOtherDBs}
-\section{Backing Up Third Party Databases}
-\index[general]{Backing Up Third Party Databases }
-\index[general]{Databases!Backing Up Third Party }
-
-If you are running a database in production mode on your machine, Bacula will
-happily backup the files, but if the database is in use while Bacula is
-reading it, you may back it up in an unstable state.
-
-The best solution is to shutdown your database before backing it up, or use
-some tool specific to your database to make a valid live copy perhaps by
-dumping the database in ASCII format. I am not a database expert, so I cannot
-provide you advice on how to do this, but if you are unsure about how to
-backup your database, you might try visiting the Backup Central site, which
-has been renamed Storage Mountain (www.backupcentral.com). In particular,
-their
-\elink{ Free Backup and Recovery
-Software}{http://www.backupcentral.com/toc-free-backup-software.html} page has
-links to scripts that show you how to shutdown and backup most major
-databases.
+\section{Sicherung anderer Datenbanken}
+\index[general]{Sicherung anderer Datenbanken }
+\index[general]{Datenbanken!Sicherung anderer }
+
+Wie oben schon erw\"{a}hnt wurde, f\"{u}hrt das Sichern von Datenbank-Dateien im laufenden Betrieb
+dazu, dass die gesicherten Dateien sich wahrscheinlich in einem inkonsistenten Zustand befinden.
+
+Die beste L\"{o}sung daf\"{u}r ist, die Datenbank vor der Sicherung zu stoppen,
+oder datenbankspezifische Hilfsprogramme zu verwenden, um eine g\"{u}ltige Sicherungsdatei zu erstellen,
+die Bacula dann auf die Volumes schreiben kann. Wenn Sie unsicher sind, wie Sie das am besten mit der
+von Ihnen benutzten Datenbank erreichen k\"{o}nnen, hilft Ihnen eventuell die Webseite von Backup Central
+weiter. Auf \elink{ Free Backup and Recovery Software}{http://www.backupcentral.com/toc-free-backup-software.html}
+finden Sie Links zu Scripts die zeigen, wie man die meisten gr\"{o}{\ss}eren Datenbanken sichern kann.
+
\label{Size}
-\section{Database Size}
-\index[general]{Size!Database }
-\index[general]{Database Size }
+\section{Datenbank Gr\"{o}{\ss}e}
+\index[general]{Gr\"{o}{\ss}e!Datenbank }
+\index[general]{Datenbank Gr\"{o}{\ss}e }
-As mentioned above, if you do not do automatic pruning, your Catalog will grow
-each time you run a Job. Normally, you should decide how long you want File
-records to be maintained in the Catalog and set the {\bf File Retention}
-period to that time. Then you can either wait and see how big your Catalog
-gets or make a calculation assuming approximately 154 bytes for each File
-saved and knowing the number of Files that are saved during each backup and
-the number of Clients you backup.
+Wenn Sie nicht automatisch alte Datens\"{a}tze aus Ihrer Katalog-Datenbank l\"{o}schen lassen,
+wird Ihre Datenbank mit jedem gelaufenen Backup-Job wachsen (siehe auch weiter oben).
+Normalerweise sollten Sie sich entscheiden, wie lange Sie die Datei-Eintr\"{a}ge im Katalog
+aufbewaren wollen und die {\bf File Retention} entsprechend konfigurieren. Dann k\"{o}nnen Sie
+entweder abwarten wie gro{\ss} Ihre Katalog-Datenbank werden wird, oder es aber auch unge\"{a}hr
+berechnen. Dazu m\"{u}ssen Sie wissen, dass f\"{u}r jede gesicherte Datei in etwa 154 Bytes in der
+Katalog-Datenbank belegt werden und wieviele Dateien Sie auf wievielen Computern sichern werden.
-For example, suppose you do a backup of two systems, each with 100,000 files.
-Suppose further that you do a Full backup weekly and an Incremental every day,
-and that the Incremental backup typically saves 4,000 files. The size of your
-database after a month can roughly be calculated as:
+Ein Beispiel: angenommen Sie sichern zwei Computer, jeder mit 100.000 Dateien.
+Weiterhin angenommen, Sie machen ein w\"{o}chentliches Full-Backup und ein
+inkrementelles jeden Tag, wobei bei einem inkrementellen Backup typischerweise 4.000 Dateien
+gesichert werden. Die ungef\"{a}hre Gr\"{o}{\ss}e Ihrer Datenbank nach einem Monat
+kann dann so berechnet werden:
\footnotesize
\begin{verbatim}
- Size = 154 * No. Systems * (100,000 * 4 + 10,000 * 26)
+ Gr\"{o}{\ss}e = 154 * Anzahl Computer * (100.000 * 4 + 10.000 * 26)
\end{verbatim}
\normalsize
-where we have assumed four weeks in a month and 26 incremental backups per month.
-This would give the following:
-
+wenn ein Monat mit 4 Wochen angenommen wird, werden also 26 inkrementelle Backups im Monat laufen.
+Das ergibt das folgende:
\footnotesize
\begin{verbatim}
- Size = 154 * 2 * (100,000 * 4 + 10,000 * 26)
+ Gr\"{o}{\ss}e = 154 * 2 * (100.000 * 4 + 10.000 * 26)
or
- Size = 308 * (400,000 + 260,000)
+ Gr\"{o}{\ss}e = 308 * (400.000 + 260.000)
or
- Size = 203,280,000 bytes
+ Gr\"{o}{\ss}e = 203.280.000 Bytes
\end{verbatim}
\normalsize
-So for the above two systems, we should expect to have a database size of
-approximately 200 Megabytes. Of course, this will vary according to how many
-files are actually backed up.
-
-Below are some statistics for a MySQL database containing Job records for five
-Clients beginning September 2001 through May 2002 (8.5 months) and File
-records for the last 80 days. (Older File records have been pruned). For these
-systems, only the user files and system files that change are backed up. The
-core part of the system is assumed to be easily reloaded from the Red Hat rpms.
+f\"{u}r die beiden oben angenommen Computer k\"{o}nnen wir also davon ausgehen, dass die Datenbank
+in etwa 200 Megabytes gro{\ss} wird. Nat\"{u}rlich h\"{a}ngt dieser Wert davon ab, wieviele
+Dateien wirklich gesichert werden.
+Unten sehen Sie ein paar Statistiken f\"{u}r eine MySQL-Datenbank die Job-Eintr\"{a}ge
+f\"{u}r 5 Clients \{u}ber 8.5 Monate und Datei-Eintr\"{a}ge \"{u}ber 80 Tage enth\"{a}lt
+(\"{a}ltere Datei-Eintr\"{a}ge wurden schon gel\"{o}scht). Bei diesen 5 Clients wurden nur
+die Benutzer- und System-Dateien gesichert, die sich st\"{a}ndig \"{a}ndern. Bei allen
+anderen Dateien wird angenommen, dass sie leicht aus den Software-Paketen des Betriebssystems
+wiederherstellbar sind.
-In the list below, the files (corresponding to Bacula Tables) with the
-extension .MYD contain the data records whereas files with the extension .MYI
-contain indexes.
+In der Liste sind die Dateien (die den MySQL-Tabellen entsprechen) mit der Endung .MYD
+die, die die eigentlichen Daten enthalten und die mit der Endung .MYI enthalten die Indexe.
-You will note that the File records (containing the file attributes) make up
-the large bulk of the number of records as well as the space used (459 Mega
-Bytes including the indexes). As a consequence, the most important Retention
-period will be the {\bf File Retention} period. A quick calculation shows that
-for each File that is saved, the database grows by approximately 150 bytes.
+Sie werden bemerken, dass die meisten Eintr\"{a}ge in der Datei File.MYD
+(die die Datei-Attribute enth\"{a}lt) enthalten sind und diese auch den
+meisten Platz auf der Festplatte belegt. Die {\bf File Retention} (der Aufbewahrungszeitraum
+f\"{u}r Dateien) ist also im wesentlichen daf\"{u}r verantwortlich, wie gro{\ss} die Datenbank wird.
+Eine kurze Berechnung zeigt, dass die Datenbank mit jeder gesicherten Datei ungef\"{a}hr um
+154 Bytes w\"{a}chst.
\footnotesize
\begin{verbatim}
- Size in
- Bytes Records File
+Gr\"{o}{\ss}e
+ in Bytes Eintr\"{a}ge Dateiname
============ ========= ===========
168 5 Client.MYD
3,072 Client.MYI
\end{verbatim}
\normalsize
-This database has a total size of approximately 450 Megabytes.
+Die Datenbank hat eine Gr\"{o}{\ss}e von ca. 450 Megabytes..
-If we were using SQLite, the determination of the total database size would be
-much easier since it is a single file, but we would have less insight to the
-size of the individual tables as we have in this case.
+H\"{a}tten wir SQLite genommen, w\"{a}re die Bestimmung der Datenbankgr\"{o}{\ss}e
+viel einfacher gewesen, da SQLite alle Daten in einer einzigen Datei speichert,
+dann aber h\"{a}tten wir nicht so einfach erkennen k\"{o}nnen, welche der Tabellen
+den meisten Speicherplatz ben\"{o}tigt.
-Note, SQLite databases may be as much as 50\% larger than MySQL databases due
-to the fact that all data is stored as ASCII strings. That is even binary
-integers are stored as ASCII strings, and this seems to increase the space
-needed.
+SQLite Datenbanken k\"{o}nnen bis zu 50 \% gr\"{o}{\ss}er sein als MySQL-Datenbanken
+(bei gleichem Datenbestand), weil bei SQLite alle Daten als ASCII-Zeichenketten gespeichert werden.
+Sogar bin\"{a}re Daten werden als ASCII-Zeichenkette dargestellt, und das scheint den Speicherverbrauch
+zu erh\"{o}hen.
\ No newline at end of file
projects / bacula / docs / commitdiff