Gemstone/S - Datenbank > Gemstone - Crontabs, Backup, GC

Regelmäßige Aufgaben - crontabs

Unter Linux werden regelmäßig auszuführende Aufgaben als Jobs in einer sogenannten crontab-Datei definiert. Bei Gemstone fallen in der Regel mindestens drei Jobs an:

•Backups von der Gemstone Datenbank anlegen

•Alte Backups löschen

•Aufräumen in der Datenbank

Mit der installierten Runtime (pas/git/GsDevKit_stones) auf dem Server gibt es Templates (Unterverzeichnis "crontabs") für ein crontab unter Linux. Diese sollte den Gegebenheiten angepaßt werden und für den Anwender genutzt werden. Die Jobs sollten als Jobs des Anwenders laufen.

Hier ein Beispiel für ein crontab (für einen Benutzer "pas" in einer VM) - man beachte die Vorabdefinitionen. Diese setzen den richtigen Pfad.

# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
HOME=/home/pas

SHELL=/bin/bash

PAS_HOME_PATH=/home/pas/pas

PATH=/home/pas/pas/git/superDoit/bin:/home/pas/pas/git/GsDevKit_stones/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

STONES_DATA_HOME=/home/pas/pas/registry

10 15 * * * pas_cron_gc.sh es2025 work >/home/pas/cron.txt 2>&1

15 15 * * * pas_cron_backup.sh es2025 work /home/pas/pas/work/stones/es2025/backups

00 00 * * * find /home/pas/pas/work/stones/es2025/backups/* -mtime +7 -exec rm {} \;

Datenbank klein halten - Garbage Collector (GC)

Die Datenbanken von Gemstone mögen gerne wachsen, daher sollte das Garbage Collector-Skript ("pas_cron_gc.sh") regelmäßig ausgeführt werden:

pas_cron_gc.sh <stonename> <registry>

Bei den kostenlosen Lizenzen von Gemstone/S ist der Speichergröße begrenzt - daher muß man hier besonders auf Datenbankgröße achten. Es könnte in solchen Fällen sinnvoll sein, das Skript jede Stunde auszuführen.

Bei den kostenlosen Lizenzen ist auch die Anzahl der gleichzeitig ausgeführten Skripte begranzt - daher sollten sich die Skripte zeitlich nicht überlagern (was sowieso keine gute Idee ist).

Datenbank sichern

Oben im Template kann man auch einen Aufruf zum Sichern der Datenbank sehen (Fullbackup):

pas_cron_backup.sh <stonename> <registry> /datadisk/pas/<registry>/stones/<stonename>/backups

Wo das Backup abgelegt wird - das kann jeder für sich entscheiden.

Das Backup ist komprimiert und entspricht ungefähr 1/7 der aktuellen genutzten Repository-Größe. Wenn also das laufende Repository viel, viel größer ist, kann man daraus erkennen, das viel Leerraum in dem laufenden Repository vorhanden ist. Das kann passieren, wenn über längere Zeit der GC nicht lief.

Wenn die Backup-Skripte lauifen, sammeln sich Backups an. Das kann dann so aussehen:

-rw-rw-r-- 1 mf mf 160932372 Mai 26 01:00 2026_05_25_23_00-logid-10-linux_x86_64-<stonename>-30701.gz

-rw-rw-r-- 1 mf mf 160905115 Mai 27 01:00 2026_05_26_23_00-logid-10-linux_x86_64-<stonename>-30701.gz

-rw-rw-r-- 1 mf mf 161149285 Mai 28 01:00 2026_05_27_23_00-logid-10-linux_x86_64-<stonename>-30701.gz

-rw-rw-r-- 1 mf mf 160870238 Mai 29 01:00 2026_05_28_23_00-logid-10-linux_x86_64-<stonename>-30701.gz

-rw-rw-r-- 1 mf mf 161015542 Mai 30 01:00 2026_05_29_23_00-logid-10-linux_x86_64-<stonename>-30701.gz

-rw-rw-r-- 1 mf mf 161113908 Mai 31 01:00 2026_05_30_23_00-logid-10-linux_x86_64-<stonename>-30701.gz

-rw-rw-r-- 1 mf mf 161080377 Jun 1 01:00 2026_05_31_23_00-logid-10-linux_x86_64-<stonename>-30701.gz

-rw-rw-r-- 1 mf mf 160924973 Jun 2 01:00 2026_06_01_23_00-logid-10-linux_x86_64-<stonename>-30701.gz

Der Dateiname gibt Auskunft über die Plattform, auf der die Anwendung lief (linux_x86_64), den Namen der Datenbank und die Versionsnummer (3.7.1). Alles Informationen, die man beim Restore benötigt.

Die Datenbanken scheinen zwischen den Platformen austauschbar zu sein - WENN keine nativen externen Treiber genutzt werden (RabbitMQ oder PostgreSQL) - also praktisch nicht im ersten Schritt. Aber man kann die Datenbank auf einer anderen Platform installieren (z.B: Raspberry PI) und dann die Softwarepakete PostgreSQL und RabbitMQ erneut installieren. Dann sind auch die Pfade zu den externen Bibliotheken korrigiert.