Questions & Answers

[rbitdd]

English version below...

wir haben das Problem, das unser Plattenplatz immer knapper wird und wir überlegen, wie wir hier vielleicht etwas einsparen können.
Eine Kollegin hat mich darauf aufmerksam gemacht, das im Projektverzeichnis die hochgeladenen Feature-Dateien abgelegt werden und diese wohl auch im Backup landen. Können wir diese Zip-Dateien einfach löschen oder lauern dort "Gefahren" auf uns, wenn wir das machen?

Hat damit jemand Erfahrung? Freue mich auf Rückmeldungen.

Diana

-------------------

We have the problem that our disk space is becoming increasingly scarce and we are thinking about how we can perhaps save a little here.
A colleague pointed out to me that the uploaded feature files are stored in the project directory and that these also end up in the backup. Can we simply delete these zip files or are there "dangers" lurking there if we do this?

Does anyone have any experience with this? Looking forward to feedback.

Diana

[hoebbel]

Hallo Diana,

die Feature-Dateien, die Du ansprichst, sind die, die im LOCAL_PROJECT_SERVER_STORAGE gespeichert sind. Erreichbar beispielsweise über SiteArchitect->ContentTransport->Feature installieren->Storage-> den oben genannten auswählen. Oder in einem entsprechenden Auftragstask den oben genannten Storage verwenden.

Da die Konfiguration der Features woanders gespeichert wird, hat das Löschen erst einmal keinerlei Auswirkungen. Die Features stehen weiterhin zur Verfügung und werden bei Bedarf neu zusammengebaut.

Problematisch wird es wahrscheinlich aber, wenn zusätzlich die Archivierung genutzt wird. Wenn ein Feature nach dem Löschen der Dateien erneut angefordert wird, wird dies zu Fehlern führen, wenn benötigte Daten archiviert wurden. 

Da es sich bei den Dateien um technische Daten handelt, für die eine manuelle Manipulation nicht vorgesehen ist, prüfen wir allerdings nicht, was passiert, wenn man diese löscht. Die Ausführungen oben sind also (mehr oder weniger 😉  theoretischer Natur. Offiziell rate ich natürlich vom Löschen der Dateien ab 🙂

Ich hoffe, dass hilft Dir weiter
Holger

[aVogt]

Hallo Diana,

zum einen verwenden wir das "Protokoll aufräumen". Das bringt schon etwas.

Dann noch etwas spezielles bei uns:

[fsRoot]/log/schedule
Logs die älter als 1 Woche sind, werden nach Auftrag gezipt. Dann sieht man die zwar nicht mehr im Server-Manager, aber das wird hingenommen. War bisher noch nicht notwendig überhaupt nachzuweisen, dass ein Auftrag lief.
Nach weiteren zwei Wochen werden die ZIP Dateien gelöscht.
Da bestimmte Schedule-log-Dateien "unbedingt" länger aufbewahrt werden sollen, werden diese (nach dem zippen) auf einen anderen Server verschoben.

[fsRoot]/log/fs-clients*.log.gz
Die werden noch kürzer als in Aktionsvorlage "Protokoll aufräumen" aufbewahrt. Dafür ein spezielles Script geschrieben. Das sind aus meiner Sicht nur Logs von Aufrufen über Clients. Später nachzuvollziehen, warum vor einem Monat etwas gehakt hat ist meist nicht gerade sinnvoll.

Wird in einem Auftrag eine Vollgenerierung durchgeführt, gibt es am Ende noch einen Auftrag, der nur eine Seite generiert. Damit wird die vorherige Generierung gelöscht. Bringt auch Platz. Muss man nur berücksichtigen, dass Platz für die Vollgenerierung benötigt wird.

Dann Archivieren wir Projekte aller zwei-drei Jahre. Damit werden Projekte kleiner. Die Archivdatei wird dann auch auf einen anderen Server ausgelagert. Zusätzlich gilt "das CMS ist kein Archivsystem". Wenn etwas archiviert werden muss, landet es über Exporte in einem "wirklichen" Archivsystem.

Als Webbrowser nutzen wir Apache/Tomcat. Da gibt es auch Logs die regelmäßig gelöscht werden.

Muss halt intern festgelegt werden, wie lange Logfiles aufgehoben werden müssen.

Grüße
Andreas

[_田中_]

Siehe auch https://community.crownpeak.com/t5/Questions-Answers/FirstSpirit-Projekt-unn%C3%B6tige-Inhalte/m-p/3...

Wir löschen die Feature-ZIPs zum Beispiel, bevor wir ein Projekt exportieren (denn auch im Export landen die ZIPs), wenn sich da mal wieder etliche GB angesammelt haben (so wie im Link beschrieben in beiden Verzeichnissen). Probleme sind uns dabei keine bekannt.

Viele Grüße

Andreas