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: George OLson <grglsn765@xxxxxxxxx>
Date: Wed, 14 Sep 2011 15:01:05 +0800
Delivered-to: opensuse@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 14 Sep 2011 02:58:01 -0400
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=j/TAq2+XITh7Ohj4oprFe0GncbOCVuewLT7667e/+qM=; b=MxTGpfwls/jOc084lhInYBkdeyUR4LFVZR93/7N+0Go4Do9MKDxrKvDK0ZR1QYJM3+ cBJzuEPv8icRw6X11wJzGcHKR+4MiouYB3sqYivbhPRZ+PiOCEbkiLJMZVblgIIUCm2q iQU/FmAQZ3fZuRbu9bihMwvRQJlG+0mJYAHCI=
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 x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0
En 09/14/2011 01:28 PM, Felix *Miata escribió:


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.

Esta discusión es muy buena y está dándome algunas ideas. Puedo ver el valor de habiendo raíces múltiples, y me gustaría para mover a aquel finalmente. Seguí el consejo de Felix y hizo aquello en mi *laptop, pero cuándo monté esto *desktop hube no todavía pensó sobre aquello.

Tan aquí es una cuestión sobre raíces múltiples - cuándo montando 2 o 3 20*gb particiones de raíz para experimentación futura, aquellas particiones tienen que ser particiones primarias? También, las particiones de raíz tienen que ser próximas al *swap y próximo a la /partición de casa, o puede ellos ser *anywhere en el paseo?

Supone yo *setup mi paseo de TB de modo que es así:

/*dev/*sdb1	2*gb, *linux *swap para ser copiado de /*dev/*sda1 cuando REDADA o con *rsync
/*dev/*sdb2 20*gb, partición de raíz ser copiado de /*dev/*sda2 cuando REDADA o con *rsync /*dev/*sdb3 443.75*gb, partición de dato, copiado de /*dev/*sda3 cuando REDADA o con *rsync
/*dev/*sdb4	partición extendida cubriendo el conjunto próximo de particiones
/*dev/*sdb5 20*gb, partición de raíz para experimentación y uso más tardío ( yo ser capaz de señalar *grub a esta partición en otro día si instalo otro sistema para probar?)
/*dev/*sdb6	20*gb, partición de raíz para experimentación y uso más tardío
/*dev/*sdb7 quedando *gb en el disco para dato extra *storage que será respaldado arriba de por separado

Es que un esquema que trabajaría, y me daría la flexibilidad de ser capaz de instalar el próximo *upgrade en una raíz diferente para probarlo, y cosas como aquello?

*Thanks Otra vez,
George

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


On 09/14/2011 01:28 PM, Felix Miata wrote:


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.

This discussion is very good and is giving me some ideas. I can see the value of having multiple roots, and I would like to move to that eventually. I followed Felix's advice and did that on my laptop, but when I set up this desktop I had not yet thought about that.

So here is a question about multiple roots - when setting up 2 or 3 20gb root partitions for future experimentation, do those partitions have to be primary partitions? Also, do the root partitions have to be next to the swap and next to the /home partition, or can they be anywhere on the drive?

Suppose I setup my TB drive so that it is like this:

/dev/sdb1	2gb, linux swap to be copied from /dev/sda1 as RAID or with rsync
/dev/sdb2 20gb, root partition be copied from /dev/sda2 as RAID or with rsync /dev/sdb3 443.75gb, data partition, copied from /dev/sda3 as RAID or with rsync
/dev/sdb4	extended partition covering the next set of partitions
/dev/sdb5 20gb, root partition for later use and experimentation (will I be able to point grub to this partition on another day if I install another system to test?)
/dev/sdb6	20gb, root partition for later use and experimentation
/dev/sdb7 remaining gb on the disk for extra data storage that will be backed up separately

Is that a scheme that would work, and would give me the flexibility of being able to install the next upgrade in a different root to test it, and things like that?

Thanks again,
George

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


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