Actualizar Paper: cuándo reabrir y cuándo recuperar
Reabre un servidor Paper tras una actualización solo cuando funcionen los recorridos de jugador acordados, las versiones instaladas coincidan con las ensayadas y una persona responsable acepte las limitaciones pendientes. Fija antes del mantenimiento la hora límite para decidir la recuperación. Poder conectarse no demuestra que los permisos, los datos de los plugins o las funciones de la comunidad sigan bien.
Esta guía permite a propietarios de comunidades establecidas acordar la reapertura con su equipo técnico o con quien ejecute el encargo. Se centra en actualizaciones planificadas de Paper y plugins. Es un procedimiento propuesto: Mineando no ha ejecutado estas pruebas ni certifica aquí la compatibilidad de ningún plugin concreto.
Delimita un cambio que puedas revisar
Prepara una ficha breve: versión actual de Minecraft, build de Paper, Java, versiones de plugins, versiones de destino, motivo y responsable del mantenimiento. Incluye dependencias y almacenamiento externo de los plugins esenciales. No describas el destino solo como «la última versión»: puede salir otra entre el ensayo y la intervención.
Distingue una actualización de build de Paper dentro de la misma versión de Minecraft de un salto de versión de Minecraft. Ambas requieren comprobaciones, pero la segunda puede ampliar la revisión de compatibilidad. Si una dependencia obliga a cambiar varios componentes juntos, documéntalos como una misma entrega. Deja los ajustes ajenos y las funciones nuevas para otro cambio.
Contrasta Java con la tabla de versiones de Paper. Actualmente indica Java 21 para Minecraft 1.20–1.21.11 y Java 25 para 26.1+. Registra el entorno que utiliza realmente el servicio, no solo el que aparece en la terminal del administrador.
Para cada plugin imprescindible, guarda la declaración de compatibilidad del mantenedor y las notas de la versión propuesta. Si falta información, anótala como desconocida. Que siga disponible una descarga no demuestra compatibilidad con vuestra combinación.
Calcula la hora límite desde la reapertura
Reserva tiempo para recuperar y verificar antes de repartir el margen de diagnóstico. Puedes usar esta regla de planificación:
Hora límite para decidir la recuperación = reapertura prevista − duración ensayada de recuperación − tiempo de verificación − margen.
Un ejemplo puramente hipotético: queréis abrir a las 20:00, el ensayo representativo de recuperación duró 25 minutos, necesitáis 15 para verificar y reserváis otros 10 de margen. La decisión corresponde a las 19:10. Son cifras inventadas para explicar el cálculo, no mediciones de capacidad ni compromisos de disponibilidad de Mineando.
Si a esa hora queda una comprobación bloqueante sin resolver, iniciad la recuperación acordada o ampliad expresamente el mantenimiento. No gastéis en silencio la reserva probando «un ajuste más». Definid cómo informaréis a la comunidad y quién puede modificar la hora de apertura.
Sin una restauración previa de este entorno, desconocéis cuánto tardará. Haced un ensayo aislado de restauración antes de depender de una ventana ajustada. Aquí usamos su resultado para decidir; no repetimos el procedimiento de recuperación.
Ensaya la entrega exacta en una copia separada
Prepara una copia con mundos y datos de plugins representativos. Limita el acceso a las personas que probarán y evita que escriba en bases de datos, webhooks u otras integraciones de producción. Anota lo que desactives para aislarla: no debe terminar marcado como comprobado por accidente.
Aplica la entrega candidata, incluidos los cambios de configuración previstos, a esa copia. Conserva juntos el inventario de software y los resultados. Si cambias después un plugin, repite las pruebas afectadas y las de sus dependencias; el ensayo de ayer no aprueba una entrega distinta hoy.
La guía de actualización de Paper advierte contra sustituir JAR activos y recomienda vigilar los registros durante las actualizaciones. Para este plan, utiliza una parada y un arranque controlados con un operador presente. Separa los archivos ensayados de la copia conservada para recuperar.
No empieces incorporando todas las mejoras pendientes. Comprueba primero si funciona el cambio propuesto. Si un fallo exige rediseñar algo mayor, sácalo de la ventana de mantenimiento y revisa el plan.
Comprueba funciones de la comunidad, además del arranque
Acuerda las pruebas con quienes gestionan esas funciones. Elige un conjunto pequeño que realmente pueda impedir la reapertura:
| Comprobación | Evidencia necesaria para abrir |
|---|---|
| Entrada de un jugador normal | Conserva la identidad, el inventario y la ubicación esperados |
| Control de acceso | Un jugador no puede ejecutar una acción de equipo; un moderador sí realiza su tarea |
| Construcción protegida | Una persona sin autorización no puede modificar la zona elegida |
| Función esencial de un plugin | Una parcela, puntuación o inscripción se consulta y modifica correctamente |
| Persistencia | El cambio controlado sobrevive a un reinicio limpio |
| Dependencia externa | La petición controlada llega al sistema previsto y su resultado se concilia |
Usa valores esperados conocidos de la copia de ensayo. «Parece correcto» no es una comparación. Registra el rol de la cuenta, los pasos, el resultado esperado, el real y su evidencia. Mantén «sin ejecutar» hasta que alguien haga la comprobación.
La documentación de problemas con plugins señala logs/latest.log como punto de partida para errores de carga y describe dependencias ausentes. Que el plugin figure habilitado solo comprueba la carga. No valida las funciones incluidas en vuestra ficha de aceptación.
Compara una sesión representativa con las mediciones de rendimiento anteriores en condiciones similares. Pacta los límites bloqueantes antes de probar. Este procedimiento no aporta una cifra universal de jugadores, tiempos de tick medidos ni la garantía de que actualizar mejore el rendimiento.
Conserva una vuelta atrás coherente
Antes de cambiar producción, restringe la actividad nueva, detén limpiamente el servidor y coordina los demás procesos que escriben estado compartido. Captura el conjunto de recuperación mediante los métodos de copia admitidos por vuestro almacenamiento. Identifica qué archivos, bases de datos, versiones y momento pertenecen al mismo conjunto.
Pregunta a los mantenedores de plugins esenciales qué cambia en los datos guardados y si se admite volver a la versión anterior. No des por hecho que reponer el JAR antiguo deshace una migración de base de datos o configuración. Planifica restaurar el estado previo conservado, salvo que exista otra recuperación documentada y ensayada.
Mantén cerrado el acceso público durante las comprobaciones de aceptación en producción. Si abres y los jugadores generan progreso, restaurar el estado anterior puede descartarlo. Una recuperación posterior necesita valorar de nuevo la pérdida de datos y las acciones externas ya completadas.
Deja constancia de la decisión
Usa tres resultados: abrir, seguir cerrado para una corrección delimitada o restaurar el conjunto acordado. Los datos esenciales ausentes, los privilegios inesperados y una función crítica rota deben impedir la apertura. Un defecto visual opcional puede aceptarse con responsable, impacto documentado y fecha de seguimiento.
Tras abrir, asigna un periodo de observación y un operador que pueda atender los problemas acordados. Registra lo sucedido, incluidas las pruebas fallidas y las versiones finales. La monitorización programada o la cobertura en directo necesitan un alcance pactado; superar un ensayo no implica disponibilidad indefinida.
Para encargar infraestructura Minecraft gestionada, aporta la ficha del cambio, las funciones esenciales y la ventana aceptable. Mineando presupuesta individualmente proyectos de pago. Si el bloqueo está en un plugin propio, incluye actualización y recuperación en el encargo de desarrollo; mantenimiento y soporte continuados se acuerdan aparte.
