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.

Return to mayfirst.coop

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-----