Primavera P6 su Oracle XE: backup automatici con Data Pump, 7-Zip e Windows Task Scheduler

Come proteggere il database di Primavera P6 Professional 25.12 con esportazioni giornaliere e mensili, compressione automatica, rotazione degli archivi e verifiche di ripristino.

Introduzione

Nei primi due articoli di questa serie abbiamo visto come installare Primavera P6 Professional 25.12 su Oracle Database 21c Express Edition e come configurare un ambiente centralizzato, accessibile sia localmente sia attraverso una VPN.

Una volta completata l’installazione, rimane una questione fondamentale: come proteggere i dati di pianificazione dei progetti?

Per chi utilizza Primavera P6 nell’attività professionale, la perdita dei dati può significare molto più della semplice scomparsa di alcuni file. All’interno del database vengono conservati programmi lavori, attività, relazioni logiche, calendari, avanzamenti, risorse e altre informazioni necessarie alla gestione delle commesse.

Ho quindi deciso di predisporre un sistema di backup automatizzato sul computer che ospita Oracle XE.

La soluzione utilizza strumenti relativamente semplici:

Oracle Data Pump per esportare i dati applicativi;
7-Zip per comprimere gli archivi;
script batch di Windows per gestire le operazioni;
Utilità di pianificazione per eseguire i backup automaticamente;
una procedura di verifica per controllare che gli archivi siano utilizzabili.

L’obiettivo è ottenere due livelli di conservazione: gli ultimi dieci backup giornalieri e uno storico mensile.

Vediamo come.

1. L’architettura di partenza

Il sistema di riferimento utilizza Windows 11 e Oracle Database 21c Express Edition.

La configurazione è la seguente:

Componente	Configurazione
Spring	P6 Professional 25.12
Database	Oracle Database 21c XE
Istanza Oracle	XE
Pluggable Database	XEPDB1
Schema principale	ADMUSER
Listener	TCP 1521
Directory temporanea	C:\oracle_backup_stage
Archivio backup	D:\backup_Oracle
Programma di compressione	7-Zip

Il database è installato sul computer principale, mentre il disco D: viene utilizzato per conservare gli archivi compressi.

La scelta di una directory temporanea su C: deriva anche da un’esigenza pratica: nell’ambiente utilizzato, Oracle Data Pump dispone dei permessi necessari per scrivere correttamente in quella directory.

Non è una limitazione generale di Oracle XE: con gli opportuni permessi del sistema operativo è possibile utilizzare anche altri dischi.

Perché non esportare direttamente su D:?

Oracle Data Pump scrive i propri file attraverso un processo del server database, non attraverso il processo del Prompt dei comandi dell’utente.

Per questo motivo la directory deve essere accessibile all’account Windows che esegue il servizio Oracle.

Nella mia configurazione ho preferito mantenere una cartella temporanea dedicata e spostare i dati sul disco di archivio solo dopo aver completato correttamente l’esportazione.

È una soluzione semplice e facilmente verificabile.

2. Che cosa salva Oracle Data Pump?

Oracle Data Pump permette di esportare uno schema database in un file dump.

Nel nostro caso utilizziamo:

SCHEMAS=ADMUSER

Questo parametro indica a Oracle di esportare gli oggetti e i dati appartenenti allo schema principale Primavera P6.

Il file risultante ha estensione:

.dmp

L’operazione genera anche un file di log:

.log

È importante chiarire che Data Pump esegue un’esportazione logica, non una copia fisica dell’intero database Oracle.

Un export dello schema ADMUSER non contiene necessariamente tutti gli utenti tecnici, i privilegi, gli oggetti di altri schemi o la configurazione dell’istanza necessari a ricostruire un sistema P6 completo.

L’esportazione è quindi una componente importante della strategia di backup, ma non dovrebbe costituirne l’unico elemento.

3. Creare la cartella temporanea

La prima operazione consiste nel creare la directory che Oracle utilizzerà per scrivere i dump.

Nel mio ambiente:

C:\oracle_backup_stage

Dal Prompt dei comandi possiamo eseguire:

mkdir C:\oracle_backup_stage

Se la cartella esiste già, non occorre ricrearla.

Dobbiamo successivamente verificare che l’account del servizio Oracle disponga dei permessi di lettura e scrittura.

Questi permessi sono distinti da quelli configurati all’interno del database.

4. Configurare la directory Oracle

Apriamo SQL*Plus con privilegi amministrativi:

sqlplus / as sysdba

Selezioniamo il pluggable database corretto:

ALTER SESSION SET CONTAINER = XEPDB1;

Verifichiamo:

SHOW CON_NAME;

Il risultato atteso è:

XEPDB1

Creiamo quindi l’oggetto directory:

CREATE OR REPLACE DIRECTORY BACKUP_ORACLE
AS 'C:\oracle_backup_stage';

Assegniamo i privilegi necessari all’utente utilizzato per l’esportazione:

GRANT READ, WRITE ON DIRECTORY BACKUP_ORACLE
TO ADMUSER;

Per verificare la configurazione possiamo utilizzare:

SELECT
    DIRECTORY_NAME,
    DIRECTORY_PATH
FROM DBA_DIRECTORIES
WHERE DIRECTORY_NAME = 'BACKUP_ORACLE';

Il risultato dovrebbe riportare:

BACKUP_ORACLE    C:\oracle_backup_stage

Ricordiamo che creare una directory Oracle non significa creare automaticamente la cartella sul disco e non attribuisce permessi Windows al servizio.

Occorrono entrambe le configurazioni.

5. Eseguire il primo backup manuale

Prima di automatizzare qualunque operazione è indispensabile effettuare un test manuale.

Apriamo il Prompt dei comandi e utilizziamo il comando:

expdp admuser@//localhost:1521/XEPDB1 schemas=ADMUSER directory=BACKUP_ORACLE dumpfile=p6_test.dmp logfile=p6_test.log

Il sistema richiederà la password dell’utente Oracle.

Durante l’esecuzione vengono esportati gli oggetti dello schema.

Al termine verifichiamo che Data Pump abbia completato l’operazione senza errori.

All’interno di:

C:\oracle_backup_stage

dovrebbero essere presenti:

p6_test.dmp
p6_test.log

Questo è il primo controllo concreto: il database risponde, la directory è accessibile e i dati possono essere esportati.

Nel mio caso l’esportazione dello schema ADMUSER è stata completata correttamente.

Una precisazione sulla compressione Data Pump

Oracle Data Pump offre alcune opzioni di compressione interne, ma non tutte sono disponibili in ogni edizione del database.

Con Oracle XE l’utilizzo di:

COMPRESSION=ALL

ha restituito un errore relativo a un’opzione non disponibile.

Ho quindi scelto una soluzione alternativa: produrre il dump ordinario e comprimerlo successivamente con 7-Zip.

6. Installare e verificare 7-Zip

Per la compressione utilizziamo 7-Zip.

Nel mio computer il programma è installato in:

C:\Program Files\7-Zip\7z.exe

Possiamo verificare che funzioni eseguendo:

"C:\Program Files\7-Zip\7z.exe"

Il programma mostra le opzioni disponibili.

Per comprimere manualmente il dump di prova:

"C:\Program Files\7-Zip\7z.exe" a -t7z "D:\p6_test.7z" "C:\oracle_backup_stage\p6_test.dmp" "C:\oracle_backup_stage\p6_test.log"

Otterremo un archivio:

D:\p6_test.7z

contenente il dump e il log.

Per verificare l’integrità dell’archivio:

"C:\Program Files\7-Zip\7z.exe" t "D:\p6_test.7z"

Se il test termina correttamente, l’archivio compresso è leggibile.

Questo controllo non dimostra ancora che il contenuto potrà essere importato correttamente in Oracle, ma permette di individuare errori di compressione o archivi danneggiati.

7. Organizzare le directory dei backup

Ho scelto la seguente struttura:

D:\backup_Oracle
│
├── scripts
│   ├── p6_backup_daily.bat
│   ├── p6_backup_monthly.bat
│   └── p6_backup_common.bat
│
├── daily_10
│
├── monthly
│
└── logs

La cartella scripts contiene gli script batch.

daily_10 conserva gli ultimi dieci backup giornalieri.

monthly conserva i backup mensili storici.

logs raccoglie i registri delle esecuzioni.

Per creare le cartelle possiamo utilizzare:

mkdir D:\backup_Oracle\scripts
mkdir D:\backup_Oracle\daily_10
mkdir D:\backup_Oracle\monthly
mkdir D:\backup_Oracle\logs

La struttura permette di distinguere facilmente gli archivi ordinari da quelli storici.

8. Gestire le credenziali per i backup automatici

Prima di scrivere gli script occorre risolvere un problema fondamentale: un processo pianificato non può attendere che un operatore inserisca manualmente una password.

Il comando utilizzato per il backup manuale:

expdp admuser@//localhost:1521/XEPDB1 ...

è adatto alle prove interattive, ma può bloccarsi quando viene eseguito automaticamente.

Una soluzione consiste nell’utilizzare Oracle Secure External Password Store, che permette di memorizzare le credenziali in un wallet Oracle.

Una volta configurato il wallet e il relativo alias, si può avviare Data Pump attraverso un collegamento del tipo:

expdp userid=/@P6BACKUP ...

In questo esempio P6BACKUP è un alias di connessione associato al wallet.

La configurazione richiede che il client Oracle utilizzato dagli script possa accedere correttamente al wallet e che l’account Windows dell’attività pianificata disponga dei permessi necessari.

L’alias P6BACKUP non viene creato automaticamente: deve essere predisposto e verificato prima di usare gli script.

Per motivi di sicurezza è preferibile questa soluzione rispetto all’inserimento della password in chiaro all’interno di un file .bat.

La procedura seguente presuppone che il comando expdp userid=/@P6BACKUP sia già stato configurato e collaudato. In alternativa, si può adattare la parte di autenticazione a un altro metodo sicuro supportato dalla propria installazione Oracle.

9. Creare lo script di backup comune

Per evitare duplicazioni, utilizziamo uno script comune che riceve un parametro:

DAILY

oppure:

MONTHLY

Salviamo il seguente contenuto nel file:

D:\backup_Oracle\scripts\p6_backup_common.bat

Script batch

@echo off
setlocal EnableExtensions EnableDelayedExpansion

rem ==========================================
rem PRIMAVERA P6 - ORACLE XE BACKUP
rem Daily / Monthly
rem ==========================================

set "MODE=%~1"

if /I not "%MODE%"=="DAILY" if /I not "%MODE%"=="MONTHLY" (
    echo Modalita non valida: DAILY o MONTHLY
    exit /b 1
)

rem === CONFIGURAZIONE ===

set "ORACLE_HOME=C:\app\Andrea\product\21c\dbhomeXE"
set "STAGE=C:\oracle_backup_stage"
set "ROOT=D:\backup_Oracle"

set "SEVENZIP=C:\Program Files\7-Zip\7z.exe"

set "EXPDP=%ORACLE_HOME%\bin\expdp.exe"

rem === DATA E ORA ===

for /f %%A in ('powershell -NoProfile -Command "Get-Date -Format yyyy-MM-dd_HHmmss"') do set "STAMP=%%A"
for /f %%A in ('powershell -NoProfile -Command "Get-Date -Format yyyy-MM"') do set "MONTH=%%A"

if /I "%MODE%"=="DAILY" (
    set "DEST=%ROOT%\daily_10"
    set "NAME=P6_DAILY_%STAMP%"
) else (
    set "DEST=%ROOT%\monthly"
    set "NAME=P6_MONTHLY_%MONTH%"
)

set "DUMP=%NAME%.dmp"
set "EXPLOG=%NAME%.log"
set "ARCHIVE=%DEST%\%NAME%.7z"
set "RUNLOG=%ROOT%\logs\%NAME%_run.txt"

rem === CONTROLLI PRELIMINARI ===

if not exist "%EXPDP%" exit /b 10
if not exist "%SEVENZIP%" exit /b 11

if not exist "%STAGE%" mkdir "%STAGE%"
if not exist "%DEST%" mkdir "%DEST%"
if not exist "%ROOT%\logs" mkdir "%ROOT%\logs"

if exist "%ARCHIVE%" (
    echo Archivio gia esistente: %ARCHIVE%
    exit /b 12
)

echo Backup %MODE% > "%RUNLOG%"
echo Inizio: %DATE% %TIME% >> "%RUNLOG%"
echo Archivio: %ARCHIVE% >> "%RUNLOG%"

rem === ESPORTAZIONE ORACLE ===

"%EXPDP%" userid=/@P6BACKUP schemas=ADMUSER directory=BACKUP_ORACLE dumpfile=%DUMP% logfile=%EXPLOG% reuse_dumpfiles=NO >> "%RUNLOG%" 2>&1

set "RESULT=!ERRORLEVEL!"

if not "!RESULT!"=="0" (
    echo ERRORE: expdp terminato con codice !RESULT! >> "%RUNLOG%"
    exit /b 20
)

if not exist "%STAGE%\%DUMP%" (
    echo ERRORE: dump non trovato. >> "%RUNLOG%"
    exit /b 21
)

if not exist "%STAGE%\%EXPLOG%" (
    echo ERRORE: log Data Pump non trovato. >> "%RUNLOG%"
    exit /b 22
)

rem === COMPRESSIONE ===

"%SEVENZIP%" a -t7z -mx=5 "%ARCHIVE%" "%STAGE%\%DUMP%" "%STAGE%\%EXPLOG%" >> "%RUNLOG%" 2>&1

if errorlevel 1 (
    echo ERRORE durante la compressione. >> "%RUNLOG%"
    exit /b 30
)

rem === VERIFICA ARCHIVIO ===

"%SEVENZIP%" t "%ARCHIVE%" >> "%RUNLOG%" 2>&1

if errorlevel 1 (
    echo ERRORE nel test dell'archivio. >> "%RUNLOG%"
    exit /b 31
)

rem === PULIZIA TEMPORANEI ===

del /q "%STAGE%\%DUMP%"
del /q "%STAGE%\%EXPLOG%"

rem === ROTAZIONE GIORNALIERA ===

if /I "%MODE%"=="DAILY" (
    for /f "skip=10 delims=" %%F in ('dir /b /a-d /o-n "%ROOT%\daily_10\P6_DAILY_*.7z" 2^>nul') do (
        del /q "%ROOT%\daily_10\%%F"
    )
)

echo Backup completato: %DATE% %TIME% >> "%RUNLOG%"

exit /b 0

Come funziona

Lo script esegue le operazioni nell’ordine:

Controlla il parametro ricevuto.
Calcola il nome del backup.
Verifica la disponibilità degli eseguibili.
Esegue l’esportazione Oracle.
Verifica che il comando sia terminato correttamente.
Controlla la presenza del dump e del log.
Comprime i file con 7-Zip.
Esegue un test dell’archivio compresso.
Elimina i file temporanei.
Nel caso dei backup giornalieri conserva soltanto gli ultimi dieci archivi.

Se l’esportazione o la compressione non riescono, lo script termina senza cancellare automaticamente i file temporanei: in questo modo è possibile analizzare il problema.

Il file di log dell’esecuzione permette di ricostruire l’esito delle operazioni.

Lo script è un modello operativo migliorato rispetto alla prima implementazione e va collaudato nell’ambiente di destinazione prima di affidargli dati importanti.

10. Creare il backup giornaliero

Salviamo questo contenuto in:

D:\backup_Oracle\scripts\p6_backup_daily.bat

@echo off
call "D:\backup_Oracle\scripts\p6_backup_common.bat" DAILY
exit /b %ERRORLEVEL%

Lo script avvia il backup comune in modalità giornaliera.

Gli archivi vengono denominati automaticamente, per esempio:

P6_DAILY_2026-10-21_230000.7z

La presenza di data e ora evita conflitti fra esecuzioni effettuate nello stesso giorno.

I dieci archivi più recenti vengono conservati nella directory:

D:\backup_Oracle\daily_10

Gli eventuali archivi più vecchi vengono eliminati soltanto dopo il completamento e la verifica del nuovo archivio.

Questo consente di conservare diversi punti temporali di recupero.

11. Creare il backup mensile

Salviamo il secondo script in:

D:\backup_Oracle\scripts\p6_backup_monthly.bat

@echo off
call "D:\backup_Oracle\scripts\p6_backup_common.bat" MONTHLY
exit /b %ERRORLEVEL%

L’archivio mensile avrà un nome simile a:

P6_MONTHLY_2026-10.7z

Il file viene conservato nella directory:

D:\backup_Oracle\monthly

Diversamente dai backup giornalieri, non è prevista una cancellazione automatica degli archivi mensili.

La conservazione storica permette di recuperare dati appartenenti a periodi precedenti.

Lo script evita di sovrascrivere un archivio mensile già esistente. Se occorre ripetere il backup nello stesso mese bisogna quindi decidere come gestire l’archivio precedente, senza cancellarlo accidentalmente.

12. Eseguire le prime prove manuali

Prima di creare le attività pianificate, eseguiamo gli script manualmente.

Dal Prompt dei comandi:

D:\backup_Oracle\scripts\p6_backup_daily.bat

Al termine controlliamo:

D:\backup_Oracle\daily_10

Deve essere presente il file .7z.

Verifichiamo anche il log dell’esecuzione.

Ripetiamo successivamente:

D:\backup_Oracle\scripts\p6_backup_monthly.bat

Controlliamo la cartella:

D:\backup_Oracle\monthly

Anche in questo caso deve essere presente l’archivio compresso.

Controllare il codice di uscita

Dopo aver eseguito lo script nel Prompt dei comandi:

echo %ERRORLEVEL%

Il valore:

indica che lo script ha completato senza rilevare errori nei controlli implementati.

Un valore differente segnala un problema da analizzare.

È importante non confondere questo risultato con una verifica completa della recuperabilità del database: il test dell’archivio e il codice di uscita non sostituiscono una prova di importazione.

13. Programmare i backup con Windows Task Scheduler

Windows dispone già di uno strumento adatto a questo scopo: Utilità di pianificazione, chiamata anche Task Scheduler.

Per avviarla:

taskschd.msc

Creiamo una nuova attività.

Backup giornaliero

Nella scheda Generale inseriamo un nome descrittivo:

P6 Oracle - Backup giornaliero

Nella scheda Attivazione impostiamo un’esecuzione quotidiana, preferibilmente in un periodo di ridotta attività sul database.

Nella scheda Azioni selezioniamo:

Avvio programma

Programma:

C:\Windows\System32\cmd.exe

Argomenti:

/c "D:\backup_Oracle\scripts\p6_backup_daily.bat"

Directory iniziale:

D:\backup_Oracle\scripts

Backup mensile

Creiamo una seconda attività:

P6 Oracle - Backup mensile

Configurando l’esecuzione mensile.

Il comando sarà:

C:\Windows\System32\cmd.exe

Con gli argomenti:

/c "D:\backup_Oracle\scripts\p6_backup_monthly.bat"

Impostazioni importanti

Per entrambe le attività occorre verificare:

l’account Windows utilizzato per l’esecuzione;
l’accesso di tale account al wallet Oracle, se presente;
i permessi di scrittura sulle directory dei backup;
la possibilità di eseguire l’attività anche senza una sessione utente aperta;
la gestione delle attività non eseguite perché il computer era spento;
l’assenza di sovrapposizione fra esportazioni contemporanee.

Quest’ultimo aspetto merita attenzione: se il backup mensile è programmato nella stessa fascia oraria del giornaliero, le due attività potrebbero avviarsi contemporaneamente.

È preferibile differenziare gli orari o implementare un meccanismo di esclusione reciproca.

Dopo la configurazione, avviamo ciascuna attività manualmente dal Task Scheduler e controlliamo il codice di uscita riportato nell’ultima esecuzione.

14. Controllare periodicamente i backup

Un backup automatico non deve essere completamente dimenticato.

Consiglio di verificare almeno periodicamente:

Presenza degli archivi

Controllare che vengano creati regolarmente nuovi file.

Dimensione dei file

Variazioni significative delle dimensioni possono indicare modifiche al database, ma anche errori o esportazioni incomplete.

File di log

Verificare eventuali errori Oracle, problemi di accesso ai dischi e anomalie durante la compressione.

Spazio disponibile

La cartella mensile conserva i backup indefinitamente; occorre quindi monitorare lo spazio occupato.

Integrità degli archivi

Ripetere periodicamente il test con 7-Zip.

Recuperabilità dei dati

Eseguire prove di importazione su un ambiente separato.

La prova di ripristino è il controllo più importante.

15. Verificare il ripristino con Oracle Data Pump Import

Per controllare che un dump sia effettivamente importabile si può utilizzare Oracle Data Pump Import, cioè impdp.

È opportuno eseguire questi test su un database separato oppure su un ambiente di collaudo.

Non bisogna eseguire prove di ripristino distruttive sul database Primavera utilizzato per lavorare.

Estrarre il dump

Per prima cosa estraiamo il contenuto di uno degli archivi 7-Zip nella directory temporanea:

C:\oracle_backup_stage

Otterremo il dump e il relativo log.

Preparare l’ambiente di prova

Nella mia prima verifica ho utilizzato uno schema separato, denominato:

ADMTEST

Lo scopo era verificare che Data Pump riuscisse a leggere l’archivio e a creare gli oggetti in uno schema diverso dall’originale.

Per eseguire un test di questo tipo occorre predisporre preventivamente il nuovo utente Oracle, i tablespace e i privilegi necessari, senza modificare lo schema ADMUSER di produzione.

Eseguire l’importazione

Il comando utilizzato per il test è stato:

impdp admtest@//localhost:1521/XEPDB1 directory=BACKUP_ORACLE dumpfile=p6_backup.dmp logfile=restore_test.log remap_schema=ADMUSER:ADMTEST

Naturalmente bisogna sostituire p6_backup.dmp con il nome effettivo del dump estratto.

Il parametro:

REMAP_SCHEMA=ADMUSER:ADMTEST

indica a Data Pump di importare gli oggetti appartenenti allo schema originale ADMUSER all’interno dello schema di prova ADMTEST.

Risultato della verifica

Il test ha dimostrato che il dump era leggibile e che parte degli oggetti e dei dati poteva essere importata.

L’importazione ha tuttavia terminato con 93 errori, principalmente relativi ai privilegi di creazione di alcune viste e a oggetti dipendenti.

Questo risultato è utile, ma va interpretato correttamente.

Non costituisce una certificazione di ripristino completo di Primavera P6.

La rimappatura dello schema può inoltre produrre un ambiente diverso da quello previsto dall’applicazione, soprattutto in presenza di riferimenti fra schemi e configurazioni specifiche.

Il collaudo definitivo deve consistere nel ricostruire l’ambiente applicativo su un’installazione separata, importare i dati necessari e verificare l’effettiva apertura dei progetti attraverso Primavera P6.

16. Aggiungere un backup fisico con RMAN

Oracle mette a disposizione anche RMAN, Recovery Manager, per effettuare backup fisici del database.

La differenza rispetto a Data Pump è sostanziale.

Oracle Data Pump	Oracle RMAN
Esportazione logica	Backup fisico
Opera su schemi e oggetti	Opera su database e file fisici
Produce dump importabili	Produce backup set o copie
Utile per migrazione e recupero logico	Utile per ripristino del database
Non conserva l’intera istanza	Può proteggere l’intero database

RMAN è utilizzabile anche con Oracle Database Express Edition, nel rispetto delle caratteristiche della versione installata.

Per verificare la disponibilità dello strumento:

rman target /

Il comando deve essere eseguito con un account e in un ambiente dotati delle autorizzazioni richieste.

Un esempio di comando RMAN è:

BACKUP DATABASE PLUS ARCHIVELOG;

L’esecuzione concreta richiede però una configurazione coerente della modalità di archiviazione dei redo log, dei percorsi di backup e della politica di recupero.

In particolare, non è sufficiente copiare il comando in una sessione RMAN per ottenere automaticamente una strategia completa di disaster recovery.

In un’installazione professionale, Data Pump e RMAN possono essere utilizzati come strumenti complementari.

17. Conservare una copia dei backup fuori dal computer

Nell’architettura descritta, i backup vengono salvati su un secondo disco del computer principale.

Questa soluzione è utile contro alcune tipologie di guasto e permette di recuperare rapidamente gli archivi.

Non è tuttavia sufficiente a proteggere i dati da tutti gli scenari.

Un guasto elettrico, un furto, un ransomware o un incidente che coinvolga l’intero computer potrebbe compromettere sia il database sia gli archivi.

Per questo motivo è consigliabile conservare almeno una copia aggiuntiva:

su un dispositivo esterno scollegato dopo la copia;
su un NAS dotato di versionamento e credenziali separate;
su uno spazio cloud con cifratura e politiche di conservazione appropriate.

Nel caso di sincronizzazione cloud è importante ricordare che una cartella sincronizzata non è automaticamente un backup indipendente: eliminazioni e modifiche indesiderate possono propagarsi alle copie remote.

Una buona strategia è quella comunemente riassunta dalla regola 3-2-1: tre copie dei dati, su due supporti differenti, con almeno una copia fuori sede.

18. Procedura minima di disaster recovery

Immaginiamo che il computer principale diventi inutilizzabile e debba essere sostituito.

La sequenza di recupero, in linea generale, sarà:

Predisporre un nuovo computer Windows.
Installare una versione compatibile di Oracle Database.
Ricreare la struttura database necessaria a Primavera P6.
Installare e configurare la versione corrispondente di Primavera.
Recuperare gli archivi di backup.
Ripristinare il database mediante RMAN oppure ricostruire gli schemi e importare i dati con Data Pump, secondo la strategia adottata.
Ripristinare le configurazioni di connessione dell’applicativo.
Verificare utenti, calendari, risorse e progetti.
Aprire Primavera P6 e controllare la consistenza dei dati.

È importante predisporre preventivamente anche una copia protetta delle configurazioni necessarie al recupero: parametri Oracle, versioni software, impostazioni P6, account di servizio e procedure di autenticazione.

In assenza di queste informazioni il ripristino può diventare molto più complesso.

19. Quanto è affidabile questa soluzione?

La procedura adottata offre diversi vantaggi.

È basata su strumenti disponibili nell’ambiente Oracle e Windows, non richiede software di backup commerciali e permette di conservare uno storico degli export del database P6.

Tuttavia l’affidabilità non si misura soltanto dalla presenza dei file .7z.

Occorre distinguere tre livelli di verifica:

Primo livello: backup eseguito

Data Pump termina senza errori e produce il dump.

Secondo livello: archivio integro

7-Zip riesce a comprimere, leggere e verificare l’archivio.

Terzo livello: ripristino funzionale

Il database viene ricostruito in un ambiente di prova e Primavera P6 apre correttamente i progetti recuperati.

Soltanto il terzo livello dimostra che la procedura di recupero applicativo è effettivamente funzionante.

Nella configurazione descritta i primi due livelli sono stati verificati; il collaudo completo del terzo resta un’attività da perfezionare.

Conclusioni

Realizzare un sistema di backup automatico per Primavera P6 su Oracle Database 21c XE è possibile utilizzando strumenti già disponibili e senza introdurre un’infrastruttura particolarmente complessa.

Con Oracle Data Pump, 7-Zip e Utilità di pianificazione Windows possiamo:

esportare periodicamente lo schema applicativo;
comprimere i dump per ridurre lo spazio occupato;
mantenere gli ultimi dieci backup giornalieri;
conservare uno storico mensile;
registrare l’esito delle operazioni;
verificare periodicamente gli archivi prodotti.

La lezione più importante, tuttavia, è un’altra: avere dei backup non significa automaticamente essere in grado di ripristinare il sistema.

Per un ambiente destinato alla pianificazione e al controllo delle commesse è indispensabile prevedere una protezione a più livelli, con backup logici, backup fisici, conservazione esterna e prove periodiche di recupero.

È proprio questa combinazione che può trasformare una semplice installazione personale di Primavera P6 in un’infrastruttura affidabile per l’attività professionale.

Articolo basato su un’installazione reale di Primavera P6 Professional 25.12 con Oracle Database 21c Express Edition su Windows 11. Gli script riportati costituiscono un modello tecnico da adattare e collaudare prima dell’impiego in produzione. La configurazione sicura dell’autenticazione automatica e il test completo di disaster recovery sono prerequisiti essenziali per un utilizzo non presidiato.