Uno scheduler attività server ti permette di automatizzare riavvii, backup, comandi ed eventi direttamente dal pannello o via API: crei una schedule con sintassi cron, aggiungi task di tipo backup, command o power e usi il time_offset per incatenarli in una sequenza sicura. Su un pannello Pterodactyl bastano pochi minuti per impostare un riavvio notturno con backup e avviso ai giocatori. Questa logica può essere integrata in un pannello personalizzato pensato per chi gestisce server di gioco senza tempo da perdere in configurazioni manuali.
In breve:
- È fondamentale misurare la durata media dei backup per impostare correttamente il parametro
time_offsete evitare interruzioni o riavvii incompleti.- La scelta della frequenza di backup dipende dal livello di traffico del server: ogni 4-6 ore per server attivi, quotidiani per traffico moderato e settimanali per poco traffico.
- Problemi di schedule spesso derivano dal processo di gestione delle code che può bloccarsi, soprattutto in ambienti Docker, richiedendo controlli sui log e spazio disco.
- L’automazione tramite schedule riduce errori umani e permette di pianificare riavvii e backup senza intervento manuale, migliorando l’affidabilità del servizio.
- Un pannello personalizzato di gestione e supporto tecnico dedicato permette di semplificare l’implementazione e risolvere rapidamente eventuali disfunzioni di schedule o backup.
Indice
- Come funziona una schedule: cron, task e time_offset
- Modelli pronti per riavvii, backup ed eventi
- Come creare schedule via API: cURL, Node.js e Python
- Regole pratiche per evitare backup rotti e riavvii mal calcolati
- Perché una schedule non parte (o fallisce a metà)
- Il punto di vista di Fabio Turi sull’automazione dei server
- Con un servizio professionale, schedule e backup possono essere gestiti senza pensieri
- Documentazione e guide utili
- Fonti
- Domande frequenti
Come funziona una schedule: cron, task e time_offset
Una schedule si basa su un’espressione cron a cinque campi: minuto, ora, giorno del mese, mese, giorno della settimana. Scrivere 0 4 * * * significa «ogni giorno alle 4:00»; 0 */6 * * * significa «ogni sei ore». Non serve altro per definire quando una schedule si attiva.
Dentro ogni schedule inserisci uno o più task, e ognuno ha un tipo preciso. Le schedule di Pterodactyl supportano tre tipi di task:
- Command: invia un comando alla console del server, utile per messaggi di avviso o azioni di gioco.
- Power: esegue un’azione di alimentazione (restart, stop, start, kill).
- Backup: crea un backup dei file del server, con esclusioni configurabili.
Il parametro time_offset stabilisce quanti secondi attendere prima di eseguire il task successivo nella sequenza, non prima della schedule stessa. È lo strumento che trasforma una lista di comandi isolati in una vera catena logica: prima avvisi i giocatori, poi salvi il mondo, poi fai il backup, infine riavvii.
La flag only_when_online decide se il task gira solo mentre il server è acceso. Impostala su true per backup e comandi che hanno senso solo a server attivo; lasciala su false per azioni come l’avvio automatico di un server fermo. Ignorare questa distinzione è una causa comune di schedule che sembrano “non fare nulla” quando in realtà stanno semplicemente aspettando le condizioni giuste.
Modelli pronti per riavvii, backup ed eventi
Le guide della community, incluse quelle di PteroCA, offrono schemi collaudati che puoi replicare quasi senza modifiche. Ecco tre configurazioni che coprono la maggior parte delle esigenze reali:
- Riavvio notturno con backup: cron
0 4 * * *. Sequenza task: comando di avviso ai giocatori (time_offset 0), comandosave-all(time_offset 30), backup (time_offset 60), azione power restart (time_offset 300, calcolato in base alla durata media del backup). - Backup automatico ogni 4/6 ore: cron
0 */4 * * *per server molto attivi,0 */6 * * *per server con traffico moderato. Nessun riavvio associato, solo il task backup cononly_when_onlineattivo. - Evento del weekend: cron
0 20 * * 6per un evento ogni sabato alle 20:00, con un comando che attiva una modalità di gioco speciale o un annuncio broadcast.
Un dato pratico da tenere a mente: le stesse guide raccomandano backup ogni 4-6 ore per i server ad alta attività, giornalieri per quelli medi e settimanali per i server con poco traffico. Il criterio non è la comodità dell’amministratore ma il volume di dati che rischi di perdere tra un salvataggio e l’altro.
Come creare schedule via API: cURL, Node.js e Python
Il pannello espone endpoint dedicati che permettono di gestire le schedule senza passare dall’interfaccia grafica, utile se vuoi integrare la schedulazione in uno script esterno o in una pipeline di deploy. Gli endpoint principali, secondo la documentazione API di Pterodactyl, sono:
GET /api/client/servers/{server}/schedulesper elencare le schedule esistenti.POST /api/client/servers/{server}/schedulesper crearne una nuova.POST /api/client/servers/{server}/schedules/{schedule}/tasksper aggiungere un task a una schedule.POST /api/client/servers/{server}/schedules/{schedule}/executeper forzare l’esecuzione immediata.
Un esempio cURL per creare un task di backup su una schedule esistente:
curl -X POST "https://pannello.tuosito.it/api/client/servers/{server}/schedules/{schedule}/tasks" \
-H "Authorization: Bearer TUA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"action":"backup","payload":"","time_offset":60,"continue_on_failure":false}'
In Node.js o Python la logica è identica: una chiamata HTTP con lo stesso corpo JSON, seguita dalla lettura della risposta per verificare che il task sia stato creato correttamente. Il body accetta i campi action, payload, time_offset e continue_on_failure, quest’ultimo utile per decidere se la sequenza deve fermarsi in caso di errore su un task.
Le API non servono solo a programmare task interni: permettono di collegare la schedulazione a sistemi esterni, script di CI/CD o webhook di monitoraggio, trasformando il pannello in un tassello di un flusso di automazione più ampio.
Non esporre mai la tua API key in repository pubblici o in script condivisi. Usa chiavi con permessi minimi, limitate alle sole azioni necessarie, e tieni un log delle chiamate per capire chi ha modificato cosa in caso di problemi.
Regole pratiche per evitare backup rotti e riavvii mal calcolati
Il time_offset sbagliato è la causa più comune di backup interrotti o riavvii che tagliano fuori un salvataggio a metà. La regola pratica: misura quanto dura in media il tuo backup, poi aggiungi un margine di sicurezza di 30-60 secondi prima di far partire il task successivo.
Non sovrapporre mai operazioni pesanti. Lascia 10-15 minuti tra un backup completo e un riavvio, soprattutto su mondi di grandi dimensioni dove il tempo di scrittura su disco può variare parecchio da una sessione all’altra.
Sulla frequenza dei backup vale lo stesso principio già visto: più il server è attivo, più spesso serve salvare, con un intervallo di 4-6 ore per le community più numerose, secondo le linee guida sulle schedule di Pterodactyl. Prima di distribuire una nuova sequenza di task su un server in produzione, testala su un’istanza di prova: un errore di sintassi cron scoperto in staging costa cinque minuti, lo stesso errore scoperto in produzione può costare un intero mondo di gioco.
Un consiglio: tieni un foglio con i tempi medi di backup misurati su ogni tuo server: variano molto in base alla dimensione del mondo, e riusarli per calcolare il time_offset ti evita sorprese.
Per policy di backup più strutturate, una guida su backup remoto per server di gioco approfondisce come impostare copie ridondanti oltre alla schedula locale.
Perché una schedule non parte (o fallisce a metà)
Quando una schedule sembra ferma, il primo sospetto è il processo che esegue le code in background: se il comando che invoca le schedule non gira correttamente nel container o nell’host, nessun task parte, anche se la configurazione è corretta. Le discussioni tecniche sul pannello segnalano che in ambienti Docker questo processo può bloccarsi dopo un crash o un riavvio del container.
Passi da controllare, in ordine:
- Verifica che il processo di esecuzione delle code sia attivo sul container o sull’host.
- Fai un flush della cache o di Redis se le schedule restano bloccate senza motivo apparente.
- Controlla i log del pannello e delle code per errori espliciti di permessi o timeout.
- Se un backup fallisce, verifica prima lo spazio disco disponibile e la quota di backup assegnata, poi valuta un retry manuale.
Il punto di vista di Fabio Turi sull’automazione dei server
L’automazione riduce gli errori umani in modo diretto: un riavvio dimenticato alle tre di notte è un problema, uno schedulato non lo è mai. La regola che conta di più resta la più noiosa: testa ogni sequenza prima di lasciarla girare da sola, e documenta cosa fa e perché.
— Fabio Turi
Con un servizio professionale, schedule e backup possono essere gestiti senza pensieri
Configurare schedule cron, calcolare time_offset e monitorare i log richiede tempo che molti gestori di server semplicemente non hanno. Questo problema può essere affrontato con un pannello Pterodactyl personalizzato dotato di moduli che semplificano la creazione delle schedule, oltre a backup automatici quotidiani già inclusi, così non dipendi solo dalla schedula che configuri tu.
Se una sequenza di task va storta o un backup non parte come previsto, il supporto tecnico via Discord risponde nei giorni lavorativi con indicazioni concrete, non con risposte standard copiate da un manuale. È la differenza tra risolvere un problema in dieci minuti o passare la serata a leggere log da soli. Attiva un server su AtomSync e imposta la prima schedule automatica in meno di un’ora, oppure consulta la pagina Garry’s Mod se cerchi un piano specifico per quel titolo.
Documentazione e guide utili
Per approfondire la sintassi delle schedule consulta la documentazione Pterodactyl e la guida API su GitHub. Per la gestione pratica del pannello, la nostra guida completa a Pterodactyl copre passo passo l’interfaccia. Salva questi link: tornano utili in fase di troubleshooting.
Fonti
- Task Scheduling — Pterodactyl (mintlify)
- Server Schedules | PteroCA Documentation
- Pterodactyl panel discussion — schedule:run (GitHub PR)
Domande frequenti
Cos’è uno scheduler attività server?
È la funzione del pannello (o della sua API) che permette di programmare azioni ricorrenti sul server, come backup, riavvii, comandi ed eventi, usando espressioni cron.
Come funziona il time_offset in una schedule?
Il time_offset stabilisce quanti secondi attendere prima di eseguire un task rispetto al precedente nella stessa sequenza, non rispetto all’orario di avvio della schedule.
Ogni quanto conviene fare un backup automatico?
Per server molto attivi conviene un backup ogni 4-6 ore; per server con traffico medio va bene una frequenza giornaliera, mentre quelli con poco traffico possono limitarsi a un backup settimanale.
Perché una schedule non si esegue in ambiente Docker?
Spesso il processo che invoca le code in background non è attivo o si è bloccato dopo un crash del container: verificarlo e fare un flush della cache risolve la maggior parte dei casi.
AtomSync gestisce già i backup automatici?
Sì, AtomSync include backup automatici quotidiani nel pannello Pterodactyl personalizzato, oltre a moduli dedicati che semplificano la creazione di schedule per riavvii e comandi.