CoreProtect: cuánto historial conservar antes de purgar
Decide cuánto historial conservar en CoreProtect según el tiempo que necesita tu comunidad para comunicar e investigar incidentes. Después comprueba si el almacenamiento y el procedimiento de recuperación permiten mantener ese plazo. Antes de borrar registros, identifica la base de datos activa, conserva una copia recuperable y revisa si hay casos abiertos que todavía dependen de ellos. Un disco casi lleno exige actuar, pero es un mal momento para improvisar la política de moderación.
Esta guía se dirige a responsables de servidores con comunidad y equipos que encargan su operación técnica. Resuelve una decisión de mantenimiento, sin repetir un tutorial de rollback. Los ejemplos y las comprobaciones son propuestas de trabajo: no los hemos ejecutado en tu servidor ni hemos medido un benchmark de capacidad de CoreProtect.
Empieza por el plazo de investigación
Pregunta a los moderadores cuánto tardan realmente en llegar los avisos. Cuenta con jugadores que vuelven tras unos días fuera, problemas en construcciones compartidas y casos que pasan de un voluntario a otro. Acordad después un plazo de respuesta que el equipo pueda cumplir.
Puedes usar este modelo de planificación:
Historial necesario = demora máxima admitida para avisar + tiempo de investigación + margen operativo.
Una comunidad hipotética que acepta avisos hasta 14 días después del incidente, reserva siete días para investigarlos y añade nueve de margen necesitaría 30 días. Son decisiones de esa comunidad, no valores predeterminados de CoreProtect ni una recomendación universal. Si admitís reclamaciones más antiguas, el ejemplo se queda corto.
Define bien desde cuándo se cuenta: importa la antigüedad de la acción, no el día en que un moderador abre el caso. Revisad expresamente los casos pendientes antes del borrado programado. Cada excepción necesita un responsable y una fecha de revisión; de lo contrario, «guardarlo por ahora» acaba convirtiéndose en conservación indefinida.
Comprueba qué historial tienes realmente
CoreProtect permite ajustes de registro por mundo y exclusiones mediante blacklist.txt. Conservar datos más tiempo no recupera acciones que nunca se registraron. Contrasta los ajustes efectivos de cada mundo con la documentación de configuración.
Prepara un registro sencillo de cobertura. Anota para cada mundo qué incidentes promete investigar moderación, qué acciones necesita consultar y un ejemplo reciente y controlado que pueda localizar. Separa el lobby, los mundos survival y los del evento. Que una consulta funcione en el lobby no demuestra que haya cobertura en los demás.
Apunta la versión instalada del plugin, el motor de base de datos seleccionado, su ubicación o destino remoto y quién se ocupa de las copias. No incluyas credenciales. Otro compañero debe poder identificar el conjunto de datos correcto sin pegar una contraseña en una incidencia.
Si faltan resultados, aplaza el cambio de retención. Revisa mundo, identidad, intervalo de tiempo y configuración de registro antes de interpretar una consulta vacía como prueba de que no ocurrió nada.
Separa tres decisiones de mantenimiento
| Decisión | Pregunta que debes resolver | Evidencia que conviene guardar |
|---|---|---|
| Retención | ¿Hasta cuándo debe poder investigar moderación? | Plazo acordado y revisión de casos abiertos |
| Almacenamiento | ¿Puede el sistema mantener ese historial? | Crecimiento medido, espacio libre y margen de mantenimiento |
| Recuperación | ¿Puede el equipo consultar el historial conservado? | Ensayo satisfactorio en un entorno aislado |
Mide el almacenamiento de la base de datos y el espacio libre del sistema de archivos a intervalos comparables. Incluye algún periodo de evento con actividad. Anota si las copias comparten volumen con los datos activos. Estima cuándo alcanzarías tu propio mínimo de espacio libre y programa la intervención con tiempo para que alguien responda. Una muestra corta de días tranquilos no permite prometer capacidad de jugadores.
Distingue entre tamaño de la base activa, tamaño de las copias y espacio temporal para mantenimiento. Un plazo expresado en días no indica cuántos gigabytes necesita vuestra actividad concreta. Si el presupuesto no permite sostener la ventana de investigación acordada, resuelve esa discrepancia con el propietario antes de borrar pruebas.
Deja claro el límite de la purga
La referencia de comandos indica que t:30d en una purga elimina registros de más de 30 días. La recuperación de espacio depende del motor; #optimize no es un atajo universal. Comprueba tu versión antes de preparar la operación.
Pide al operador que escriba primero el propósito: «Eliminar el historial anterior al límite aprobado de estos mundos». Otra persona debe poder comparar esa frase con el comando previsto y la hora de ejecución. Anota la zona horaria utilizada para interpretar de forma coherente las fechas de los casos.
No hagas coincidir el primer cambio de retención con una migración de base de datos, una actualización del plugin y un reinicio del mundo desde cero. Separar cambios facilita evaluar el resultado. Si llega un incidente durante la preparación, permite que su responsable identifique qué pruebas necesita antes de continuar.
No incluimos un comando de borrado listo para ejecutar: su antigüedad y alcance deben salir del registro aprobado, no de copiar un artículo en la consola de producción.
Conserva un historial que puedas recuperar
Una copia del mundo no constituye por sí sola el plan de recuperación de CoreProtect. Incluye la base de datos del historial y su configuración en el inventario de recuperación. Si utilizas almacenamiento externo, acuerda una copia coherente de la base con quien opera ese servicio; no presupongas que está incluida al copiar la carpeta de Minecraft.
Cambiar database-type no transfiere el historial existente. CoreProtect describe la migración como una operación aparte, dependiente de la versión, con copia previa y validación en su guía de migración. Trata el cambio de motor como un mantenimiento independiente.
Antes de la primera purga, ensaya el acceso a una copia conservada en un entorno aislado. Comprueba un incidente antiguo conocido y una acción reciente controlada. Registra qué has encontrado, la fecha de la copia y cuánto has tardado en dejarla utilizable. La guía para ensayar una restauración de Minecraft ayuda a organizar ese ejercicio.
Mantén ese historial separado de los datos activos. Restaurar una copia antigua sobre producción solo para responder una consulta de moderación exigiría una decisión de recuperación independiente. Asigna también a los archivos conservados su propio plazo de retención y un responsable de acceso.
Entrega una lista de comprobaciones
Antes de autorizar el mantenimiento, exige respuestas a estas preguntas:
- ¿Qué plazo de aviso y qué casos pendientes se han revisado?
- ¿A qué base de datos y mundos afectará la operación?
- ¿Dónde está la copia de recuperación y cuándo se comprobó que servía?
- ¿Quién ejecuta, quién revisa y en qué horario pueden responder?
- ¿Qué registros recientes y antiguos se comprobarán después?
- ¿Qué obliga a detener el trabajo si fallan las pruebas, la copia o las previsiones de espacio?
Al terminar, comprueba el historial retenido y una acción nueva controlada, revisa errores y mide el espacio real. Documenta el resultado aunque el archivo apenas cambie de tamaño. Ajusta la siguiente planificación con observaciones, sin dar por hecho cuánto espacio recuperarás.
Si necesitas incluir este trabajo en un encargo de infraestructura, envía a Mineando las versiones, la lista de mundos, el plazo de investigación y el sistema de copias actual. La infraestructura gestionada para Minecraft se presupuesta con alcance individual; las responsabilidades de mantenimiento y la cobertura de soporte se acuerdan por separado.
