No tengo nada en contra de Root, excepto eFUSE. De quién fue la idea de eFUSE
Según tengo entendido:
Por culpa de los usuarios amateurs y de los minimalistas despistados que no saben utilizar herramientas que están pensadas para usuarios avanzados, el equipo de desarrollo de TWRP ha decidido polémicamente que su copia de seguridad de NANDROID no incluye /data/media .
Más información y fuentes en estos comentarios:
1. ¿Cuál es la mejor práctica para hacer una copia de seguridad de /datos/medios?
2. ¿Cuál es la mejor práctica para hacer una copia de seguridad de /datos/medios?
Lo que quiero es una copia de seguridad de la imagen a nivel de bloque de todo el teléfono, para poder volver al punto exacto más adelante.
Quiero que esa copia de seguridad a nivel de bloque incluya el /data/media
partición.
Ahora, he descubierto que es posible a través de ADB, pero eso requiere Root. Si realmente no hay otra manera, yo consideraría tomar el riesgo de rootear el teléfono después de hacer cualquier otro método de copia de seguridad posible (adb app backup, copia de seguridad de archivos, etc.)
Pero mi pregunta es:
¿Es técnicamente posible hacer una copia de seguridad a nivel de bloque (dd) de la partición /data/media sin Root?
Si el equipo de desarrollo de TWRP hubiera decidido incluir /data/media
complaciendo a los usuarios avanzados y a los maximalistas en lugar de a los minimalistas y a los usuarios amateurs, ¿podría en realidad ¿habría sido posible sin Root?
1 votos
En primer lugar
/data/media
no es/dev/media
. El anterior es un directorio deuserdata
que está montada en/data
. Así que, en cierto sentido, quieres hacer una copia de seguridad de todo el dispositivo de bloques deuserdata
partición. Eso es posible sin rootear tu sistema operativo actual. Pero necesitas un bootloader desbloqueado para arrancar en TWRP. Desde ahí puedesdd
cualquier dispositivo de bloque, incluso todo el chip de memoria flash. Pero, ¿por qué quieres un acceso a nivel de bloque? Una simpletar
de/sdcard
es suficiente en la mayoría de los casos.0 votos
@IrfanLatif Gracias por resolver mi confusión. Lo mejor es una copia de seguridad a nivel de bloque de
/dev/block/mmcblk0
.1 votos
@IrfanLatif El acceso a nivel de bloque significa que se puede flashear poco a poco a su estado original y la confianza de que no falta absolutamente nada en la copia de seguridad.
1 votos
Lo primero que hay que hacer al comprar un dispositivo Android es asegurarse de que el bootloader está desbloqueado. Te estoy mirando a ti, Google Nexus. (su bootloader bloqueado me ha dado problemas en algún momento). Samsung, afortunadamente, suele enviarlos sin el bootloader bloqueado.
2 votos
El acceso a nivel de bloque suele ser necesario cuando se tiene que tratar con los inodos o el diario del sistema de archivos, como por ejemplo para recuperar algunos datos borrados o hacer algún análisis forense.
/sdcard
(que expone/data/media
para nosotros) es un sistema de archivos emulado con un subconjunto de características del sistema de archivos. Por ejemplo, no puedes cambiar los permisos y el contexto SELinux de los archivos, esos son fijo . Así que ni siquiera es necesario hacer una copia de seguridad y restaurarlas. Los atributos del sistema de archivos (como la bandera inmutable) son compatibles con/sdcard
pero no se puede respaldar contar
.2 votos
Los atributos extendidos (y, por tanto, las ACL) no son compatibles (excepto seguridad.selinux ), pero no importan mucho en Android. Sin embargo, si usted está haciendo una copia de seguridad y restaurar
/data/media
directamente (con acceso Root), debes cuidar los permisos de los archivos y los contextos SELinux. Tar soporta la copia de seguridad de un montón de metadatos; permisos (incluyendo propietario y grupo), marcas de tiempo (incluyendo mtime, atime, ctime) y atributos extendidos (incluyendo ACLs, contextos SELinux y capacidades de archivo). Curiosamente, TWRP también creatar
copias de seguridad de sistemas de archivos como/data
,/system
,/vendor
etc.0 votos
En Open GApps se incluye un binario gnu tar completo, que soporta las banderas --acls --xattrs --selinux