opensuse
[Arriba] [Todas las Listas]

Re: [opensuse] REDADA 1 vs "VIVE" Backup era REDADA de software vs REDAD

To: opensuse@xxxxxxxxxxxx
Subject: Re: [opensuse] REDADA 1 vs "VIVE" Backup era REDADA de software vs REDADA de BIOS
From: Duaine Hechler <dahechler@xxxxxxx>
Date: Wed, 14 Sep 2011 01:20:42 -0500
Delivered-to: opensuse@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 14 Sep 2011 02:21:45 -0400
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1315981243; bh=KofXRzI7cvuRkCs60t5yAr0xnp8uCl9HkBLR3JLM9fU=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WRghI+/IXYhZYdTVVwt74e8Rdp88+FKYaTx5NwVIWhiSbQauiJMItJyk347QcAV313shFYU/wa0pwmQipsqv1yY7OScqjksUGLsyXynFKdXkSF+s5H1dp4FDcU0/xICQskHYofX0zMLSgXJb8nSD1AqF7CMlotU00AAVTpnWYM8=
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <4E703B97.3070303@earthlink.net>
List-archive: <http://lists.opensuse.org/opensuse/>
List-help: <mailto:opensuse+help@opensuse.org>
List-owner: <mailto:opensuse+owner@opensuse.org>
List-post: <mailto:opensuse@opensuse.org>
List-subscribe: <mailto:opensuse+subscribe@opensuse.org>
List-unsubscribe: <mailto:opensuse+unsubscribe@opensuse.org>
Mailing-list: contact opensuse+help@xxxxxxxxxxxx; run by mlmmj
References: <4E6FFFBE.102@gmail.com> <4E702018.1030700@suddenlinkmail.com> <4E702836.6060003@att.net> <4E703B97.3070303@earthlink.net>
User-agent: Mozilla/5.0 (X11; Linux i686; rv:6.0) Gecko/20110812 Thunderbird/6.0
En 09/14/2011 12:28 AM, Felix *Miata escribió:
En 2011/09/13 23:06 (GMT-0500) *Duaine *Hechler compuso:

Así que tomé de REDADA y cada noche yo a mano corrido "*rsync" para mantener los dos paseos en *sync.

Al menos para mí, esto proporciona un "vivir" *backup y una "condición" de REDADA simulada.

Un ejemplo bueno del uso de esta REDADA simulada, es cuándo actualizo a versiones más nuevas.

Antes de que empiezo el *upgrade, yo *rsync los paseos. De este modo tengo un rápido *backout plan.

Tan en conclusión, REDADA 1 es GRANDE hasta que tú  un tornillo importante arriba de - entonces AMBOS paseos no son *usable.

Con *HDs tan grande cuando son más lo fronteras en incompetencia a no tener particiones múltiples, un primero, un próximo, y #uno 3*rd o más para experimental. El primero es justo que, el primer OS instaló. Entonces en "*upgrade" tiempo, instalar el "*upgrade" a la "partición" próxima, dejando el primer *undisturbed. Sólo después de próximo "" es confirmado *suitable lo" conviertes a principal, el cual primero inmediatamente antes de que era, y después de que que primero acontece un *online *backup hasta próximo2 acontece disponible. Entretanto un tercer o más es disponible para probar *devel versión(*s) y/u otro *distros. En este *scenario, /casa y otras particiones de dato del usuario, si ninguno, es separado, y *mountable como tal debajo muy / te ha chutado. Algún cuidado tiene que ser tomado sobre dato de usuario para impedir la corrupción que cambia entre no-emparejando versiones de software bajo las varias versiones instaladas de OS, pero esto no es difícil.

Mi dos REDADA1 sistemas tienen 3 OS / *md dispositivos cada cual, un *md dispositivo para /*tmp, un *md dispositivo para /casa, y par de otro *md dispositivos para otro dato. /Bota no hago a REDADA porque veo poco punto. Yo clon (entonces puesto un nuevo *UUID y etiqueta) la /bota del #1 HD al #2 de modo que fácilmente puede ser utilizado como dispositivo de bota de la suela en caso el #1 HD muere. Utilizo etiquetas para dispositivos en carta.*lst Y *fstab, los cuales son un poco más fácil para ojos humanos para mantener que ID de dispositivo o *UUID.

He *eSATA *HDs para respaldar arriba, los cuales son sólo *powered en *backup tiempo, pero mucho más rápido en transferir dato que *USB 2.0.
A pesar de que, ya tengo un "/", *swap y /casa, estoy haciendo cualquier cosa que necesito cualquier cosa esto complicó. Y, he aprendido de mi *mainframe días, NO para ser en el borde de hemorragia de *upgrading.

Soy justo una casa sencilla y usuario empresarial pequeño de Linux.

Y, si realmente quiero experimento, puedo siempre uso *VirtualBox.

*Duaine

--
*Duaine *Hechler
Piano, Piano de Jugador, Sintonía de Órgano
de la Bomba, *Servicing&  *Rebuilding
Miembro de Sociedad de Órgano de Reed
*Florissant, *MO 63034
(314) 838-5587
dahechler@xxxxxxx
www.hechlerpianoandorgan.com
--
Casa&  usuario Empresarial de Linux - 11 años

--
A *unsubscribe, *e-correo: *opensuse+unsubscribe@xxxxxxxxxxxx
Puesto que órdenes adicionales, *e-correo: *opensuse+help@xxxxxxxxxxxx


On 09/14/2011 12:28 AM, Felix Miata wrote:
On 2011/09/13 23:06 (GMT-0500) Duaine Hechler composed:

So I took of RAID and every night I manually run "rsync" to keep the two drives in sync.

At least for me, this provides a "live" backup and a "simulated" RAID condition.

A good example of the use of this simulated RAID, is when I update to newer versions.

Before I start the upgrade, I rsync the drives. This way I have a quick backout plan.

So in conclusion, RAID 1 is GREAT until you do a major screw up - then BOTH drives are not usable.

With HDs so large as they are any more it borders on incompetence to not have multiple / partitions, a first, a next, and a 3rd or more for experimental. The first is just that, the first OS installed. Then at "upgrade" time, install the "upgrade" to the "next" partition, leaving the first undisturbed. Only after "next" is confirmed suitable do you "convert" it to main, which first immediately before was, and after which first becomes an online backup until next2 becomes available. Meanwhile a third or more are available for testing devel version(s) and/or other distros. In this scenario, /home and other user data partitions, if any, are separate, and mountable as such under any / you have booted. Some care must be taken about user data to prevent corruption switching among non-matching versions of software under the various installed versions of OS, but this is not difficult.

My two RAID1 systems have 3 OS / md devices each, one md device for /tmp, one md device for /home, and couple of other md devices for other data. /boot I don't make into RAID because I see little point. I clone (then set a new UUID and label) the /boot from the #1 HD to the #2 so that it can readily be used as a sole boot device in case the #1 HD dies. I use labels for devices in menu.lst and fstab, which are a bit easier for human eyes to maintain than device ID or UUID.

I have eSATA HDs for backing up, which are only powered at backup times, but much faster at transferring data than USB 2.0.
Although, I already have a "/", swap and /home, I'm doing anything that I need anything this complicated. And, I've learned from my mainframe days, NOT to be on the bleeding edge of upgrading.

I'm just a simple home and small business user of Linux.

And, if I really want to experiment, I can always use VirtualBox.

Duaine

--
Duaine Hechler
Piano, Player Piano, Pump Organ
Tuning, Servicing&  Rebuilding
Reed Organ Society Member
Florissant, MO 63034
(314) 838-5587
dahechler@xxxxxxx
www.hechlerpianoandorgan.com
--
Home&  Business user of Linux - 11 years

--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx


<Anterior por Tema] Tema Actual [Siguiente por Tema>