Alessandro ma l’immagine che hai allegato è quella prima del run del tuo script?
Perchè vista così sembrerebbe mantenere gli ultimi 10 archivi così come da https://www.veeam.com/kb1825
Probabilmente non la trovi perchè sei in SSH con l’utente veeamadmin e il logrotate è per root (sto ipotizzando)?
ciao, giusto appunto!!! Comunque logrotate non varia per utente (come fa ad esempio crontab), c’è una configurazione di default in
/etc/logrotate.conf
e poi quelle specifiche in
/etc/logrotate.d
come dedurrei dalla KB che hai richiamato, sembra che la rotazione sia gestita “in autonomia” dai servizi Veeam. Ad esempio in questo caso la soluzione alternativa a quella che ho fatto io sarebbe
This value is not present in the configuration file by default and may need to be manually created.
If the /etc/VeeamAgentConfig file is not present on the Linux machine, you must first create it.
As an individual log file grows larger than the maximum size, a new generation of log files is created. This setting controls the maximum number of generations of agent log files to be retained.
Example: Agent.DC.Source.DC.1.log, Agent.DC.Source.DC.2.log,Agent.DC.Source.DC.3.log, etc.
Config File Location: /etc/VeeamAgentConfig
Entry Name: AgentMaxLogCount
Data: <numeric value>
Default: 10
Example: AgentMaxLogCount=5
(per essere un po’ pignoli, la KB ben dettagliata ma non specifica ownership/permissions del file da creare ma è sensato che di root ma leggibile a tutti vada benone)
Ok. Hai ragione per il logrotate… volevo appunto riferirmi al crontab dove forse ci sono script proprietari di Veeam.
Non ho sotto mano il lab quindi non posso controllare.
Mi preme sottolineare una cosa però.
La riduzione dei log da mantenere stride con quelle che sono le logiche di troubleshooting. Io sono sempre dell’idea che non bisogna mai sottostimare le folder dei log oppure la folder dei Tlog di Oracle. Sai quante volte ho dovuto spiegare che deve poter mantenere anche fino a 5 gg di log perchè se si bloccasse il backup durante un fine settimana lungo si bloccherebbe il DB ove non ci fosse la giusta capienza?
Perciò io dico che la soluzione di ridurre il numero dei log è fine a se stessa e potresti ritrovarti a dover ridurre ancora i log perchè sempre troppo grandi.
sì verissimo, in caso però di un server che logga decine di giga diventa buona idea spostarli su un’altro mountpoint dedicato, che non sia /
La kb da uno script bash già pronto per fare lo spostamento.
Per quel che riguarda i log dei DB di produzione, ci ho “litigato” qualche volta con qualcuno che non voleva capire che, se un sistema di produzione si blocca perché quello di backup rimane fermo per sole 24-48 ore, c’è qualcosa da rivedere.
