fillBD ist dafür gebaut, die Dateien in definierten Verzeichnissen
so zusammenzustellen, dass ein gemounteter RealCrypt-Container
möglichst maximal gefüllt wird - und vor allen Dingen auch dann,
wenn ausschließlich große Dateien (oberhalb von 500MB) zu sichern
sind.
Natürlich dürfen nicht alle Dateien exakt gleich groß sein. Denn
dann würden unterschiedliche Zusammenstellungen ja ziemlich wenig an
der Gesamt-Größe ändern. :-)
Beim Anlegen der RealCrypt-Container stelle ich immer die Größe
23000MB ein (das entspricht dann 24.931.450.880 Byte).
Allerdings hat jeder meiner Container einen eigenen und eindeutigen
Dateinamen, der der Nummer des Backup-Mediums entspricht. Daher wird
im Script kein fester Datei- oder Mountpoint-Name, sondern nur ein
Pfad eingestellt, unterhalb dessen der Container zu finden ist. Es
darf sich zum Zeitpunkt des Aufrufes von fillBD dort nur genau ein
Mount befinden. Sonst führt es zu einer Fehlermeldung:
Kein, oder mehr als ein MOUNT unter /300GB/tc
gefunden!
Die entsprechenden Pfade sind im Script an die eigenen Bedürfnisse
anzupassen.
Die Variable src_pth_g ist eine Liste
und enthält die Verzeichnisse, in denen sich die zu sichernden
Dateien befinden. Unterverzeichnisse in diesen Verzeichnissen werden
nicht unterstützt.
In der Variable dest_pth_g ist der Pfad
einzustellen, unterhalb dem der RealCrypt-Container gemountet wird.
Der gemountete Datenträger muß nicht komplett leer sein. Wenn dort
bereits Dateien liegen, die auch in den Verzeichnissen mit den zu
sichernden Dateien zu finden sind, werden diese Dateien
ausgeblendet. Diesen Umstand kann man dann nutzen, wenn es unter den
zu sichernden Dateien solche gibt, die nicht auf mehrere
Ziel-Datenträger verteilt werden sollen - die also zusammengehörig
sind. In diesem Fall werden die zusammengehörigen Dateien einfach
vorab auf den Ziel-Datenträger kopiert.
Mit dem Befehlszeilen-Parameter -d kann
ein Testlauf (ohne gemounteten Datenträger) gestartet werden.
Dabei werden dann die unter dest_defaults_kapazitaet
eingestellte Kapazität und unter dest_defaults_blockgroesse
eingestellte Blockgröße verwendet.
Anhand der angezeigten Restkapazität kann nun entschieden werden, ob
die vorliegende Menge zu sichernder Dateien es schon erlaubt, den
Ziel-Datenträger maximal zu füllen....oder ob man lieber noch auf
ein paar weitere zu sichernde Dateien wartet.
Mit dem Befehlszeilen-Parameter -v wird
eine Status-Anzeige zugeschaltet, die bei jeder besseren gefundenen
Datei-Zusammenstellung über die beteiligten Dateien und die
verbleibende Restkapazität informiert. Der Parameter -n zeigt jede getestete
Datei-Zusammenstellung...und ist eher etwas für Debug-Zwecke.
Beide Parameter sollten nicht genutzt werden, wenn viele zu
sichernde Dateien vorliegen. Pro Datei wird ein Zeichen (X oder -)
ausgegeben und alle zusammen sollten in einer Zeile angezeigt werden
[können], damit die Ausgabe sinnvoll lesbar ist. Notfalls kann man
die Ausgabe in eine Datei umleiten und sich diese dann mit einem
Editor ansehen, bei dem der Zeilenumbruch ausgeschaltet ist.
Ein Aufruf von fillBD erzeugt beispielsweise folgende Ausgabe (und
ist nach weniger als einer Sekunde fertig):
dede@c2q:~> fillBD.py -v
Kapazität auf dem Ziel: 23776 MB
Dateien: 26 Gesamtgröße: 33254 MB
-------------------------X 21 GB
------------------------XX 19 GB
-----------------------XXX 17 GB
----------------------XXXX 16 GB
---------------------XXXXX 14 GB
--------------------XXXXXX 12 GB
-------------------XXXXXXX 11 GB
------------------XXXXXXXX 9 GB
-----------------XXXXXXXXX 8 GB
----------------XXXXXXXXXX 6 GB
---------------XXXXXXXXXXX 5 GB
--------------XXXXXXXXXXXX 4 GB
-------------XXXXXXXXXXXXX 3 GB
------------XXXXXXXXXXXXXX 2 GB
-----------XXXXXXXXXXXXXXX 464 MB
X--------X--XXXXXXXXXXXXXX 104 KB
XX---X--X-XXX---XXXXXXXXXX 40 KB
-X--X-XX-XXX-X--X-XXXXXXXX 32 KB
XXXXX--X-X--XXX-X--XXXXXXX 16 KB
X--XXXXXXXX---X--XXX-XXXXX 8 KB
cd "/300GB/tc/Backup 846"
<<< diverse copy-Statements >>>
Zum Ausführen des CD- und der CP-Statements markiert man sie alle
mit der Maus und führt sie durch Druck auf das Scroll-Rad (bzw. die
mittlere Maustaste) alle zusammen nacheinander aus.
Ein abschließender Test mit df sollte
dann die berechnete Restkapazität anzeigen:
dede@c2q:/300GB/tc/Backup 846> df | grep
/tc/
/dev/mapper/realcrypt1 24347128
24347120 8
100% /300GB/tc/Backup 846
Anmerkung:
Der RealCrypt-Container sollte vorzugsweise mit vFAT formatiert
sein, damit die Restkapazität korrekt bestimmt werden kann.
Folgende Aufstellung zeigt die verfügbaren Kapazitäten von jeweils
5GB großen Containern:
dede@c2q:/tc> df -Th
Dateisystem
Typ Größe Benutzt Verf. Verw%
Eingehängt auf
/dev/mapper/realcrypt1 ext2
5,0G 10M 4,7G 1%
/tc/tst_ext2
/dev/mapper/realcrypt2 ext3
5,0G 139M 4,6G 3%
/tc/tst_ext3
/dev/mapper/realcrypt3 ext4
5,0G 138M 4,6G 3%
/tc/tst_ext4
/dev/mapper/realcrypt4 vfat
5,0G 4,0K 5,0G 1%
/tc/tst_fat
Zum einen hat man bei vFAT nicht diesen für root reservierten
Bereich und zum anderen kann man vFAT auch bis zum Anschlag füllen.
Meine Versuche mit ext3 und ext4 haben ergeben, dass ein
entsprechender Container trotz genügend Platz die letzte Datei nicht
mehr komplett aufnehmen wollte.
Und meine Versuche, diesen für root reservierten Bereich mittels
tune2fs freizugeben, haben überhaupt keinen Spaß gemacht. Das
Kopieren von Dateien in den "getunten" Container ging fürchterlich
langsam und ließ sich nicht einmal abbrechen oder via "kill -9"
abschießen. Ich habe schließlich meinen Rechner rebootet und als
auch das irgendwann nicht mehr weiter ging, resetet.....
Für Journaling-Dateisysteme kann der Parameter -j übergeben werden,
um für jede auf den Container zu kopierende Datei zusätzlich die
vierfache Blockgröße des jew. Dateisystems zu reservieren. Diesen
Aufschlag habe ich aber nur anhand von Tests festgelegt. Optimal
wirds damit sicher nicht. Ebenso wenig wird die von fillBD gefundene
Datei-Zusammenstellung garantiert und immer in den Container passen.
Um das zu umgehen, empfehle ich dringend die Verwendung von vFAT -
sofern man nicht Dateien sichern muß, von denen welche >4GB sind.