# Cutover produção (IPCAM ↔ iVMS-4000)

**Este documento não executa o cutover.** É o procedimento para quando o servidor de produção, os HDDs e a VLAN existirem.

Neste lab (`evo`, 10.10.15.74) o cutover está **proibido**: não há Windows/iVMS acessível, não há HDD físico, as câmeras `192.168.20.x` não respondem daqui. Não ligue gravação nas 60 `Carga *` nem nas 192.168.20.x neste host.

Ferramenta: `php artisan ipcam:cutover-check` — só lê estado. **Não** liga `recording_enabled`, **não** para o iVMS, **não** formata disco.

## Portões (todos bloqueantes em verde)

```bash
cd /var/www/html/ipcam/apps/panel
php artisan ipcam:cutover-check
php artisan ipcam:export-cameras
```

| Portão | Como cumprir |
|---|---|
| FFmpeg | Pacote `ffmpeg` no PATH |
| Storage fora do webroot | `IPCAM_STORAGE_ROOT=/storage` |
| Discos com UUID | `fs_uuid` no cadastro + mount por UUID em `/etc/fstab` |
| Filesystem independente | Cada HDD no próprio mount; **sem RAID 0/1, sem LVM spanning** |
| Câmeras reais | RTSP (não `lavfi:`), host ≠ localhost; mínimo `IPCAM_CUTOVER_MIN_CAMERAS` (default 3) |
| Carga simulada off | Nenhuma `Carga *` com gravação ligada |
| Export iVMS | Arquivo em `IPCAM_IVMS_EXPORT_PATH` (cópia da config/lista do iVMS-4000) |
| NVR reserva | `IPCAM_NVR_RESERVE=true` **só** depois de confirmar equipamento na janela |
| Mídia de rollback | ISO Windows + instalador iVMS em `IPCAM_ROLLBACK_MEDIA_PATH` |

Enquanto o checker disser NO-GO, **não** desligue o iVMS e **não** formate o Windows.

## Antes de tocar no Windows

1. Exportar lista/config de câmeras no iVMS-4000 (arquivo de backup do próprio software).
2. Copiar esse arquivo para o Linux: `IPCAM_IVMS_EXPORT_PATH`.
3. `php artisan ipcam:export-cameras` (inventário IPCAM **sem senhas**).
4. Guardar senhas das câmeras **fora do git**.
5. Confirmar NVR reserva na janela (sim/não — dado operacional, não inventar).
6. Separar mídia de reinstall (Windows + iVMS) em disco/USB que não será formatado.
7. Anotar UUID dos HDDs de gravação (`blkid`) **antes** de qualquer format.

## Ordem no servidor de produção

O roteiro original: testes 1–11 → Ubuntu no servidor → mounts UUID → serviços → deploy → cadastro das câmeras → validação → **só então** desligar iVMS.

1. Instalar Ubuntu LTS no hardware de produção (não neste lab).
2. Montar cada HDD em `/storage/disk01`, `/storage/disk02`, … por **UUID** no fstab. Discos independentes.
3. PostgreSQL, PHP 8.3, FFmpeg, Apache/Nginx, copiar o código.
4. `.env` a partir de `deploy/env/.env.production.example` (secrets só no servidor).
5. Instalar units: `ipcam-recorder`, `ipcam-monitor`, `ipcam-live`, `ipcam-retention`, `ipcam-events` (`User=www-data`). **Não** dependem do Apache.
6. Cadastrar câmeras reais (ONVIF → RTSP → URL manual). Não copiar `if fabricante`.
7. `IPCAM_RECORDER_MAX_FFMPEG` ≥ o lote que você vai ligar (neste lab o teto é 8; produção exemplo 64).
8. Checker em verde.
9. Ligar gravação em **lote pequeno** (1, depois 3, depois o teto). Conferir `/saude` e `ipcam:load-report` (SLA ≥ 95% das habilitadas).
10. Só depois de 24 h estáveis no lote: ampliar. Só depois da frota estável: desligar o serviço de gravação do iVMS.

**Não** ligue 60 FFmpeg de uma vez sem medir CPU/I/O nesse hardware.

Reencode 8–30 dias: **NO-GO** no lab (Fase 12). Em produção, retenção = `IPCAM_RETENTION_DAYS` (idade/espaço), sem worker de reencode.

## O que este cutover não faz

- Não importa o histórico do iVMS para o IPCAM.
- Não compacta MP4 em zip.
- Não substitui o Recorder pelo painel Laravel.

Rollback: [`ROLLBACK.md`](ROLLBACK.md).