Welcome to the May First Movement Technology Status Page
Please see below for any known interuptions to our service. If you are experiencing a problem not listed here, please open a support ticket.
Subscribe to an RSS feed of these alerts, get them by email, or learn how to subscribe to other messages.
pietri: all guests are running / pietri: apuntan a todos los huéspedes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Servers Affected/Servidores afectados: pietri paul kwame colin annette clara moses eagle julia Period Affected/Horas afectadas: 2015-02-13 - 2015-02-15 Date/Fecha: 2015-02-15 As of 2:30 pm America/New_York, all guests on pietri are now restored. Thanks to all members for your patience as we worked through the weekend to restore services. Also, a big thanks to Ross, Jaime V, Daniel (dkg) and Jamie M for spending all night friday and significant parts of the weekend to complete this restoration. Following is a brief summary of useful information about the recovery, what happened, how things have changed, and next steps. First, the recovery resulted in some data loss for members with data on the affected servers listed above. Specifically, any data that was added or changed or deleted between about 11:00 am and 10:00 pm America/New_York time on Friday, February 13 has been lost. We do not have a backup of this data. That means any email that was received during this time or any changes or comments added to a web site is no longer available. Why is this data lost? Doesn't May First/People Link keep backups? Yes - we do keep backups that run nightly for all servers - both an onsite backup and an offsite backup. However, since the most recent backup ran early in the morning on friday, and the next backup was scheduled for early in the morning on saturday, data that is added or changed between these times is not backed up. What happened to the server? May First/People Link uses redundant disks in all servers. That means that all data is written simultaneously to two disks at all times. If one disk fails, the server continues running uninterrupted on the remaining disk. Friday morning, we discovered problems with one of the disks in pietri. Due to the errors on the disk, we disabled this disk at about 11:00 am America/New_York time and scheduled to replace the failing disk at 10:00 pm. However, at 10:00 pm, when we restarted the server after replacing the disk, the redundant disk completely failed. It was unrecognizable to the server and completely inaccessible. We were facing the unusual condition of having trouble with two pairs of a redundant array of disks at the same time. Fortunately, the original failing disk was still accessible. We spent most of friday night copying enough data from this disk to a new disk to start the primary (aka host) server. We then spent all day saturday and sunday morning copying data from the originally failing disk to new disks. Only one guest, annette, had data saved in the parts of the hard disk that was damaged. Fortunately, using a free/open source tool (ddrescue) we were able to copy the sectors in a creative way that was able to retrieve nearly all the data from around the damaged sectors on the disk (only 45K of damaged data in the end). What has changed? In the course of our recovery, we made two changes. One, the guest julia was moved to a new physical server (axiom) which we expect will lead to better performance on julia and the hosts that remain on pietri. Second, we have switched from using two hard disks to using four hard disks in the server, allowing us to switch to a faster version of our hard disk redundancy software (switching from RAID1 to RAID10), which will also improve performance on this server. Next steps: We have one more step to take before this process is complete. We need about 3 - 4 hours in the middle of the night to re-sync the new disks to their redundant counter parts. We will notify you via a service advisory when this is scheduled. - -- A partir de 14:30 America/New_York, todos los huéspedes de pietri son restaurados. Gracias a todos los miembros por su paciencia mientras trabajamos con el fin de semana para restaurar servicios. También, muchas gracias a Ross, Jaime V, Daniel (dkg) y Jamie M para gastar todo noche del viernes y partes importantes del fin de semana para completar esta restauración. Lo que sigue es un breve resumen de información útil acerca de la recuperación, lo que pasó, cómo han cambiado las cosas y próximos pasos. En primer lugar, la recuperación resultó en una pérdida de datos para miembros con datos sobre el afectados los servidores mencionados anteriormente. En concreto, cualquier dato que fue agregado o cambiado o eliminados entre unos 11:00 y 22:00 America/New_York tiempo el viernes, El 13 de febrero se ha perdido. No tenemos una copia de seguridad de los datos. Eso significa que cualquier correo electrónico que recibió durante este tiempo o cualquier cambio o comentario añadido a un sitio web ya no está disponible. ¿Por qué se pierde esta información? ¿No primero de puede / People Link guardar copias de seguridad? -Que hacemos guardar copias de seguridad que se ejecutan todas las noches para todos los servidores - ambos una copia de seguridad en el sitio y un backup fuera del sitio. Sin embargo, desde la última copia de seguridad se temprano en la mañana del viernes, y la siguiente copia de seguridad estaba programada para temprano en la mañana del sábado, datos que es agregado o cambiado entre estos tiempos no se copiarán. ¿Qué pasó con el servidor? Primero de mayo / People Link usa discos redundantes en todos servidores. Eso significa que todos los datos se escriben simultáneamente en dos discos en absoluto veces. Si un disco falla, el servidor continúa funcionando sin interrupciones en el disco restante. El viernes por la mañana, descubrimos problemas con uno de los discos de pietri. Debido a los errores en el disco, hemos desactivado este disco en el punto 11:00 America/New_York tiempo y programados para reemplazar el disco falla en 22:00. No obstante, a 22:00, cuando reinicia el servidor después de reemplazar el disco, el disco redundante totalmente fracasado. Era irreconocible al servidor y completamente inaccesible. Nos enfrentábamos a la condición inusual de problemas con dos pares de una matriz redundante de discos al mismo tiempo. Afortunadamente, el disco falla original era todavía accesible. Pasamos la mayor parte de copiar datos suficientes de este disco a un disco nuevo para iniciar la noche del viernes el servidor primario (también conocido como anfitrión). Luego pasamos todo el día el sábado y el domingo por la mañana copias datos desde la falta de originalmente del disco para discos nuevos. Sólo uno de los invitados, annette, tenía los datos guardados en las partes del disco duro que era dañado. Afortunadamente, utilizando una herramienta de código libre (ddrescue) fuimos capaces copiar los sectores de una manera creativa que fue capaz de recuperar casi todos los datos de alrededor de los sectores dañados en el disco (sólo 45K de datos dañados en el final). ¿Qué ha cambiado? En el curso de nuestra recuperación, hicimos dos cambios. Uno, el Comentarios julia fue trasladada a un nuevo examen físico servidor (axioma) que esperamos será conducen al mejor desempeño sobre julia y los anfitriones que quedan en pietri. En segundo lugar, nos hemos cambiado de utilizar dos discos duros a usar cuatro discos duros en el servidor, permitiéndonos cambiar a una versión más rápida de nuestro disco duro software de redundancia (cambio de RAID1 a RAID10), que también mejorará rendimiento en este servidor. Próximos pasos: tenemos un paso más para tomar antes de que termine este proceso. Nos necesitan alrededor de 3 a 4 horas en medio de la noche para volver a sincronizar los discos nuevos sus piezas contrarias redundante. Nosotros le notificaremos vía un servicio consultivo cuando Esto está programado. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJU4PRPAAoJEKAUwFpge3U1yaIP/0qkOhrz24sqExVjouSJh/G4 bwpKJeepB1JtDAUGnJ/4Gn4wkxLBU1O8U0ldiGzWtXVC7d7EAimV4j/LGOrQILuQ y33BrnEjP/uUxpi4wsh573gSfP5wZonut0TRx6joy6qv+70UqXa6BSqIMX8kEx9c 2AC0QLqWQyXObI+wVYih+XobIF6waBMtDBrqAdLexJXgH4704EdMK6hbLBWTn/Ax 0xnaXsQcBRU+2edM+XlvOmJgBAmu+oBjZAbXCG+QbahX/gGOdF/yTL26Vx8ETG9X cEQAIt+Blro9YJ1JgdOu87lxi9lAfFcj/nQ+vINulvMWmhB06wCj+loqkQOzfMsj FCxn//nnXMWRFcbRpMF/S0MCmRVayRwasVYpzkM7YXoYCu3Jt5/HwAecR0vfhXrt EHNwQd1oY+DzUujSN3SlXS42cz2uKe1Rd9tWtm9yuGzkCQRYSyo4fFLJ+OExb/k9 9g38w2ETdqSY0jr6vLF6EKElA/KYfrN8fU0Z5AVqg7AD8p/B61zpsetGg0suxcGF 7PcLsg0WPq+cyHgFKJS7f7rXGl3MI990iyUxvFRDttlD5w9OtS8Vqq9EClyrAyzZ XrxyiSVyIeg4P67XHvCb3EMYnxpEfKblJs/909BUMOKl4k03mY8OZUxUCnGzxTt/ ucPeWBIcmXvxVQ2N2jiY =n+nJ -----END PGP SIGNATURE-----