Files
termanager2/app/Http/Controllers/Settings/BackupController.php
2026-07-29 14:26:36 +02:00

117 lines
4.5 KiB
PHP

<?php
namespace App\Http\Controllers\Settings;
use App\Http\Controllers\Controller;
use App\Jobs\CreateBackupArchive;
use App\Jobs\RestoreBackupArchive;
use App\Services\BackupOperationState;
use Illuminate\Http\Request;
use Illuminate\Support\Str;
/**
* Trasferimento dei file di backup: consegna dell'archivio prodotto e
* ricezione di quello da ripristinare.
*
* Non e' un componente Livewire come il resto della pagina: lo `streamDownload`
* di Livewire passa il file base64 dentro la risposta JSON, e un archivio con
* tutti i PDF dei territori non ci sta. L'avvio delle operazioni e la barra di
* avanzamento vivono invece in Livewire\Settings\BackupManager, che interroga
* BackupOperationState. Entrambe le rotte sono nel gruppo `settings.manage`.
*/
class BackupController extends Controller
{
public function __construct(
private readonly BackupOperationState $stato,
) {
}
/**
* Consegna l'archivio prodotto da un'operazione di backup e annota che e'
* stato servito.
*
* L'annotazione e' meta' del blocco che protegge l'azzeramento: senza un
* `servito_at` il pulsante di conferma rifiuta di procedere, quindi non
* esiste una strada che cancelli i dati senza che l'archivio sia almeno
* uscito dal server. L'altra meta' e' la conferma umana in
* BackupManager::confermaAzzeramento().
*
* Il completamento del trasferimento *non* e' verificabile da qui: con
* `fastcgi_buffering on` (il default, e docker/nginx/default.conf non lo
* disattiva) nginx accetta l'intera risposta dal processo PHP e la inoltra
* per conto suo. PHP finisce di scrivere e prosegue anche se il browser ha
* chiuso la connessione al primo byte, quindi far scattare l'azzeramento
* "dopo l'ultimo byte" azzererebbe anche su un download annullato.
*/
public function file(string $operationId)
{
$operazione = $this->stato->get($operationId);
abort_if($operazione === null, 404, 'Backup non piu\' disponibile: rigeneralo.');
$percorso = CreateBackupArchive::percorso($operationId);
abort_unless(is_file($percorso), 404, 'Archivio di backup non trovato: rigeneralo.');
$nome = $operazione['result']['nome_download'] ?? 'termanager2-backup.zip';
$this->stato->update($operationId, function (array $state) {
$state['result']['servito_at'] = now()->toDateTimeString();
return $state;
});
return response()
->download($percorso, $nome, [
'Content-Type' => 'application/zip',
'Content-Length' => (string) filesize($percorso),
]);
}
/**
* Riceve il pacchetto da ripristinare e mette in coda il lavoro.
*
* Risponde JSON perche' il form viene inviato via XMLHttpRequest: e' l'unico
* modo di avere una barra di caricamento reale sull'upload, che per un
* archivio di centinaia di MB e' la parte piu' lunga dell'operazione.
*/
public function upload(Request $request)
{
// 256 MB e' il tetto reale della pila, non una scelta di questa
// validazione: piu' in su intervengono prima `client_max_body_size` di
// nginx e `upload_max_filesize`/`post_max_size` di PHP, che rifiutano
// la richiesta con un 413 opaco invece di un messaggio leggibile.
$request->validate([
'backupZip' => ['required', 'file', 'mimes:zip', 'max:256000'],
], [
'backupZip.required' => 'Seleziona il pacchetto di backup da ripristinare.',
'backupZip.mimes' => 'Il pacchetto di backup deve essere un file .zip.',
'backupZip.max' => 'Il pacchetto supera i 256 MB accettati dal server.',
]);
$operationId = (string) Str::uuid();
// Il file dell'upload vive in una cartella temporanea che sparisce a
// fine richiesta: il job lo troverebbe gia' cancellato.
$percorso = $request->file('backupZip')->storeAs(
'backup-restore-in',
$operationId . '.zip',
'local'
);
$this->stato->initialize(
$operationId,
BackupOperationState::TIPO_RESTORE,
'In coda'
);
$this->stato->log($operationId, 'Archivio ricevuto. In attesa del worker di coda.');
RestoreBackupArchive::dispatch(
$operationId,
storage_path('app/' . $percorso),
(int) auth()->id()
);
return response()->json(['operation_id' => $operationId]);
}
}