Hola :)
2017-05-24 16:48 GMT+03:00 miguel gmail
Cuando llego y veo los 4 discos con LED rojo pienso ... "vaya marrón me ha caído". Me pongo manos a la obra y consigo recuperar 2 discos, pero los ortos 2 ... rechinaban: cabezal tocando el platter como si fuera un DJ ... Mandamos los discos a una empresa de recuperación de datos y nos dijeron que no se podía hacer nada.
Lo malo es que la cosa pasó de problema técnico a problema político a nivel de jefes ... Ahora el profesor nos odia (obviamente) porque ha perdido 3 años de datos. Al final todos se señalaban con el dedo y un misterio quién tenía que haberse encargado del servidor y las copias de seguridad.
¿Y luego te extrañas que tengan veinte copias por ahí que ni saben que están? :-P
No, de hecho la chica tiene copias por todos lados ahora :) Lo malo de eso es que luego no saben cual es la copia "buena" :(
Lo que me da rabia es que en vez de intentar ayudar al usuario, se estuvieron senalando con el dedo unos a otros >:-|
para una vez que les hace falta...
Ya. La historia me suena. Mucho.
:(
Yo cortaría cabezas por hacer esas copias fuera de la política de backup.
Estoy de acuerdo. En este caso en concreto, MHO es que fue culpa nuestra, no del usuario. Lo malo es que ahora el usuario desconfia de nosotros (obviamente) y hace sus propias copias de seguridad aunque nosotros se las hacemos oficialmente.
Mi enfoque es: 1. definir una política de backup con varios sabores (por favor, no más de cinco, como mucho). Lo de doble copia de backup debería ser obligatorio. Abarcar todo el conjunto de datos que lo requiera (ficheros planos, bases de datos, aplicaciones rarunas, etc.). Lo de disco o cinta... depende de presupuesto, ventana de backup, volumen a proteger, etc. 2. asignar (estimar) costes a cada política. 3. comunicar la política y dejar que cada aplicación elija su sabor. Dicha política puede estar definida en términos de RPO, RTO, VRO y GRO (por ejemplo) y explicitar los límites del servicio de backup. 4. imputar mensualmente el coste de ese backup.
Al que se salga de la política... palo.
Estoy de acuerdo :)
Y sí, a veces hay que hacer ajustes... lo típico del DBA que decide que se hace su copia local de un export que destroza la dedup porque cambia un bit... Se puede llegar a acuerdos y excluir cierto tipo de ficheros, pero no se puede permitir que los usuarios saquen sus copias de backup por su cuenta y riesgo.
Claro, no llueve a gusto de todos y la informatica/tecnologia es lo suficientemente flexible como para adaptarse a ciertos casos aislados justificados. Lo malo es cuando nosotros (IT staff) no somos lo suficientemente flexibles o no tenemos ganas de realmente ayudar al usuario.
Si ocurre algún tipo de desgracia que haga irrecuperable un dato... mala suerte. La protección infinita tiene un coste infinito (o muuuy elevado, inasumible, pero improbable).
Estoy de acuerdo, pueden darse casos de "destruccion total" y no se puede hacer nada. Nuestro deber es, como dices, poner todos los medios a nuestro alcance para intentar hacer frente a posibles perdidas de datos. Tambien tenemos el deber de intentar ayudar al usuariosi hay una perdida total. En mi caso, lo que hice fue recuperar 2 discos, enviar el RAID (4 discos) a una empresa de recuperacion de datos para intentar recuperar los otros dos, hablar cada 2 o 3 dias con la chica para ponerla al dia (cara a car y yendo yo a su mesa), dar ideas para que pueda conseguir datos por otro lado (e-mails, colegas, ...), ... Al final odian a todos menos a mi porque vieron que intentaba ayudar, daba la cara y pasaba de "buscar culpables". Los usuarios suelen ser comprensivos si ven que intentas ayduar y que no les mientes. Caso gracioso: una vez un cliente me empezo a poner a prueba sobre la HA, DR, ... (era un tipo prepotente) y al final me dice: "Y si cae un meteorito?" ... Le contesto: "Corre, es lo mejor que puedes hacer. Pero corre deprisa." Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org