Azure Storage Files

Díganos qué opina sobre la experiencia de descarga del PDF.
Documentación de Azure Files

Recursos compartidos de archivos en la nube de nivel empresarial sencillos, seguros y
sin servidor.
Acerca de Azure Files
ｅ INFORMACIÓN GENERAL
Guía de plan de Azure Files
¿Qué es Azure Files?
Habilitación basada en identidad
Vídeos
Introducción
ｆ INICIO RÁPIDO
Creación y uso de un recurso compartido de archivos de Azure
ｇ TUTORIAL
Creación de un recurso compartido de archivos SMB de Azure: Windows
Creación de un recurso compartido de archivos NFS de Azure: Linux
Solución de problemas
ｉ REFERENCIA
Solucionar problemas de Azure Files
Solución de problemas de rendimiento de Azure Files
Migrate
GUÍA PASO A PASO

GUÍA PASO A PASO
ｃ
Información general sobre la migración
Guías de migración
Entrenamiento autodirigido
ｄ CURSOS
Introducción a Azure Files
Configuración de Azure Files y Azure File Sync
Architecture
Ｙ ARQUITECTURA
Recurso compartido de archivos de la nube empresarial de Azure
Servicios de archivo híbridos
Uso de recursos compartidos de archivos de Azure en un entorno híbrido
Recurso compartido de archivos híbrido con la recuperación ante desastres para trabajos
tanto remotos como de sucursales locales
Archivos de Azure a los que se accede de forma local y que protege AD DS

Artículo • 25/03/2023
Azure Files le ofrece recursos compartidos de archivos en la nube totalmente

administrados, a los que se puede obtener acceso mediante el protocolo Bloque de
mensajes del servidor (SMB) estándar, el protocolo Network File System (NFS) y la API
de REST de Azure Files. Los recursos compartido de archivos de Azure se pueden
montar simultáneamente mediante implementaciones locales o en la nube. A los
recursos compartidos de archivos SMB de Azure se puede acceder desde clientes
Windows, Linux y macOS. Se puede acceder a los recursos compartidos de archivos NFS
de Azure desde clientes Linux. Además, los recursos compartidos de archivos SMB de
Azure Files se pueden almacenar en la caché de los servidores de Windows Server con
Azure File Sync, lo que permite un acceso rápido allí donde se utilizan los datos.
Estos son algunos vídeos sobre casos de uso comunes de Azure Files:
Reemplazo del servidor de archivos por un recurso compartido de archivos de

Azure sin servidor
Introducción a los contenedores de perfiles de FSLogix en Azure Files en Azure
Virtual Desktop mediante el aprovechamiento de la autenticación de AD
Para empezar a usar Azure Files, consulte Inicio rápido: Creación y uso de un recurso
compartido de archivos de Azure.
¿Por qué es útil Azure Files?

Los recursos compartidos de archivos de Azure se pueden usar para:
Reemplazar o complementar servidores de archivos locales:

Azure Files puede ser utilizado para reemplazar o complementar los servidores de
archivos tradicionales locales o en dispositivos de almacenamiento conectado a la
red (NAS). Desde sistemas operativos tan extendidos como Windows, macOS y
Linux se puede montar directamente un recurso compartido de Azure Files desde
cualquier lugar del mundo. Los recursos compartidos de archivos SMB de Azure
Files se pueden replicar también con Azure File Sync en servidores de Windows
Server, locales o en la nube, para obtener un almacenamiento en caché eficiente y
distribuido de los datos. Con la Autenticación de AD de Azure Files, los recursos
compartidos de archivos de Azure de SMB pueden funcionar con Active Directory
Domain Services (AD DS) hospedados en el entorno local para el control de
acceso.
Aplicaciones "Lift-and-shift" :
Azure Files facilita la migración mediante "lift and shift" de aplicaciones a la nube
que espera un recurso compartido de archivos para almacenar datos de la
aplicación de archivos o de un usuario. Azure Files permite la migración clásica
mediante "lift and shift" en la que tanto la aplicación como sus datos se mueven a
Azure, y la migración híbrida mediante "lift and shift" en la que los datos de la
aplicación se mueven a Azure Files pero la aplicación continúa ejecutándose de
forma local.
Simplificar el desarrollo en la nube:

Azure Files también se puede utilizar para simplificar los nuevos proyectos de
desarrollo en la nube. Por ejemplo:
Configuración de aplicaciones compartidas

Un patrón habitual entre las aplicaciones distribuidas es contar con archivos de
configuración en una ubicación centralizada que permite tener acceso a ellos
desde muchas instancias de aplicaciones. Las instancias de la aplicación pueden
cargar su configuración mediante la API de REST de Azure Files y los usuarios
pueden acceder a ella montando el recurso compartido localmente.
Recurso compartido de diagnóstico:

Un recurso compartido de Azure Files es un lugar adecuado para que las
aplicaciones en la nube escriban sus registros, métricas y volcados de memoria.
Las instancias de la aplicación pueden escribir los registros mediante la API de
REST de Azure Files, y los desarrolladores pueden acceder a ellos montando el
recurso compartido de archivos en su máquina local. Esto permite una gran
flexibilidad, ya que los desarrolladores pueden adoptar el desarrollo en la nube
sin tener que abandonar las herramientas existentes que ya conocen y disfrutan.
Desarrollo, pruebas y depuración:

Cuando los desarrolladores o administradores están trabajando en máquinas
virtuales en la nube, a menudo necesitan diversas herramientas o utilidades.
Copiar estas utilidades y herramientas en cada máquina virtual puede ser una
tarea que consuma mucho tiempo. Mediante el montaje de un recurso
compartido de Azure Files localmente en las máquinas virtuales, un
desarrollador o administrador pueden acceder rápidamente a sus herramientas
y utilidades, sin tener que copiarlos.
Contenedorización:
los recursos compartidos de archivos de Azure se pueden usar como volúmenes
persistentes para contenedores con estado. Los contenedores ofrecen
funcionalidades de "compilar una vez, ejecutarse en cualquier lugar" que permiten
a los desarrolladores acelerar la innovación. En el caso de los contenedores que
acceden a datos sin procesar en cada inicio, se requiere un sistema de archivos
compartidos para que estos contenedores puedan acceder al sistema de archivos,
independientemente de la instancia en que se ejecuten.
Ventajas principales
Fácil de usar. Cuando se monta un recurso compartido de archivos de Azure en el
equipo, no es necesario hacer nada especial para acceder a los datos: simplemente
vaya a la ruta de acceso donde se monta el recurso compartido de archivos y abra
o modifique un archivo.
Acceso compartido. Los recursos compartidos de Azure Files admiten los
protocolos SMB y NFS estándar del sector, lo que significa que puede reemplazar
perfectamente los recursos compartidos de archivos en local por recursos
compartidos de archivos de Azure sin preocuparse de compatibilidad de
aplicaciones. La posibilidad de compartir un sistema de archivos entre varias
máquinas, aplicaciones e instancias de aplicaciones es una ventaja importante para
aquellas aplicaciones que necesitan la posibilidad de compartir.
Completamente administrado. Los recursos compartidos de Azure Files pueden
crearse sin necesidad de administrar ni el hardware ni un sistema operativo. Esto
significa que no tiene que tratar con la aplicación de actualizaciones de seguridad
críticas en el sistema operativo del servidor ni ocuparse de reemplazar discos
duros defectuosos.
Herramientas y scripting. Como parte de la administración de las aplicaciones de
Azure, se pueden usar cmdlets de PowerShell y la CLI de Azure para crear, montar
y administrar recursos compartidos de archivos de Azure. Los recursos
compartidos de archivos de Azure se pueden crear y administrar mediante Azure
Portal y el Explorador de Azure Storage.
Resistencia. Azure Files se creó desde sus orígenes para estar siempre disponible.
Reemplazar los recursos compartidos de archivos en local por Azure Files significa
que ya no tendrá que tratar con problemas de red o interrupciones del suministro
eléctrico local.
Programación amigable. Las aplicaciones que se ejecutan en Azure pueden tener
acceso a los datos en el recurso compartido mediante las API de E/S del sistema.
Por tanto, los desarrolladores pueden aprovechar el código y los conocimientos
que ya tienen para migrar las aplicaciones actuales. Además de las API de E/S del
sistema, puede usar las Bibliotecas de cliente de Azure Storage o la API de REST de
Azure Files.
Cursos
Para el entrenamiento autodirigido, consulte los módulos siguientes:

Configuración de Azure Files y Azure File Sync
Architecture
Para obtener instrucciones sobre cómo diseñar soluciones en Azure Files mediante
patrones y prácticas establecidos, consulte lo siguiente:
Recurso compartido de archivos de la nube empresarial de Azure

Servicios de archivo híbridos
Uso de recursos compartidos de archivos de Azure en un entorno híbrido
Recurso compartido de archivos híbrido con recuperación ante desastres para
trabajos tanto remotos como de sucursales locales
Archivos de Azure a los que se accede de forma local y que protege AD DS
Casos prácticos
Las organizaciones de todo el mundo aprovechan Azure Files y Azure File Sync
para optimizar el acceso a los archivos y el almacenamiento. Consulte sus casos
prácticos aquí.
Pasos siguientes
Planeamiento de una implementación de Azure Files
Creación de un recurso compartido de Azure Files
Conexión y montaje de un recurso compartido de archivos SMB en Windows
Conexión y montaje de un recurso compartido de archivos SMB en Linux
Conexión y montaje de un recurso compartido de archivos SMB en macOS
Conexión y montaje de un recurso compartido de archivos NFS en Linux
Preguntas más frecuentes de Azure Files
Inicio rápido: Creación y uso de un
recurso compartido de archivos de
Azure
Artículo • 10/10/2023
Azure Files es el sencillo sistema de archivos en la nube de Microsoft. Puede montar

recursos compartidos de archivos de Azure en los sistemas operativos Windows, Linux y
macOS. En este artículo se muestra cómo crear un recurso compartido de archivos de
Azure con el protocolo SMB mediante Azure Portal, la CLI de Azure o Azure PowerShell.
Se aplica a
Este inicio rápido solo se aplica a recursos compartidos de archivos de Azure SMB. Los
recursos compartidos de archivos SMB estándar y premium admiten el almacenamiento
con redundancia local (LRS) y el almacenamiento con redundancia de zona (ZRS). Los
recursos compartidos de archivos estándar también admiten almacenamiento con
redundancia geográfica (GRS) y el opciones de almacenamiento con redundancia de
zona geográfica (GZRS). Para más información, consulte Redundancia de Azure Files.
Tipo de recurso compartido de archivos SMB NFS
Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS
Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS
Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS
Introducción
Portal
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
Crear una cuenta de almacenamiento

Portal
Una cuenta de almacenamiento es un grupo compartido de almacenamiento en el
que puede implementar un recurso compartido de archivos de Azure u otros
recursos de almacenamiento como blobs o colas. Una cuenta de almacenamiento
puede contener un número ilimitado de recursos compartidos. Un recurso
compartido puede almacenar un número ilimitado de archivos, hasta los límites de
capacidad de la cuenta de almacenamiento.
Para crear una cuenta de almacenamiento mediante Azure Portal, siga estos pasos:
1. En Servicios de Azure, seleccione Cuentas de almacenamiento.
2. Seleccione Crear para crear una cuenta de almacenamiento.
3. En la sección Detalles del proyecto, seleccione la suscripción de Azure en la

que se va a crear la cuenta de almacenamiento. Si solo tiene una suscripción,
debe ser la predeterminada.
4. Si desea crear un nuevo grupo de recursos, seleccione Crear nuevo y escriba

un nombre como myexamplegroup.
5. En Detalles de la instancia, proporcione un nombre para la cuenta de

almacenamiento. Es posible que tenga que agregar algunos números
aleatorios para convertirlo en un nombre único global. Los nombres de las
cuentas de almacenamiento deben estar formados por minúsculas, números y
deben tener entre 3 y 24 caracteres. Anote el nombre de la cuenta de
almacenamiento. La usará más adelante.
6. En Región, seleccione la región en la que desea crear la cuenta de

almacenamiento.
7. En Rendimiento, conserve el valor predeterminado de Estándar.
8. En Redundancia, seleccione Almacenamiento con redundancia local (LRS).


9. Seleccione Revisar para revisar la configuración. Azure ejecutará una

validación final.
10. Una vez completada la validación, seleccione Crear. Debería ver una
notificación informándole de que la implementación está en curso.
Creación de un recurso compartido de archivos

de Azure
Portal
Para crear un recurso compartido de archivos de Azure:
1. Seleccione la cuenta de almacenamiento desde el panel.
2. En la página de la cuenta de almacenamiento, en la sección Almacenamiento

de datos, seleccione Recursos compartidos de archivos.
3. En el menú de la parte superior de la página Recursos compartidos de
archivos, seleccione + Recurso compartido de archivos. Se abre la página
New file share (Nuevo recurso compartido de archivos).
4. En Nombre, escriba myshare. Los nombres de recursos compartidos de

archivos deben estar formados por letras minúsculas, números y guiones
únicos, y deben comenzar y terminar con un número o una letra en minúscula.
El nombre no puede contener dos guiones consecutivos. Para obtener detalles
sobre cómo asignar un nombre a recursos compartidos y archivos, vea
Asignación de nombres y referencia a recursos compartidos, directorios,
archivos y metadatos.
5. Deje la opción Transacción optimizada seleccionada para el Nivel.
6. Seleccione la pestaña Copia de seguridad. De forma predeterminada, la copia

de seguridad se habilita al crear un recurso compartido de archivos de Azure
mediante Azure Portal. Si quiere deshabilitar la copia de seguridad para el
recurso compartido de archivos, desactive la casilla Habilitar copia de
seguridad. Si quiere habilitar la copia de seguridad, puede dejar los valores
predeterminados o bien crear un almacén de servicios de recuperación en la
misma región y suscripción de la cuenta de almacenamiento. Para crear una
directiva de copia de seguridad, seleccioneCrear una nueva directiva.
7. Seleccione Revisar y crear y, después, Crear para crear el recurso compartido
de archivos de Azure.
Creación de un directorio
Portal
Para crear un nuevo directorio denominado myDirectory en la raíz del recurso

compartido de archivos de Azure:
1. En la página Configuración del recurso compartido de archivos, seleccione el

recurso compartido de archivos myshare. Al seleccionarlo, se abrirá la página
del recurso compartido de archivos e indicará que No se encontraron archivos.
2. En el menú que aparece en la parte superior de la página, seleccione + Add
directory (Agregar directorio) y su cuenta. Se abre la página New directory
(Nuevo directorio).
3. Escriba myDirectory y, luego, seleccione Aceptar.
Cargar un archivo
Portal
En primer lugar, debe crear o seleccionar un archivo para cargarlo. Hágalo por
cualquier medio que considere oportuno. Cuando haya decidido el archivo que
desea cargar, siga estos pasos:
1. Seleccione el directorio myDirectory. Se abre el panel myDirectory.
2. En el menú en la parte superior, seleccione Cargar. Se abre el panel Upload

files (Cargar archivos).
3. Seleccione el icono de carpeta para abrir una ventana donde examinar los
archivos locales.
4. Seleccione un archivo y, después, elija Abrir.
5. En la página Cargar archivos, compruebe el nombre de archivo y, luego, haga

clic en Cargar.
6. Cuando termine, el archivo debe aparecer en la lista en la página myDirectory.
Descarga de un archivo
Portal
Para descargar una copia del archivo cargado, haga clic sobre este con el botón
derecho y seleccione Descargar. La experiencia exacta de la descarga dependerá
del sistema operativo y el explorador web que use.
Limpieza de recursos
Portal
Cuando haya terminado, elimine el grupo de recursos. Al eliminar el grupo de

recursos, se elimina la cuenta de almacenamiento, el recurso compartido de
archivos de Azure y otros recursos que se implementaron en el grupo de recursos.
Si hubiera bloqueos en la cuenta de almacenamiento, primero deberá quitarlos.
Vaya a la cuenta de almacenamiento y seleccione Configuración>Bloqueos. Si se
muestran bloqueos, elimínelos.
Es posible que también tenga que eliminar el almacén de Azure Backup Recovery
Services antes de poder eliminar el grupo de recursos.
1. Seleccione Inicio y, a continuación, seleccione Grupos de recursos.

2. Seleccione el grupo de recursos que desea eliminar.
3. Seleccione Eliminar grupo de recursos. Se abre una ventana con una
advertencia acerca de los recursos que se eliminarán con el grupo de recursos.
4. Escriba el nombre del grupo de recursos y, luego, seleccione Eliminar.
Pasos siguientes
Tutorial: Creación de un recurso
compartido de archivos SMB de Azure y
conexión a una VM de Windows
mediante Azure Portal
Artículo • 23/10/2023
Azure Files ofrece recursos compartidos de archivos totalmente administrados en la

nube a los que se puede acceder mediante el protocolo SMB (Bloque de mensajes del
servidor) o el protocolo NFS (Network File System) estándar del sector. En este
tutorial, aprenderá varias maneras de usar un recurso compartido de archivos SMB de
Azure en una máquina virtual (VM) Windows.
＂ Crear una cuenta de almacenamiento

＂ Creación de un recurso compartido de archivos
＂ Implementación de una máquina virtual
＂ Conexión a la máquina virtual
＂ Montaje de un recurso compartido de archivos de Azure en la máquina virtual
＂ Creación y eliminación de una instantánea de recurso compartido
Se aplica a
Introducción

Para poder trabajar con un recurso compartido de archivos de Azure, es necesario que
cree una cuenta de Azure Storage.
Una cuenta de almacenamiento es un grupo compartido de almacenamiento en el que
puede implementar un recurso compartido de archivos de Azure u otros recursos de
almacenamiento como blobs o colas. Una cuenta de almacenamiento puede contener
un número ilimitado de recursos compartidos. Un recurso compartido puede almacenar
un número ilimitado de archivos, hasta los límites de capacidad de la cuenta de
almacenamiento.
Para crear una cuenta de almacenamiento mediante Azure Portal, siga estos pasos:
2. Seleccione Crear para crear una cuenta de almacenamiento.
3. En la sección Detalles del proyecto, seleccione la suscripción de Azure en la que se

va a crear la cuenta de almacenamiento. Si solo tiene una suscripción, debe ser la
predeterminada.
4. Si desea crear un nuevo grupo de recursos, seleccione Crear nuevo y escriba un

nombre como myexamplegroup.
5. En Detalles de la instancia, proporcione un nombre para la cuenta de

almacenamiento. Es posible que tenga que agregar algunos números aleatorios
para convertirlo en un nombre único global. Los nombres de las cuentas de
almacenamiento deben estar formados por minúsculas, números y deben tener
entre 3 y 24 caracteres. Anote el nombre de la cuenta de almacenamiento. La usará
más adelante.
6. En Región, seleccione la región en la que desea crear la cuenta de

almacenamiento.
7. En Rendimiento, conserve el valor predeterminado de Estándar.
8. En Redundancia, seleccione Almacenamiento con redundancia local (LRS).


9. Seleccione Revisar para revisar la configuración. Azure ejecutará una validación

final.
10. Una vez completada la validación, seleccione Crear. Debería ver una notificación
informándole de que la implementación está en curso.
Creación de un recurso compartido de archivos de Azure

A continuación, cree de un recurso compartido de archivos SMB de Azure.
1. Cuando se complete la implementación de la cuenta de Azure Storage, seleccione

Ir al recurso.
2. Seleccione Recursos compartidos de archivos en el panel de la cuenta de

almacenamiento.
3. Seleccione + Recurso compartido de archivos.
4. Asigne al nuevo recurso compartido de archivos el nombre qsfileshare y deje la

opción Transacción optimizada seleccionada para Nivel.
5. Seleccione la pestaña Copia de seguridad. De manera predeterminada, la copia de

seguridad se habilita al crear un recurso compartido de archivos de Azure
mediante Azure Portal. Si quiere deshabilitar la copia de seguridad para el recurso
compartido de archivos, desactive la casilla Habilitar copia de seguridad. Si quiere
habilitar la copia de seguridad, puede dejar los valores predeterminados o bien
crear un almacén de servicios de recuperación en la misma región y suscripción de
la cuenta de almacenamiento. Para crear una directiva de copia de seguridad,
seleccioneCrear una nueva directiva.
6. Seleccione Revisar y crear y, después, Crear para crear el recurso compartido de
archivos.
7. Cree un nuevo archivo txt denominado qsTestFile en la máquina local.
8. Seleccione el nuevo recurso compartido de archivos y en su ubicación, haga clic en

Cargar.
9. Vaya a la ubicación donde haya creado el archivo .txt > seleccione qsTestFile.txt>
seleccione Cargar.
Implementación de una máquina virtual

Ya ha creado una cuenta de Azure Storage y un recurso compartido de archivos con un
solo archivo en ella. A continuación, cree una máquina virtual de Azure con
Windows Server 2019 Datacenter que represente el servidor local en este tutorial.
1. Expanda el menú del lado izquierdo del portal y seleccione Crear un recurso en la
esquina superior izquierda de Azure Portal.
2. En Servicios populares, seleccione Máquinas virtuales.
3. En la pestaña Aspectos básicos, en Detalles del proyecto, seleccione el grupo de

recursos que creó anteriormente.
4. En Detalles de la instancia, asigne a la máquina virtual el nombre qsVM.
5. En Tipo de seguridad, seleccione Estándar.
6. En Imagen, seleccione Windows Server 2019 Datacenter - x64 Gen2.
7. Mantenga los valores predeterminados en Región, Opciones de disponibilidad y

Tamaño.
8. En Cuenta de administrador, agregue un nombre de usuario y escriba una

contraseña para la máquina virtual.
9. En Reglas de puerto de entrada, elija Permitir los puertos seleccionados y luego

seleccione RDP (3389) y HTTP en la lista desplegable.
10. Seleccione Revisar + crear.
11. Seleccione Crear. La creación de una máquina virtual nueva tardará varios minutos
en completarse.
12. Después de completar la implementación de la máquina virtual, seleccione Ir al

recurso.
Conexión a la máquina virtual

Ahora que ha creado la máquina virtual, conéctese a ella para poder montar el recurso
compartido de archivos.
1. Seleccione Conectar en la página de propiedades de la máquina virtual.

2. En la página Connect to virtual machine (Conectarse a una máquina virtual),
mantenga las opciones predeterminadas para conectarse por dirección IP a través
del número de puerto3389 y seleccione Descargar archivo RDP.
3. Abra el archivo RDP que descargó y haga clic en Conectar cuando se le solicite.
4. En la ventana Seguridad de Windows, seleccione Más opciones y, después, Usar

otra cuenta. Escriba el nombre de usuario con el siguiente formato,
localhost\nombre de usuario, siendo <nombre de usuario> el nombre de usuario
administrador de la máquina virtual que creó. Escriba la contraseña que creó para
la máquina virtual y, luego seleccione Aceptar.
5. Puede recibir una advertencia de certificado durante el proceso de inicio de sesión.

Seleccione Sí o Continuar para crear la conexión.
Asigne el recurso compartido de archivos de Azure a una

unidad de Windows
1. En Azure Portal, vaya al recurso compartido de archivos qsfileshare y seleccione
Conectar.
2. Seleccione una letra de unidad y, a continuación, Mostrar script.
3. Copie el script y péguelo en el Bloc de notas.


4. En la máquina virtual, abra PowerShell y pegue el contenido del Bloc de notas y

presione Entrar para ejecutar el comando. Debe asignar la unidad.
Creación de una instantánea de recurso

compartido
Ahora que ha asignado la unidad, cree una instantánea.
1. En el portal, vaya al recurso compartido de archivos, seleccione Instantáneas,

después, + Agregar instantánea y, a continuación, OK.
2. En la máquina virtual, abra qstestfile.txt y escriba "este archivo se ha modificado".

Guarde y cierre el archivo.
3. Cree otra instantánea.
Búsqueda de una instantánea de recurso

compartido
1. En el recurso compartido de archivos, seleccione Instantáneas.
2. En la pestaña Instantáneas, seleccione la primera instantánea de la lista.
3. Abra esa instantánea y seleccione qsTestFile.txt.

Restauración desde una instantánea
1. En la pestaña de instantánea de recurso compartido de archivo, haga clic con el
botón derecho en qsTestFile y seleccione el botón Restaurar.
2. Seleccione Sobrescribir el archivo original y, a continuación, OK.
3. En la máquina virtual, abra el archivo. Se ha restaurado la versión no modificada.
Eliminación de una instantánea de recurso

compartido
1. Para poder eliminar una instantánea de recurso compartido, deberá quitar los
bloqueos de la cuenta de almacenamiento. Vaya a la cuenta de almacenamiento
que creó para este tutorial y seleccione Configuración>Bloqueos. Si se muestran
bloqueos, elimínelos.
2. En el recurso compartido de archivos, seleccione Instantáneas.
3. En la pestaña Instantáneas, seleccione la primera instantánea de la lista y

seleccione Eliminar.
Uso de una instantánea de recurso compartido

en Windows
Al igual que con las instantáneas de VSS locales, puede ver las instantáneas desde el
recurso compartido de archivos de Azure montado mediante la pestaña versiones
anteriores.
1. Ubique el recurso compartido montado en el Explorador de archivos.
2. Seleccione qsTestFile.txt>haga clic con el botón derecho y seleccione Propiedades

en el menú.
3. Seleccione Versiones anteriores para ver la lista de instantáneas de recursos
compartidos de este directorio.
4. Seleccione Abrir para abrir el archivo.
Restaurar desde una versión anterior

1. Seleccione Restaurar. Esta acción copia el contenido de todo un directorio de
forma recursiva en la ubicación original en el momento de la creación de la
instantánea del recurso compartido.
７ Nota
Si el archivo no ha cambiado, no verá una versión anterior para ese archivo

porque ese archivo es la misma versión que la instantánea. Esto es coherente
con el modo en que funciona en un servidor de archivos de Windows.
Cuando haya terminado, elimine el grupo de recursos. Al eliminar el grupo de recursos,
se elimina la cuenta de almacenamiento, el recurso compartido de archivos de Azure y
otros recursos que se implementaron en el grupo de recursos.
Si hubiera bloqueos en la cuenta de almacenamiento, primero deberá quitarlos. Vaya a

la cuenta de almacenamiento y seleccione Configuración>Bloqueos. Si se muestran
bloqueos, elimínelos.
Es posible que también tenga que eliminar el almacén de Azure Backup Recovery
Services antes de poder eliminar el grupo de recursos.

3. Seleccione Eliminar grupo de recursos. Se abre una ventana con una advertencia
acerca de los recursos que se eliminarán con el grupo de recursos.
Pasos siguientes
Uso de un recurso compartido de archivos de Azure con Windows
compartido de archivos NFS de Azure y
montaje del mismo en una máquina
virtual Linux mediante Azure Portal
Artículo • 10/10/2023

servidor) o el protocolo NFS (Network File System) estándar del sector. Los protocolos
NFS y SMB se admiten en máquinas virtuales (VM) de Azure que ejecutan Linux. En este
tutorial se muestra cómo crear un recurso compartido de archivos de Azure mediante el
protocolo NFS y conectarlo a una máquina virtual Linux.
En este tutorial, aprenderá lo siguiente:

＂ Implementación de una máquina virtual Linux
＂ Creación de un recurso compartido de archivos NFS
＂ Montaje del recurso compartido de archivos en la máquina virtual
Se aplica a
Introducción
Inicie sesión en Azure Portal .
Creación de una cuenta de almacenamiento FileStorage

Para poder trabajar con un recurso compartido de archivos NFS 4.1 de Azure, es
necesario que cree una cuenta de almacenamiento de Azure con el nivel de rendimiento
prémium. Actualmente, los recursos compartidos de NFS 4.1 solo están disponibles
como recursos compartidos de archivos prémium.
1. En el menú de Azure Portal, seleccione Todos los servicios. En la lista de recursos,

escriba Cuentas de almacenamiento. Cuando comience a escribir, la lista se filtrará
en función de la entrada. Seleccione Cuentas de almacenamiento.
2. En la ventana Cuentas de almacenamiento que aparece, elija + Crear.
3. En la pestaña Aspectos básicos, seleccione la suscripción en la que se va a crear la
cuenta de almacenamiento.
4. En el campo Grupo de recursos, seleccione Crear nuevo para crear un grupo de
recursos nuevo para usar en este tutorial.
5. Escriba un nombre para la cuenta de almacenamiento. El nombre que elija debe
ser único en Azure. El nombre también debe tener una longitud de entre 3 y 24
caracteres, y solo puede contener números y letras minúsculas.
6. Seleccione una región para la cuenta de almacenamiento o utilice la región
predeterminada. Azure admite recursos compartidos de archivos NFS en las
mismas regiones que admiten el almacenamiento de archivos prémium.
7. Seleccione el nivel de rendimiento Premium para almacenar los datos en unidades
de estado sólido (SSD). En Tipo de cuenta Premium, seleccione Recursos
compartidos de archivos.
8. Mantenga la opción de replicación establecida en su valor predeterminado de
Almacenamiento con redundancia local (LRS).
9. Seleccione Revisar y crear para revisar la configuración de la cuenta de
almacenamiento y crear la cuenta.
10. Cuando aparezca la notificación Validación superada, seleccione Crear. Debería
ver una notificación informándole de que la implementación está en curso.
En la imagen siguiente se muestra la configuración de la pestaña Aspectos básicos de

una nueva cuenta de almacenamiento:

Implementación de una máquina virtual de

Azure que ejecuta Linux
A continuación, cree una máquina virtual de Azure que ejecute Linux para representar el
servidor en el entorno local. Al crear la máquina virtual, se creará automáticamente una
red virtual. El protocolo NFS solo se puede usar desde una máquina dentro de una red
virtual.
1. Seleccione Inicio y, a continuación, Máquinas virtuales en Servicios de Azure.
2. Seleccione + Crear y, después, + Máquina virtual de Azure.
3. En la pestaña Aspectos básicos, en Detalles del proyecto, asegúrese de que la

suscripción y el grupo de recursos correctos están seleccionados. En Detalles de
instancia, escriba myVM en Nombre de máquina virtual y seleccione la misma
región que la cuenta de almacenamiento. Elija la distribución de Linux para la
imagen. Deje los demás valores predeterminados. El tamaño y los precios
predeterminados solo se muestran como ejemplo. La disponibilidad y los precios
del tamaño dependen de su región y suscripción.

4. En Cuenta de administrador , seleccione Clave pública SSH. Deje el resto de

valores predeterminados.
5. En Reglas de puerto de entrada > Puertos de entrada públicos, elija Permitir los
puertos seleccionados y luego seleccione SSH (22) y HTTP (80) en la lista
desplegable.

） Importante
Solo se recomienda establecer puertos SSH abiertos a Internet para realizar

pruebas. Si quiere cambiar esta configuración más adelante, vuelva a la
pestaña Aspectos básicos.
6. Seleccione el botón Revisar y crear de la parte inferior de la página.
7. En la página Crear una máquina virtual verá los detalles de la máquina virtual que
va a crear. Anote el nombre de la red virtual. Cuando esté preparado, seleccione
Crear.
8. Cuando se abra la ventana Generar nuevo par de claves, seleccione Descargar la

clave privada y crear el recurso. El archivo de clave se descargará como
myVM_key.pem. Asegúrese de saber dónde se descargó el archivo .pem, ya que
necesitará la ruta de acceso al archivo para conectarse a la máquina virtual.
Verá un mensaje que indica que la implementación está en curso. Espere unos minutos
a que se complete la implementación.

NFS de Azure
Ahora está listo para crear un recurso compartido de archivos NFS y proporcionar
seguridad de nivel de red para el tráfico NFS.
Adición de un recurso compartido de archivos a la cuenta

de almacenamiento
1. Seleccione Inicio y, a continuación, Cuentas de almacenamiento.
2. Seleccione la cuenta de almacenamiento que ha creado.
3. Seleccione Almacenamiento de datos y Recursos compartidos de archivos en el

panel de la cuenta de almacenamiento.
5. Asigne al nuevo recurso compartido de archivos el nombre qsfileshare y escriba

"100" para la Capacidad mínima aprovisionada o aprovisione más capacidad
(hasta 102 400 GiB) para obtener más rendimiento. Seleccione el protocolo NFS,
deje seleccionada la opción Sin restringir raíz y seleccione Crear.

Configurar un punto de conexión privado o un punto de

conexión de servicio
A continuación, configure un punto de conexión privado para la cuenta de
almacenamiento. Esto proporciona a la cuenta de almacenamiento una dirección IP
privada desde el espacio de direcciones de la red virtual. Se aplican las tasas de
procesamiento de datos estándar para los puntos de conexión privados. Si no
necesita una dirección IP estática, puede usar un punto de conexión de servicio en su
lugar. No se realiza ningún cargo adicional por el uso de puntos de conexión de servicio.
1. Seleccione el recurso compartido de archivos qsfileshare. Debería ver un cuadro de

diálogo que indica Conectar a este recurso compartido de NFS desde Linux. En
Configuración de red, seleccione Opciones de revisión.
2. A continuación, seleccione Configurar un punto de conexión privado.
3. Seleccione + Punto de conexión privado.

4. Deje Suscripción y Grupo de recursos como están. En Instancia, proporcione un
nombre y seleccione una región para el nuevo punto de conexión privado. El
punto de conexión privado debe estar en la misma región que la red virtual, por lo
que debe usar la misma región que especificó al crear la máquina virtual. Cuando
haya completado todos los campos, seleccione Siguiente: Recurso.
5. Confirme que la Suscripción, el Tipo de recurso y el Recurso son correctos y

seleccione Archivo en la lista desplegable Subrecurso de destino. A continuación,
seleccione Siguiente: Red virtual.

6. En Redes, seleccione la red virtual asociada a la máquina virtual y deje la subred
predeterminada. En la sección Configuración de IP privada, seleccione Asignar
dirección IP de forma dinámica. Seleccione Next: DNS (Siguiente: DNS).
7. En Integrar con la zona DNS privada, seleccione Sí. Asegúrese de que están
seleccionados la suscripción y el grupo de recursos correctos y, después,
seleccione Siguiente: Etiquetas.
8. Opcionalmente, puede aplicar etiquetas para clasificar los recursos, como aplicar el
nombre Entorno y el valor Prueba a todos los recursos de prueba. Escriba pares
nombre-valor si quiere y, a continuación, seleccione Siguiente: Revisar y crear.
9. Azure intentará validar el punto de conexión privado. Una vez completada la

validación, seleccione Crear. Verá una notificación informándole de que la
implementación está en curso. Transcurridos unos minutos, debería ver una
notificación indicando que la implementación se ha completado.
Deshabilitación de la transferencia segura

Azure Files no admite actualmente el cifrado en tránsito con el protocolo NFS y se basa
en la seguridad de nivel de red. Por lo tanto, deberá deshabilitar la transferencia segura.

almacenamiento.
4. Seleccione el recurso compartido de archivos NFS que ha creado. En

Configuración de transferencia segura, seleccione Cambiar configuración.

5. Cambie la opción Se requiere transferencia segura a Deshabilitado y seleccione
Guardar. El cambio puede tardar hasta 30 segundos en surtir efecto.

Cree una conexión SSH con la máquina virtual.
1. Seleccione Inicio y, a continuación, Máquinas virtuales.
2. Seleccione la máquina virtual Linux que ha creado para este tutorial y asegúrese de
que su estado es En ejecución. Tome nota de la dirección IP pública de la máquina
virtual y cópiela en el portapapeles.
3. Si está en una máquina Mac o Linux, abra un símbolo del sistema de Bash. Si está
en una máquina Windows, abra un símbolo del sistema de PowerShell.
4. Cuando se le solicite, abra una conexión SSH a la máquina virtual. Reemplace la

dirección IP por la de la máquina virtual y reemplace la ruta de acceso al archivo
.pem por la ruta de acceso a la ubicación en la que se descargó el archivo de clave.
Consola
ssh -i .\Downloads\myVM_key.pem azureuser@20.25.14.85
Si recibe una advertencia de que no se puede establecer la autenticidad del host, escriba
sí para continuar con la conexión a la máquina virtual. Deje abierta la conexión SSH para
el paso siguiente.
 Sugerencia
Ahora la clave SSH que creó se puede usar la próxima vez que cree una máquina
virtual en Azure. Solo tiene que seleccionar la opción Usar la clave existente
almacenada en Azure en Origen de clave pública SSH la próxima vez que cree una
máquina virtual. Ya dispone de la clave privada en el equipo, por lo que no tendrá
que descargar nada.
Montaje de recurso compartido de archivos

NFS
Ahora que ha creado un recurso compartido de NFS, para usarlo debe montarlo en el
cliente Linux.

almacenamiento y seleccione el recurso compartido de archivos NFS que ha
creado.
4. Debería consultar Conexión a este recurso compartido de archivos NFS desde

Linux junto con comandos de ejemplo para usar NFS en la distribución de Linux y
un script de montaje que contenga las opciones de montaje necesarias. Para ver
otras opciones de montaje recomendadas, consulte Montaje del recurso
compartido de archivos de Azure NFS en Linux.
） Importante
El script de montaje proporcionado montará el recurso compartido NFS solo
hasta que se reinicie la máquina Linux. Para montar automáticamente el
recurso compartido cada vez que se reinicia la máquina, consulte Montaje de
un recurso compartido NFS mediante /etc/fstab.
5. Seleccione su distribución de Linux.
6. Mediante la conexión SSH que ha creado con la máquina virtual, escriba los
comandos de ejemplo para usar NFS y montar el recurso compartido de archivos.
Ahora ha montado el recurso compartido de archivos NFS y está listo para almacenar
archivos.

2. Seleccione el grupo de recursos que ha creado para este tutorial.
Pasos siguientes
Obtenga más información sobre el uso de recursos compartidos de archivos NFS
de Azure
.
Tutorial: Extensión de servidores de
archivos de Windows con Azure File
Sync
Artículo • 01/06/2023
En este artículo se demuestran los pasos básicos para ampliar la capacidad de

almacenamiento de un servidor con Windows Server mediante Azure File Sync. Aunque
este tutorial presenta un servidor con Windows Server como una máquina virtual de
Azure, lo habitual es realizar este proceso para servidores locales. En el artículo
Implementación de Azure File Sync puede encontrar instrucciones para implementar
Azure File Sync en su propio entorno.
＂ Implementación del servicio de sincronización de almacenamiento

＂ Preparación de Windows Server para su uso con Azure File Sync
＂ Instalación del agente de Azure File Sync
＂ Registro de un servidor de Windows Server en el servicio de sincronización de
almacenamiento
＂ Creación de un grupo de sincronización y un punto de conexión en la nube
＂ Creación de un punto de conexión de servidor
Inicio de sesión en Azure

Preparación del entorno

Para este tutorial, deberá realizar las siguientes operaciones antes de implementar Azure
File Sync:
Crear una cuenta de Azure Storage y un recurso compartido

Configurar una máquina virtual con Windows Server 2019 Datacenter
Preparar la máquina virtual con Windows Server para Azure File Sync
Creación de una carpeta y un archivo .txt

En el equipo local, cree una carpeta nueva denominada FilesToSync y agregue un archivo
de texto denominado mytestdoc.txt. Dicho archivo se cargará en el recurso compartido
de archivos más adelante.

Para crear una cuenta de almacenamiento de uso general v2 en Azure Portal, siga estos
pasos:

2. En la página Cuentas de almacenamiento, elija + Create (+ Crear).
3. En la hoja Aspectos básicos, seleccione la suscripción en la que se va a crear la
4. En el campo Grupo de recursos, seleccione el grupo de recursos deseado o cree
uno nuevo. Para más información sobre los grupos de recursos de Azure, consulte
Información general de Azure Resource Manager.
5. Después, escriba un nombre para la cuenta de almacenamiento. El nombre que
elija debe ser único en Azure. El nombre también debe tener una longitud de entre
3 y 24 caracteres, y solo puede contener números y letras minúsculas.
predeterminada.
7. Seleccione un nivel de rendimiento. El valor predeterminado es Estándar.
8. Especifique cómo se replicará la cuenta de almacenamiento. La opción de
redundancia predeterminada es Almacenamiento con redundancia geográfica (GRS)
. Para más información acerca de las opciones de replicación disponibles, consulte
Redundancia de Azure Storage.
9. Hay otras opciones disponibles en las hojas Opciones avanzadas, Redes,
Protección de datos y Etiquetas. Para utilizar Azure Data Lake Storage, elija la hoja
Opciones avanzadas y, después, establezca Espacio de nombres jerárquico en
Habilitado. Para más información, consulte Introducción a Azure Data Lake
Storage Gen2.
11. Seleccione Crear.
En la imagen siguiente se muestra la configuración de la hoja Aspectos básicos de una

nueva cuenta de almacenamiento:


Tras implementar una cuenta de Azure Storage, siga estos pasos para crear un recurso
1. En Azure Portal, seleccione Ir al recurso.
2. En el menú de la izquierda, seleccione Almacenamiento de datos>Recursos

4. Asigne al nuevo recurso compartido de archivos el nombre afsfileshare, deje el

nivel establecido en Optimizado para transacciones y, luego, seleccione Crear. Solo
necesita 5 TiB para este tutorial.
5. Seleccione el recurso compartido de archivos nuevo. En la ubicación del recurso
compartido de archivos, seleccione Cargar.
6. Vaya a la carpeta FilesToSync en la máquina local en la que creó el archivo .txt,

seleccione mytestdoc.txt y, después, seleccione Cargar.
Ya ha creado una cuenta de almacenamiento y un recurso compartido de archivos con

un archivo en él. A continuación, implementará una VM de Azure con Windows Server
2019 Datacenter que representará el servidor local en este tutorial.
Implementación de una máquina virtual y conexión de un
disco de datos
1. Seleccione Inicio en Azure Portal y, en Servicios de Azure, seleccione + Crear un
recurso.
2. En Servicios populares de Azure, seleccione Máquina virtual>Crear.
3. En Detalles del proyecto, seleccione la suscripción y el grupo de recursos que creó

para este tutorial.
4. En Detalles de instancia, especifique el nombre de la máquina virtual. Por ejemplo,

use MiVM.
5. No cambie la configuración predeterminada en Región, Opciones de

disponibilidad y Tipo de seguridad.
6. En Imagen seleccione Windows Server 2019 Datacenter - Gen2. Deje Tamaño

establecido en el valor predeterminado.
7. En Cuenta de administrador, especifique el nombre de usuario y la contraseña de
la máquina virtual. El nombre de usuario debe tener entre 1 y 20 caracteres y no
puede contener caracteres especiales \/""[]:|<>+=;,?*@& ni terminar con '.' La
contraseña debe tener entre 12 y 123 caracteres y debe tener 3 de las siguientes
opciones: 1 carácter en minúsculas, 1 carácter en mayúscula, 1 número y 1 carácter
especial.
8. En Reglas de puerto de entrada, elija Permitir los puertos seleccionados y, luego,

seleccione RDP (3389) y HTTP (80) en el menú desplegable.
9. Antes de crear la máquina virtual, es preciso crear un disco de datos.
a. En la parte inferior de la página, seleccione Siguiente: Discos.
b. En la pestaña Discos, en Opciones de disco, deje los valores predeterminados.
c. En Discos de datos, seleccione Crear y adjuntar un nuevo disco.
d. Use la configuración predeterminada, salvo en Tamaño, que se puede cambiar a

4 GiB para este tutorial al seleccionar Cambiar tamaño.
e. Seleccione Aceptar.
Puede seleccionar el icono Notificaciones para ver el progreso de la

implementación. La creación de una máquina virtual tarda varios minutos en
completarse.
12. Después de que se complete la implementación de la máquina virtual, seleccione Ir

al recurso.
Ya ha creado una nueva máquina virtual y ha conectado un disco de datos. Después,

conéctese a la máquina virtual.

1. En Azure Portal, seleccione Conectar>RDP en la página de propiedades de la VM.
2. En la página Conectar, mantenga las opciones predeterminadas para conectarse
mediante la dirección IP pública a través del puerto 3389. Seleccione Descargar
archivo RDP.
3. Abra el archivo RDP que descargó y haga clic en Conectar cuando se le solicite. Es
posible que vea la siguiente advertencia: No se puede identificar el publicador de
esta conexión remota. Haga clic en Conectar de todos modos.
4. En la ventana Seguridad de Windows que le pide que escriba las credenciales,

seleccione Más opciones y, luego, Usar otra cuenta. Escriba localhost\username en
el campo dirección de correo electrónico, escriba la contraseña que creó para la
VM y, después, seleccione Aceptar.
5. Es posible que reciba una advertencia de certificado durante el proceso de inicio
de sesión que indica que no se puede comprobar la identidad del equipo remoto.
Seleccione Sí o Continuar para crear la conexión.
Preparación de la VM con Windows Server

En el caso de la VM con Windows Server 2019 Datacenter, deshabilite Configuración de
seguridad mejorada de Internet Explorer. Este paso solo es necesario para el registro
inicial del servidor. Se puede volver a habilitar una vez registrado el servidor.
En la VM con Windows Server 2019 Datacenter, el Administrador del servidor se abre

automáticamente. Si el Administrador del servidor no se abre de forma predeterminada,
búsquelo en el menú Inicio.
1. En el Administrador del servidor, seleccione Servidor local.
2. En el panel Propiedades, busque la entrada de Configuración de seguridad

mejorada de IE y haga clic en Activar.
3. En el cuadro de diálogo Configuración de seguridad mejorada de Internet

Explorer, seleccione Desactivar en Administradores y Usuarios y, luego, seleccione
Aceptar.
Ya puede agregar el disco de datos a la máquina virtual.
Incorporación del disco de datos

1. En la VM con Windows Server 2019 Datacenter, haga clic en Files and storage
services>Volumes>Disks (Archivos y servicios de almacenamiento > Volúmenes >
Discos).
2. Haga clic con el botón derecho en el disco de 4 GiB llamado Msft Virtual Disk y
seleccione New volume (Volumen nuevo).
3. Finalice el asistente. Use la configuración predeterminada y tome nota de la letra

de unidad asignada.
5. Seleccione Cerrar.
Ya está el disco en línea y ha creado un volumen. Abra el Explorador de archivos en
la máquina virtual de Windows Server para confirmar la presencia del disco de
datos recién agregado.
6. En el Explorador de archivos de la máquina virtual, expanda Este PC y abra la

nueva unidad. En este ejemplo es la unidad F:.
7. Haga clic con el botón derecho y seleccione Nueva>carpeta. Asigne a la carpeta el

nombre FilesToSync.
8. Abra la carpeta FilesToSync.
9. Haga clic con el botón derecho y seleccione Nuevo>Documento de texto. Asigne

el archivo de texto el nombre MyTestFile.
10. Cierre el Explorador de archivos y el Administrador del servidor.
Instalación del módulo de Azure PowerShell

A continuación, en la VM con Windows Server 2019 Datacenter, instale el módulo de
Azure PowerShell en el servidor. El módulo Az es un módulo acumulativo para los
cmdlets de Azure PowerShell. Al instalarlo, se descargan todos los módulos disponibles
de Azure Resource Manager y hace que sus cmdlets estén disponibles para su uso.
1. En la VM, abra una ventana de PowerShell con privilegios elevados (ejecute como
administrador).
2. Ejecute el siguiente comando:
PowerShell
Install-Module -Name Az
７ Nota
Si tiene una versión de NuGet anterior a la 2.8.5.201, se le pedirá que

descargue e instale la versión más reciente.
De forma predeterminada, la Galería de PowerShell no está configurada como un

repositorio de confianza para PowerShellGet. La primera vez que use PSGallery
verá el siguiente mensaje:
Resultados
Untrusted repository
You are installing the modules from an untrusted repository. If you

trust this repository, change its InstallationPolicy value by running
the Set-PSRepository cmdlet.
Are you sure you want to install the modules from 'PSGallery'?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "N"):
3. Responda Sí o Sí a todo para continuar con la instalación.
Ya ha configurado el entorno para el tutorial Cierre la ventana de PowerShell. y está listo

para implementar el servicio de sincronización de almacenamiento.
Implementación del servicio de sincronización

de almacenamiento
Para implementar Azure File Sync, en primer lugar coloque un recurso del servicio de
sincronización de almacenamiento en un grupo de recursos de la suscripción
seleccionada. El servicio de sincronización de almacenamiento hereda los permisos de
acceso de su suscripción y del grupo de recursos.
1. En Azure Portal, seleccione Crear un recurso y busque Azure File Sync.
2. En los resultados de la búsqueda, haga clic en Azure File Sync.
3. Seleccione Crear para abrir la pestaña Implementar Azure File Sync.

En el panel que se abre, escriba la siguiente información:
Value Descripción
Nombre Un nombre único (por suscripción) para el servicio de sincronización de

almacenamiento.
Use afssyncservice02 para este tutorial.
Suscripción La suscripción de Azure que utiliza para este tutorial.
Grupos de el grupo de recursos que contiene el servicio de sincronización de

recursos almacenamiento.
Use myexamplegroup para este tutorial.
Ubicación Este de EE. UU.
4. Cuando termine, seleccione Revisar y crear y, luego, Crear para implementar el

Servicio de sincronización de almacenamiento. La implementación del servicio
tardará varios minutos.
5. Cuando la implementación se complete, seleccione Ir al grupo de recursos.
Instalación del agente de Azure File Sync

El agente de Azure File Sync es un paquete descargable que permite la sincronización
de Windows Server con un recurso compartido de archivos de Azure.
1. En la VM con Windows Server 2019 Datacenter, abra Internet Explorer.
） Importante
Es posible que vea una advertencia que le indica que active la configuración
de seguridad mejorada de Internet Explorer. No vuelva a activarla hasta que
haya terminado de registrar el servidor en el paso siguiente.
2. Vaya al Centro de descarga de Microsoft . Desplácese hacia abajo hasta la

sección Azure File Sync Agent (agente de Azure File Sync) y haga clic en
Download (Descargar).
3. Seleccione la casilla de StorageSyncAgent_WS2019.msi y, después, Siguiente.
4. Seleccione Permitir una vez>Run.
5. Siga el Asistente para instalación de agente de sincronización de

almacenamiento y acepte los valores predeterminados.
6. Seleccione Instalar.
7. Seleccione Finalizar.
Ha implementado el Servicio de sincronización de Azure e instalado el agente en la VM

con Windows Server. Ahora tiene que registrar la máquina virtual en el servicio de
sincronización de almacenamiento.
Registro de Windows Server

Si el servidor de Windows Server se registra en un servicio de sincronización de
almacenamiento, se establece una relación de confianza entre el servidor (o el clúster) y
el servicio. Un servidor no se puede registrar en más de un servicio de sincronización de
almacenamiento. No obstante, se puede sincronizar con otros servidores y recursos
compartidos de archivos de Azure asociados con dicho servicio.
Tras la instalación del agente de Azure File Sync, la interfaz de usuario de Registro del
servidor se debería abrir automáticamente. Si no es así, puede abrirla manualmente
desde su ubicación de archivo: C:\Program
Files\Azure\StorageSyncAgent\ServerRegistration.exe.
1. Cuando la interfaz de usuario del registro del servidor se abra en la VM, seleccione
Iniciar sesión.
2. Inicie sesión con las credenciales de su cuenta de Azure.
3. Proporcione la siguiente información:

Value Descripción
Suscripción de Azure La suscripción que contiene el servicio de sincronización de

almacenamiento de este tutorial.
Grupo de recursos el grupo de recursos que contiene el servicio de sincronización

de almacenamiento. Use myexamplegroup para este tutorial.
Servicio de El nombre del servicio de sincronización de almacenamiento. Use

sincronización de afssyncservice02 para este tutorial.
almacenamiento
4. Seleccione Registrar para completar el registro del servidor.
5. Como parte del proceso de registro, se le solicita un que vuelva a iniciar sesión.
Inicie sesión y seleccione Siguiente.
6. Seleccione Aceptar.
Creación de un grupo de sincronización

Un grupo de sincronización define la topología de sincronización de un conjunto de
archivos. Un grupo de sincronización debe contener un punto de conexión en la nube,
que representa un recurso compartido de archivos de Azure. También debe contener
uno o varios puntos de conexión de servidor. Un punto de conexión de servidor
representa una ruta de acceso en un servidor registrado. Para crear un grupo de
sincronización:
1. En Azure Portal , seleccione + Grupo de sincronización en el servicio de

sincronización de almacenamiento que ha implementado.
2. Escriba la siguiente información para crear un grupo de sincronización con un

punto de conexión en la nube:
Value Descripción
Value Descripción
Nombre del Este nombre debe ser único dentro del servicio de sincronización de
grupo de almacenamiento, pero puede ser cualquier nombre que considere
sincronización lógico.
Suscripción La suscripción en la que se ha implementado el servicio de

sincronización de almacenamiento de este tutorial.
Cuenta de Elija Seleccionar cuenta de almacenamiento. En el panel que aparece,

almacenamiento seleccione la cuenta de almacenamiento que tiene el recurso
compartido de archivos de Azure que ha creado.
Recurso El nombre del recurso compartido de archivos de Azure que ha creado.

compartido de
archivos de
Azure
Si selecciona el grupo de sincronización, puede ver que ahora tiene uno punto de
conexión en la nube.
Adición de un punto de conexión de servidor

Un punto de conexión del servidor representa una ubicación concreta en un servidor
registrado. Por ejemplo, una carpeta en un volumen de servidor. Para agregar un punto
de conexión del servidor:
1. Seleccione al grupo de sincronización recién creado y, después, seleccione

Agregar punto de conexión del servidor.
2. En el panel Agregar punto de conexión del servidor, escriba la siguiente

información para crear un punto de conexión del servidor:
Value Descripción
Servidor registrado El nombre del servidor que ha creado. Por ejemplo, myVM.
Path La ruta de acceso del servidor de Windows Server a la unidad que

ha creado. Por ejemplo, f:\filestosync.
Nube por niveles Déjelo deshabilitado para este tutorial.
Espacio disponible Déjelo en blanco para este tutorial.

del volumen
Los archivos ya están sincronizados entre el recurso compartido de archivos de Azure y

Windows Server.
Si desea limpiar los recursos que ha creado en este tutorial, primero elimine los puntos
de conexión del servicio de sincronización de almacenamiento. A continuación, anule el
registro del servidor con el servicio de sincronización de almacenamiento, quite los
grupos de sincronización y elimine el servicio de sincronización.


Pasos siguientes
En este tutorial, ha aprendido los pasos básicos necesarios para ampliar la capacidad de
almacenamiento de un servidor con Windows Server mediante Azure File Sync. Para
obtener una visión más completa del planeamiento de una implementación de Azure
File Sync, consulte:
Planeamiento de una implementación de Azure Files Sync

Planeamiento de una implementación
de Azure Files
Artículo • 05/10/2023
Puede implementar Azure Files de dos formas: montando directamente los recursos
compartidos de archivos de Azure sin servidor o almacenando en caché recursos
compartidos de archivos de Azure localmente mediante Azure File Sync. Las
consideraciones de implementación cambiarán en función de la opción que escoja.
Montaje directo de un recurso compartido de archivos de Azure: dado que Azure

Files proporciona acceso mediante Bloque de mensajes del servidor (SMB) o
Network File System (NFS), puede montar recursos compartidos de archivos de
Azure en el entorno local o en la nube mediante los clientes SMB o NFS estándar
disponibles en el sistema operativo. Dado que los recursos compartidos de
archivos de Azure no tienen servidor, la implementación en escenarios de
producción no requiere la administración de un servidor de archivos o un
dispositivo NAS. lo que significa que no tiene que aplicar revisiones de software ni
intercambiar discos físicos.
Almacenamiento en caché de recursos compartidos de archivos de Azure

localmente con Azure File Sync: Azure File Sync le permite centralizar los recursos
compartidos de archivos de su organización en Azure Files sin renunciar a la
flexibilidad, el rendimiento y la compatibilidad de un servidor de archivos local.
Azure File Sync transforma una instancia de Windows Server local (o en la nube) en
una caché rápida del recurso compartido de archivos SMB de Azure.
En este artículo se abordan principalmente las consideraciones de implementación de

un recurso compartido de archivos de Azure que se va a montar directamente mediante
un cliente local o en la nube. Para planear una implementación de Azure File Sync,
consulte Planeamiento de una implementación de Azure File Sync.
Protocolos disponibles
Azure Files ofrece dos protocolos de sistema de archivos estándar del sector para
montar recursos compartidos de archivos de Azure: el protocolo Bloque de mensajes
del servidor (SMB) y el protocolo Network File System (NFS), permitiéndole elegir el
protocolo que se ajuste más a su carga de trabajo. Los recursos compartidos de archivos
de Azure no admiten los protocolos SMB y NFS en el mismo recurso compartido de
archivos, aunque puede crear recursos compartidos de archivos de Azure SMB y NFS
dentro de la misma cuenta de almacenamiento. Actualmente, NFS 4.1 solo se admite en
el nuevo tipo de cuenta de almacenamiento FileStorage (solo recursos compartidos de
archivos premium).
Con los recursos compartidos de archivos SMB y NFS, Azure Files ofrece recursos
compartidos de archivos de nivel empresarial que se pueden escalar verticalmente para
satisfacer sus necesidades de almacenamiento y a los que pueden acceder
simultáneamente miles de clientes.
Característica SMB NFS
Versiones de protocolo SMB 3.1.1, SMB 3.0, SMB 2.1 NFS 4.1
admitidas
SO recomendado Windows 11, versión 21H2+ Versión posterior a la 4.3 del

Windows 10, versión 21H1 o kernel de Linux
posterior
Windows Server 2019 o posterior
Versión 5.3 o posterior del kernel
de Linux
Niveles disponibles Premium, optimizado para Premium

transacciones, acceso frecuente y
acceso esporádico
Modelo de facturación Capacidad aprovisionada para Capacidad aprovisionada

recursos compartidos de archivos
premium
Pago por uso para recursos
compartidos de archivos estándar
Puntos de conexión de Compatible Compatible

zona de Azure DNS
(versión preliminar)
Redundancia LRS, ZRS, GRS, GZRS LRS, ZRS
Semántica del sistema Win32 POSIX

de archivos
Authentication Autenticación basada en identidad Autenticación basada en

(Kerberos), autenticación de clave host
compartida (NTLMv2)
Authorization Listas de control de acceso (ACL) de Permisos de estilo UNIX

estilo Win32
Distinción entre Sin distinción de mayúsculas y Distingue mayúsculas de

mayúsculas y minúsculas, conservación de minúsculas
minúsculas mayúsculas y minúsculas
Eliminación o Solo con bloqueo Sí

modificación de
archivos abiertos
Uso compartido de Modo de uso compartido de Windows Network Lock Manager con
archivos bloqueo aconsejado de
intervalo de bytes
Compatibilidad con No compatible Compatible

vínculos físicos
Compatibilidad con los No compatible Compatible

vínculos simbólicos
Opcionalmente Sí (solo SMB 3.0 o posterior) No

accesible desde Internet
Admite FileREST Sí Subconjunto:
Operaciones en
FileService
Operaciones en
FileShares
Operaciones en
Directories
Operaciones en Files
Bloqueos de intervalo Compatible No compatible

de bytes obligatorios
Bloqueos de intervalo No compatible Compatible

de bytes de aviso
Atributos extendidos o No compatible No compatible

con nombre
Flujos de datos No compatible N/D

alternativos
Identificadores de No compatible N/D

objeto
Puntos de repetición de No compatible N/D

análisis
Archivos dispersos No compatible N/D

Compresión No compatible N/D
Canalizaciones con No compatible N/D

nombre
SMB directo No compatible N/D
Concesión de directorio No compatible N/D

SMB
Instantánea de volumen No compatible N/D
Nombres de archivos No compatible N/D

cortos (alias 8.3)
Servicio de servidor No compatible N/D
Transacciones del No compatible N/D

sistema de archivos
(TxF)
Conceptos de administración
Los recursos compartidos de archivos de Azure se implementan en cuentas de
almacenamiento, que son objetos de nivel superior que representan un grupo
compartido de almacenamiento. Este grupo de almacenamiento se puede usar para
implementar varios recursos compartidos de archivos, así como otros recursos de
almacenamiento, tales como contenedores de blobs, colas o tablas. Todos los recursos
de almacenamiento que se implementan en una cuenta de almacenamiento comparten
los límites que se aplican a esa cuenta de almacenamiento. Para ver los límites actuales
de una cuenta de almacenamiento, consulte Objetivos de escalabilidad y rendimiento
de Azure Files.
Hay dos tipos principales de cuentas de almacenamiento que se usarán para las
implementaciones de Azure Files:
Cuentas de almacenamiento de uso general, versión 2 (GPv2) : Las cuentas de

almacenamiento de GPv2 permiten implementar recursos compartidos de archivos
de Azure en hardware estándar o basado en disco duro (HDD). Además de
almacenar recursos compartidos de archivos de Azure, las cuentas de
almacenamiento de GPv2 pueden almacenar otros recursos de almacenamiento,
como contenedores de blobs, colas o tablas.
Cuentas de almacenamiento FileStorage: Las cuentas de almacenamiento
FileStorage permiten implementar recursos compartidos de archivos de Azure en
hardware prémium o basado en unidades de estado sólido (SSD). Las cuentas
FileStorage solo se pueden usar para almacenar recursos compartidos de archivos
de Azure. No se puede implementar ningún otro recurso de almacenamiento
(contenedores de blobs, colas, tablas, etc.) en una cuenta FileStorage. Solo las
cuentas de FileStorage pueden implementar recursos compartidos de archivos
SMB y NFS.
Existen otros tipos de cuenta de almacenamiento que puede encontrar en el Azure

Portal, PowerShell o la CLI. Dos tipos de cuentas de almacenamiento, BlockBlobStorage
y BlobStorage, no pueden contener recursos compartidos de archivos de Azure. Los
otros dos tipos de cuenta de almacenamiento que puede ver son las cuentas de
almacenamiento clásico y de uso general de la versión 1 (GPv1), y ambas pueden
contener recursos compartidos de archivos de Azure. Aunque las cuentas de
almacenamiento clásico y de GPv1 pueden contener recursos compartidos de archivos
de Azure, la mayoría de las nuevas características de Azure Files solo están disponibles
en las cuentas de almacenamiento de GPv2 y FileStorage. Por lo tanto, se recomienda
usar solo las cuentas de almacenamiento de GPv2 y FileStorage para las nuevas
implementaciones, así como actualizar las cuentas de almacenamiento de GPv1 y clásico
si ya existen en su entorno.
Al implementar recursos compartidos de archivos de Azure en cuentas de

almacenamiento, se recomienda:
Implementar solo recursos compartidos de archivos de Azure en cuentas de

almacenamiento con otros recursos compartidos de archivos de Azure. Aunque las
cuentas de almacenamiento de GPv2 permiten tener cuentas de almacenamiento
de propósito combinado, dado que los recursos de almacenamiento como los
recursos compartidos de archivos de Azure y los contenedores de blobs
comparten los límites de la cuenta de almacenamiento, la combinación de recursos
puede dificultar la solución de problemas de rendimiento más adelante.
Prestar atención a las limitaciones de IOPS de la cuenta de almacenamiento al

implementar recursos compartidos de archivos de Azure. Lo ideal sería asignar
recursos compartidos de archivos 1:1 con cuentas de almacenamiento. Sin
embargo, quizás no sea posible debido a diversos límites y restricciones, tanto de
su organización como de Azure. Cuando no sea posible tener un solo recurso
compartido de archivos implementado en una cuenta de almacenamiento, tenga
en cuenta qué recursos compartidos estarán muy activos y cuales estarán menos
activos, con el fin de asegurarse de que los recursos compartidos de archivos más
activos no se colocan en la misma cuenta de almacenamiento.
Implementar solamente cuentas de GPv2 y FileStorage, y actualizar las cuentas de
almacenamiento clásicas y de GPv1, cuando las encuentre en su entorno.
Identidad
Para acceder a un recurso compartido de archivos de Azure, el usuario debe estar
autenticado y tener la debida autorización. Esto se hace en función de la identidad del
usuario que accede al recurso compartido de archivos. Azure Files admite los siguientes
métodos de autenticación:
Active Directory Domain Services local (AD DS, o AD DS local): las cuentas de
almacenamiento de Azure pueden estar unidas a un dominio de Active Directory
Domain Services propiedad del cliente, al igual que un servidor de archivos de
Windows Server o un dispositivo NAS. Puede implementar un controlador de
dominio en el entorno local, en una VM de Azure o, incluso, como VM en otro
proveedor de nube. Azure Files es independiente de la ubicación donde se
hospeda el controlador de dominio. Una vez que una cuenta de almacenamiento
está unida a un dominio, el usuario final puede montar un recurso compartido de
archivos con la cuenta de usuario con la que inició sesión en su equipo. La
autenticación basada en AD usa el protocolo de autenticación Kerberos.
Microsoft Entra Domain Services: Microsoft Entra Domain Services proporciona
un controlador de dominio administrado por Microsoft que se puede usar para los
recursos de Azure. La unión a un dominio de la cuenta de almacenamiento a
Microsoft Entra Domain Services proporciona ventajas similares a la unión a un
dominio de dicha cuenta a una instancia de AD DS propiedad del cliente. Esta
opción de implementación es especialmente útil para escenarios de migración
mediante lift-and-shift de aplicaciones que requieren permisos basados en AD.
Dado que Microsoft Entra Domain Services proporciona autenticación basada en
AD, esta opción también usa el protocolo de autenticación Kerberos.
Microsoft Entra Kerberos para identidades híbridas: Microsoft Entra Kerberos
permite usar Microsoft Entra ID para autenticar identidades de usuario híbridas,
que son identidades de AD locales que se sincronizan con la nube. Esta
configuración usa Microsoft Entra ID para emitir tickets de Kerberos para acceder
al archivo compartido con el protocolo SMB. Esto significa que los usuarios finales
pueden acceder a los recursos compartidos de archivos de Azure a través de
Internet sin necesidad de una línea de visión a los controladores de dominio desde
las máquinas virtuales unidas de forma híbrida a Microsoft Entra y unidas a
Microsoft Entra.
Autenticación de Active Directory a través de SMB para clientes Linux:
Azure Files admite la autenticación basada en identidades a través de SMB para
clientes Linux mediante el protocolo de autenticación Kerberos mediante AD DS o
Microsoft Entra Domain Services.
Clave de la cuenta de Azure Storage: los recursos compartidos de archivos de
Azure también se pueden montar con una clave de cuenta de almacenamiento de
Azure. Para montar un recurso compartido de archivos de esta forma, el nombre
de la cuenta de almacenamiento se usa como nombre de usuario y la clave de la
cuenta de almacenamiento se usa como contraseña. El uso de la clave de la cuenta
de almacenamiento para montar el recurso compartido de archivos de Azure es
realmente una operación de administrador, porque el recurso compartido de
archivos montado tendrá permisos completos para todos los archivos y todas las
carpetas del recurso compartido, aunque tengan ACL. Cuando se usa la clave de la
cuenta de almacenamiento para el montaje a través de SMB, se usa el protocolo
de autenticación NTLMv2. Si tiene previsto usar la clave de la cuenta de
almacenamiento para acceder a los recursos compartidos de archivos de Azure, se
recomienda usar puntos de conexión privados o puntos de conexión de servicio
como se describe en la sección Redes.
En el caso de los clientes que realizan la migración desde servidores de archivos locales
o que crean nuevos recursos compartidos de archivos en Azure Files destinados a
comportarse como servidores de archivos de Windows o dispositivos NAS, la unión a un
dominio de la cuenta de almacenamiento a una instancia AD DS propiedad del cliente
es la opción recomendada. Para obtener más información sobre la unión de dominio de
su cuenta de almacenamiento a un AD DS propiedad del cliente, consulte Información
general: autenticación de Active Directory Domain Services local en SMB para recursos
compartidos de archivos de Azure.
Redes
El montaje directo del recurso compartido de archivos de Azure a menudo requiere
cierta idea sobre la configuración de red, debido a las siguientes razones:
El puerto que usan los recursos compartidos de archivos SMB para la

comunicación, el puerto 445, se suele bloquear por parte de muchas
organizaciones y proveedores de servicios de Internet (ISP) para el tráfico saliente
(Internet).
Los recursos compartidos de archivos NFS se basan en la autenticación de nivel de
red y, por tanto, solo son accesibles mediante redes restringidas. El uso de un
recurso compartido de archivos NFS siempre requiere algún nivel de configuración
de redes.
Para configurar las redes, Azure Files proporciona un punto de conexión público
accesible a través de Internet e integración con características de red de Azure como
puntos de conexión de servicio, que ayudan a restringir el punto de conexión público a
redes virtuales específicas y puntos de conexión privados, que proporcionan a la cuenta
de almacenamiento una dirección IP privada desde un espacio de direcciones IP de red
virtual. Aunque no hay ningún cargo adicional por el uso de puntos de conexión
públicos o puntos de conexión de servicio, las tasas de procesamiento de datos
estándar se aplican a los puntos de conexión privados.
Desde un punto de vista práctico, esto significa que deberá tener en cuenta las
siguientes configuraciones de red:
Si el protocolo necesario es SMB y todo el acceso a través de SMB procede de

clientes de Azure, no se requiere ninguna configuración de conexión en red
especial.
Si el protocolo requerido es SMB y el acceso es desde clientes locales, entonces se
requiere una conexión VPN o ExpressRoute desde los locales a su red Azure, con
Azure Files expuestos en su red interna usando puntos de conexión privados.
Si el protocolo necesario es NFS, puede usar puntos de conexión de servicio o
puntos de conexión privados para restringir la red a redes virtuales específicas. Si
necesita una dirección IP estática o la carga de trabajo requiere alta disponibilidad,
use un punto de conexión privado.
Para más información sobre cómo configurar las redes para Azure Files, consulte
Consideraciones sobre redes de Azure Files.
Además de conectarse directamente al recurso compartido de archivos mediante el

punto de conexión público o mediante una conexión VPN o ExpressRoute con un punto
de conexión privado, SMB proporciona una estrategia de acceso de cliente adicional:
SMB a través de QUIC. SMB vía QUIC ofrece "VPN SMB" de configuración cero para el
acceso SMB a través del protocolo de transporte QUIC. Aunque Azure Files no admite
directamente SMB a través de QUIC, puede crear una caché ligera de los recursos
compartidos de archivos de Azure en una máquina virtual de Azure Edition de Windows
Server 2022 mediante Azure File Sync. Para más información sobre esta opción, consulte
SMB a través de QUIC con Azure File Sync.
Cifrado
Azure Files admite dos tipos diferentes de cifrado:
Cifrado en tránsito, que se relaciona con el cifrado usado al montar o acceder al

recurso compartido de archivos de Azure
Cifrado en reposo, que se relaciona con la manera en que cifran los datos cuando
se almacenan en el disco
Cifrado en tránsito
） Importante
En esta sección se tratan los detalles del cifrado en tránsito para recursos
compartidos SMB. Para más información sobre el cifrado en tránsito con recursos
compartidos de NFS, consulte Seguridad y redes.
De forma predeterminada, todas las cuentas de Azure Storage tienen habilitado el

cifrado en tránsito. Esto significa que, al montar un recurso compartido de archivos a
través de SMB o acceder a él a través del protocolo de FileREST (por ejemplo, a través
de Azure Portal, la CLI o PowerShell, o los SDK de Azure), Azure Files solo permitirá la
conexión si se realiza con una versión posterior a SMB 3.x con cifrado o HTTPS. Los
clientes que no admiten SMB 3.x, o los clientes que admiten SMB 3.x pero no el cifrado
SMB, no podrán montar el recurso compartido de archivos de Azure si está habilitado el
cifrado en tránsito. Para obtener más información sobre qué sistemas operativos
admiten SMB 3.x con cifrado, consulte nuestra documentación para Windows, macOS y
Linux. Todas las versiones actuales de PowerShell, la CLI y los SDK admiten HTTPS.
Puede deshabilitar el cifrado en tránsito para una cuenta de almacenamiento de Azure.

Cuando el cifrado está deshabilitado, Azure Files también permite el uso de SMB 2.1 y
SMB 3.x sin cifrado, y de llamadas a la API de FileREST sin cifrar a través de HTTP. La
razón principal para deshabilitar el cifrado en tránsito es admitir una aplicación
heredada que debe ejecutarse en un sistema operativo anterior, como Windows Server
2008 R2 o una distribución de Linux anterior. Azure Files solo permite conexiones
SMB 2.1 dentro de la misma región de Azure del recurso compartido de archivos de
Azure. Un cliente SMB 2.1 fuera de la región de Azure del recurso compartido de
archivos de Azure (por ejemplo, en un entorno local o en una región de Azure diferente)
no podrá acceder al recurso compartido de archivos.
Se recomienda encarecidamente asegurarse de que está habilitado el cifrado de los

datos en tránsito.
Para obtener más información sobre el cifrado en tránsito, consulte Requerir

transferencia segura en Azure Storage.
Cifrado en reposo
Todos los datos almacenados en Azure Files se cifran en reposo mediante el cifrado de
servicio de almacenamiento (SSE) de Azure. El cifrado del servicio de almacenamiento
funciona de forma similar a BitLocker en Windows: los datos se cifran bajo el nivel del
sistema de archivos. Dado que los datos se cifran bajo el sistema de archivos del recurso
compartido de archivos de Azure, ya que se codifican en el disco, no es necesario tener
acceso a la clave subyacente en el cliente para leer o escribir en dicho recurso
compartido. El cifrado en reposo se aplica a los protocolos SMB y NFS.
De manera predeterminada, los datos almacenados en Azure Files se cifran con claves
administradas por Microsoft. Con las claves administradas por Microsoft, Microsoft
mantiene las claves para cifrar o descifrar los datos y es responsable de rotarlas de
forma periódica. También puede elegir administrar sus propias claves, lo que le permitirá
controlar el proceso de rotación. Si decide cifrar los recursos compartidos de archivos
con claves administradas por el cliente, Azure Files está autorizado para tener acceso a
las claves con el fin de satisfacer las solicitudes de lectura y escritura de los clientes. Con
las claves administradas por el cliente, puede revocar esta autorización en cualquier
momento, pero esto significa que el recurso compartido de archivos de Azure ya no
será accesible a través de SMB o la API FileREST.
Azure Files usa el mismo esquema de cifrado que los otros servicios de almacenamiento
de Azure, como Azure Blob Storage. Para aprender más sobre el cifrado del servicio de
almacenamiento (SSE) de Azure, consulte Cifrado de Azure Storage para datos en
reposo.
Protección de los datos

Azure Files tiene un enfoque de varias capas para garantizar la copia de seguridad de
los datos, su recuperación y su protección contra amenazas de seguridad. Consulte
Introducción a la protección de datos de Azure Files.
Eliminación temporal
La eliminación temporal es una configuración de nivel de cuenta de almacenamiento de
recursos compartidos de archivos de SMB que permite recuperar el recurso compartido
de archivos cuando se elimina accidentalmente. Cuando se elimina un recurso
compartido de archivos, pasa a un estado de eliminación temporal, en lugar de borrarse
de forma permanente. Se puede configurar el tiempo durante el que los recursos
compartidos eliminados de forma temporal se pueden recuperar antes de que se
eliminen permanentemente y durante este período de retención el recurso compartido
se puede recuperar en cualquier momento.
La eliminación temporal está habilitada de manera predeterminada para las nuevas
cuentas de almacenamiento desde enero de 2021 y se recomienda dejarla activada para
la mayoría de los recursos compartidos de archivos SMB. Si tiene un flujo de trabajo en
el que la eliminación de recursos compartidos es común y se espera, puede que decida
tener un período de retención corto o no tener habilitada la eliminación temporal. La
eliminación temporal no funciona con los recursos compartidos de NFS, incluso si está
habilitada para la cuenta de almacenamiento.
Para obtener más información acerca de la eliminación temporal, consulte Evitar la

eliminación accidental de datos.
Copia de seguridad
Puede realizar una copia de seguridad del recurso compartido de archivos de Azure a
través de instantáneas de recurso compartido, que son copias de solo lectura de un
momento dado del recurso compartido. Las instantáneas son incrementales, lo que
significa que solo contienen los datos que han cambiado desde la instantánea anterior.
Puede tener hasta 200 instantáneas por recurso compartido de archivos y conservarlas
durante un máximo de diez años. Puede realizar instantáneas manualmente en
Azure Portal, a través de PowerShell o en la interfaz de la línea de comandos (CLI), o
bien puede usar Azure Backup.
Azure Backup para recursos compartidos de archivos de Azure controla la programación

y retención de instantáneas. Sus capacidades de abuelo-padre-hijo (GFS) significan que
puede tomar instantáneas diarias, semanales, mensuales y anuales, cada una con su
propio período de retención distinto. Azure Backup también organiza la habilitación de
la eliminación temporal y toma un bloqueo de eliminación en una cuenta de
almacenamiento en cuanto se configura un recurso compartido de archivos en ella para
la copia de seguridad. Por último, Azure Backup proporciona ciertas capacidades clave
de supervisión y alertas que permiten a los clientes tener una vista consolidada de su
copia de seguridad.
Puede realizar restauraciones de nivel de elemento y de nivel de recurso compartido en

Azure Portal mediante Azure Backup. Lo único que debe hacer es elegir el punto de
restauración (una instantánea concreta), el archivo o directorio en cuestión si es
pertinente y, a continuación, la ubicación (original o alternativa) en la que quiere realizar
la restauración. El servicio de copia de seguridad controla la copia de los datos de
instantáneas y muestra el progreso de la restauración en el portal.
Protección de Azure Files con Microsoft Defender para

Storage
Microsoft Defender para Storage es una capa de inteligencia de seguridad nativa de
Azure que detecta posibles amenazas a sus cuentas de almacenamiento. Proporciona
una seguridad completa mediante el análisis de la telemetría del plano de datos y el
plano de control generados por Azure Files. Usa capacidades avanzadas de detección de
amenazas con tecnología de Inteligencia contra amenazas Microsoft para
proporcionar alertas de seguridad contextuales, incluidos los pasos para mitigar las
amenazas detectadas y evitar futuros ataques.
Defender para Storage analiza continuamente el flujo de telemetría generado por Azure
Files. Cuando se detectan actividades potencialmente malintencionadas, se generan
alertas de seguridad. Estas alertas se muestran en Microsoft Defender for Cloud junto
con los detalles de la actividad sospechosa, los pasos de investigación, las acciones de
corrección y las recomendaciones de seguridad.
Defender para Storage detecta malware conocido, como ransomware, virus, spyware y
otro malware cargado en una cuenta de almacenamiento basada en un hash de archivo
completo (solo se admite para la API de REST). Esto ayuda a evitar que el malware entre
en la organización y se propague a más usuarios y recursos. Consulte Descripción de las
diferencias entre el examen de malware y el análisis de reputación de hash.
Defender para Storage no tiene acceso a los datos de la cuenta de almacenamiento y no

afecta a su rendimiento. Puede habilitar Microsoft Defender para Storage en el nivel de
suscripción (recomendado) o de recursos.
Niveles de almacenamiento
Azure Files ofrece cuatro niveles diferentes de almacenamiento: Premium, Optimizado
para transacciones, Frecuente y Esporádico, con el fin de que pueda adaptar sus
recursos compartidos a los requisitos de rendimiento y precio de su escenario:
Premium: Los recursos compartidos de archivos Premium tienen el respaldo de

discos SSD y proporcionan alto rendimiento y baja latencia de forma consistente
en menos de 10 milisegundos en la mayoría de las operaciones de E/S para las
cargas de trabajo con mayor uso de E/S. Los recursos compartidos de archivos
Premium son adecuados para una amplia variedad de cargas de trabajo como
bases de datos, hospedaje de sitios web y entornos de desarrollo. Los recursos
compartidos de archivos Premium se pueden usar con los protocolos Bloque de
mensajes del servidor (SMB) y Network File System (NFS).
Optimizado para transacciones: Los recursos compartidos de archivos con el nivel
Optimizado para transacciones permiten cargas de trabajo con muchas
transacciones que no necesitan la latencia que ofrecen los recursos compartidos
de archivos Premium. Los recursos compartidos de archivos optimizados para
transacciones se ofrecen en el hardware de almacenamiento estándar respaldado
por unidades de disco duro (HDD). A los optimizados para transacciones se les ha
llamado históricamente "estándar"; sin embargo, realmente es el tipo de soporte
físico de almacenamiento, en lugar del propio nivel (tanto el acceso frecuente
como el esporádico también son niveles "estándar", ya que se encuentran en el
hardware de almacenamiento estándar).
Acceso frecuente: Los recursos compartidos de nivel de acceso frecuente ofrecen
almacenamiento optimizado para escenarios de uso compartido de archivos de
uso general, como los recursos compartidos de los equipos. Los recursos
compartidos de archivos de nivel de acceso frecuente se ofrecen en el hardware de
almacenamiento estándar respaldado por unidades de disco duro.
Acceso esporádico: Los recursos compartidos de archivos de acceso esporádico
ofrecen un almacenamiento económico optimizado para escenarios de
almacenamiento de archivo en línea. Los recursos compartidos de archivos de nivel
de acceso esporádico se ofrecen en el hardware de almacenamiento estándar
respaldado por unidades de disco duro.
Los recursos compartidos de archivos Premium se implementan en la cuenta de

almacenamiento de FileStorage y solo están disponibles en un modelo de facturación
aprovisionado. Para más información sobre el modelo de facturación aprovisionado
para recursos compartidos de archivos Premium, consulte Planeamiento de una
implementación de Azure Files. Los recursos compartidos de archivos estándar, que
incluyen los optimizados para las transacciones, los de nivel de acceso frecuente y los de
nivel de acceso esporádico, se implementan en la cuenta de almacenamiento de uso
general, versión 2 (GPv2) y están disponibles en un modelo de pago por uso.
Al seleccionar una capa de almacenamiento para la carga de trabajo, tenga en cuenta

los requisitos de rendimiento y uso. Si la carga de trabajo requiere una latencia de un
solo dígito o si usa medios de almacenamiento SSD en un entorno local, es probable
que el nivel Premium sea el más adecuado. Si no es muy importante que la latencia sea
baja, por ejemplo, en el caso de recursos compartidos de equipo montados localmente
desde Azure o almacenados en la caché local mediante Azure File Sync, desde el punto
de vista del costo es posible que sea más adecuado usar el almacenamiento estándar.
Una vez que se haya creado un recurso compartido de archivos en una cuenta de
almacenamiento, no se podrá mover a niveles exclusivos de diferentes tipos de cuenta
de almacenamiento. Por ejemplo, para cambiar un recurso compartido de archivos
optimizado para transacciones al nivel Premium, es preciso crear un recurso compartido
de archivos en una cuenta de almacenamiento de FileStorage y copiar los datos desde el
recurso compartido original a un nuevo recurso compartido de archivos en la cuenta de
FileStorage. Se recomienda usar AzCopy para copiar datos entre recursos compartidos
de archivos de Azure, pero también se pueden usar herramientas como robocopy en
Windows o rsync en macOS y Linux.
Para más información, consulte Facturación de Azure Files.
Limitaciones
Actualmente, los recursos compartidos de archivos estándar con recursos compartidos
de archivos grandes habilitados (hasta una capacidad de 100 TiB) tienen ciertas
limitaciones.
Solo se admiten cuentas de almacenamiento con redundancia local (LRS) y

almacenamiento con redundancia de zona (ZRS).
Una vez que habilite recursos compartidos de archivos grandes en una cuenta de
almacenamiento, no podrá convertir la cuenta de almacenamiento para usar ni el
almacenamiento con redundancia geográfica (GRS) ni el almacenamiento con
redundancia de zona geográfica (GZRS).
Una vez que habilite los recursos compartidos de archivos de gran tamaño, no
podrá deshabilitarlos.
Si desea usar GRS o GZRS con recursos compartidos de archivos de Azure SMB
estándar, consulte Redundancia geográfica de Azure Files para recursos compartidos de
archivos grandes (versión preliminar).
Redundancia
Para proteger los datos de los recursos compartidos de archivos de Azure contra la
pérdida o daños de los datos, Azure Files almacena varias copias de cada archivo a
medida que se escriben. En función de sus requisitos, podrá seleccionar diferentes
grados de redundancia. Actualmente, Azure Files admite las siguientes opciones de
redundancia de datos:
Almacenamiento con redundancia local (LRS) : con LRS, todos los archivos se
almacenan tres veces dentro de un clúster de almacenamiento de Azure. Esto
protege contra la pérdida de datos debido a errores de hardware, como una
unidad de disco incorrecta. No obstante, si se produjera un desastre, como un
incendio o una inundación en el centro de datos, es posible que todas las réplicas
de las cuentas de almacenamiento que usen LRS se pierdan o no se puedan
recuperar.
Almacenamiento con redundancia de zona (ZRS): con ZRS, se almacenan tres
copias de cada archivo. Sin embargo, estas copias están aisladas físicamente en
tres clústeres de almacenamiento distintos en diferentes zonas de disponibilidad de
Azure. Las zonas de disponibilidad son ubicaciones físicas exclusivas dentro de una
región de Azure. Cada zona consta de uno o varios centros de datos equipados
con alimentación, refrigeración y redes independientes. No se acepta la escritura
en el almacenamiento hasta que se realice la escritura en los clústeres de
almacenamiento en las tres zonas de disponibilidad.
Almacenamiento con redundancia geográfica (GRS): con GRS, hay dos regiones,
una primaria y una secundaria. Los archivos se almacenan tres veces dentro de un
clúster de almacenamiento de Azure en la región primaria. Las escrituras se
replican de forma asincrónica en una región secundaria definida por Microsoft.
GRS proporciona seis copias de los datos distribuidas entre dos regiones de Azure.
En caso de un desastre importante, como la pérdida permanente de una región de
Azure debido a una catástrofe natural o a otro evento similar, Microsoft realizará
una conmutación por error. En este caso, la base de datos secundaria se convertiría
en la principal, atendiendo todas las operaciones. Dado que la replicación entre las
regiones principal y secundaria es asincrónica, en caso de que se produzca un
desastre importante, se perderán los datos que todavía no se hayan replicado en la
región secundaria. También puede realizar una conmutación por error manual de
una cuenta de almacenamiento con redundancia geográfica.
Almacenamiento con redundancia de zona geográfica (GZRS): GZRS es como
ZRS, pero con redundancia geográfica. Con GZRS, los archivos se almacenan tres
veces en tres clústeres de almacenamiento distintos en la región primaria. Todas
las escrituras se replican de forma asincrónica en una región secundaria definida
por Microsoft. El proceso de conmutación por error de GZRS funciona igual que en
GRS.
Los recursos compartidos de archivos estándar de Azure de hasta 5 TiB admiten los
cuatro tipos de redundancia. Los recursos compartidos de archivos estándar de más
de 5 TiB solo admiten LRS y ZRS. Los recursos compartidos de archivos premium de
Azure solo admiten LRS y ZRS.
Las cuentas de almacenamiento de uso general versión 2 (GPv2) proporcionan otras dos
opciones de redundancia que Azure Files no admite: almacenamiento con redundancia
geográfica con acceso de lectura (RA-GRS) y almacenamiento con redundancia de zona
geográfica con acceso de lectura (RA-GZRS). Puede aprovisionar recursos compartidos
de archivos de Azure en cuentas de almacenamiento con estas opciones establecidas;
sin embargo, Azure Files no admite la lectura desde la región secundaria. Los recursos
compartidos de archivos de Azure implementados en cuentas de almacenamiento con
RA-GRS o RA-GZRS se facturan como GRS o GZRS, respectivamente.
Para obtener más información sobre la redundancia, consulte Redundancia de datos de

Azure Files.
Disponibilidad de ZRS estándar
ZRS para cuentas de almacenamiento estándar de uso general v2 está disponible para
un subconjunto de regiones de Azure.
Disponibilidad de ZRS premium

ZRS para recursos compartidos de archivos premium está disponible para un
subconjunto de regiones de Azure.
Disponibilidad de GZRS estándar

GZRS está disponible para un subconjunto de regiones de Azure.
Recuperación ante desastres y conmutación

por error
En el caso de una interrupción de servicio regional no planeada, debe tener un plan de
recuperación ante desastres (DR) para los recursos compartidos de archivos de Azure.
Para comprender los conceptos y los procesos implicados en la conmutación por error
de la cuenta de almacenamiento y recuperación ante desastres, consulte Recuperación
ante desastres y conmutación por error para Azure Files.
Migración
En muchos casos, no podrá establecer un nuevo recurso compartido de archivos para su
organización, sino que se migrará uno existente de un servidor de archivos local o un
dispositivo NAS a Azure Files. La elección de la herramienta y estrategia de migración
adecuadas para el escenario es importante para el éxito de la migración.
En el artículo de introducción a la migración se describen brevemente los aspectos

básicos y se incluye una tabla que le conduce a guías de migración que probablemente
cubran su escenario.
Pasos siguientes
Planeamiento de una implementación de Azure File Sync
Implementación de Azure Files
Implementación de Azure File Sync
Consulte el artículo de introducción a la migración para encontrar la guía de
migración para su escenario.
Recursos compartidos de archivos SMB
en Azure Files
Artículo • 29/09/2023
Azure Files ofrece dos protocolos estándar del sector para el montaje de recursos
compartidos de archivos de Azure: el protocolo Bloque de mensajes del servidor (SMB)
y el protocolo Network File System (NFS) . Azure Files le permite seleccionar el
protocolo del sistema de archivos más adecuado para su carga de trabajo. Los recursos
compartidos de archivos de Azure no admiten el acceso a un recurso compartido de
archivos de Azure individual con los protocolos SMB y NFS, aunque se pueden crear
recursos compartidos de archivos SMB y NFS dentro de la misma cuenta de
almacenamiento. En general, Azure Files ofrece recursos compartidos de archivos de
nivel empresarial que se pueden escalar verticalmente para satisfacer sus necesidades
de almacenamiento y a los que pueden acceder simultáneamente miles de clientes.
En este artículo se tratan los recursos compartidos de archivos SMB de Azure. Para
obtener información sobre los recursos compartidos de archivos NFS de Azure, consulte
el artículo sobre Recursos compartidos de archivos NFS en Azure Files.
Escenarios frecuentes
Los recursos compartidos de archivos SMB se usan para diversas aplicaciones, incluidos
recursos compartidos de archivos de usuario final y recursos compartidos de archivos
que respaldan las bases de datos y las aplicaciones. Los recursos compartidos de
archivos SMB se suelen usar en los escenarios siguientes:
Recursos compartidos de archivos de usuario final, como recursos compartidos de

equipo, directorios particulares, etc.
Almacenamiento auxiliar para aplicaciones basadas en Windows, como bases de
datos de SQL Server o aplicaciones de línea de negocio escritas para las API del
sistema de archivos local Win32 o .NET.
Desarrollo de aplicaciones y servicios nuevos, sobre todo si esa aplicación o
servicio tiene como requisito una E/S aleatoria y almacenamiento jerárquico.
Características
Azure Files admite las características principales de SMB y Azure que se requieren para
las implementaciones de producción de recursos compartidos de archivos SMB:
Listas de control de acceso discrecional (DACL) y unión a un dominio de AD.
Copia de seguridad sin servidor integrada con Azure Backup.
Aislamiento de red con puntos de conexión privados de Azure.
Alto rendimiento de red con SMB multicanal (solo recursos compartidos de
archivos premium).
Cifrado de canal SMB que incluye AES-256-GCM, AES-128-GCM y AES-128-CCM.
Compatibilidad con versiones anteriores mediante instantáneas de recurso
compartido integradas de VSS.
Eliminación temporal automática en los recursos compartidos de archivos de Azure
para evitar eliminaciones accidentales.
Opcionalmente, recursos compartidos de archivos accesibles desde Internet con
SMB 3.0 y versiones posteriores seguro para Internet.
Los recursos compartidos de archivos SMB pueden montarse directamente en el

entorno local o también se pueden almacenar en caché en el entorno local con
Azure File Sync.
Seguridad
De forma predeterminada, todas las cuentas de Azure Storage tienen habilitado el

cifrado en tránsito. Esto significa que, al montar un recurso compartido de archivos a
través de SMB (o acceder a él a través del protocolo FileREST), Azure Files solo permitirá
la conexión si se realiza con una versión SMB 3.x con cifrado o HTTPS. Los clientes que
no admiten SMB 3.x con cifrado del canal SMB no podrán montar el recurso compartido
de archivos de Azure si está habilitado el cifrado en tránsito.
Azure Files admite AES-256-GCM con SMB 3.1.1 cuando se usa con
Windows Server 2022 o Windows 11. SMB 3.1.1 también admite AES-128-GCM y
SMB 3.0 admite AES-128-CCM. AES-128-GCM se negocia de forma predeterminada en
Windows 10, versión 21H1, por motivos de rendimiento.
Puede deshabilitar el cifrado en tránsito para una cuenta de almacenamiento de Azure.

Cuando el cifrado está deshabilitado, Azure Files también permite el uso de SMB 2.1 y
SMB 3.x sin cifrado. La razón principal para deshabilitar el cifrado en tránsito es admitir
una aplicación heredada que debe ejecutarse en un sistema operativo anterior, como
Windows Server 2008 R2 o una distribución de Linux anterior. Azure Files solo permite
conexiones SMB 2.1 dentro de la misma región de Azure del recurso compartido de
archivos de Azure. Un cliente SMB 2.1 fuera de la región de Azure del recurso
compartido de archivos de Azure (por ejemplo, en un entorno local o en una región de
Azure diferente) no podrá acceder al recurso compartido de archivos.
Configuración del protocolo SMB

Azure Files ofrece varias configuraciones que afectan al comportamiento, rendimiento y
seguridad del protocolo SMB. Se configuran para todos los recursos compartidos de
archivos de Azure dentro de una cuenta de almacenamiento.
SMB multicanal
SMB multicanal permite que un cliente SMB 3.x establezca varias conexiones de red a un
recurso compartido de archivos SMB. Azure Files admite SMB multicanal en recursos
compartidos de archivos prémium (recursos compartidos de archivos en el tipo de
cuenta de almacenamiento FileStorage). No hay ningún costo adicional por habilitar
SMB multicanal en Azure Files. SMB multicanal está deshabilitado de forma
predeterminada.
Portal
Para ver el estado de SMB multicanal, vaya a la cuenta de almacenamiento que

contiene los recursos compartidos de archivos prémium y seleccione Recursos
compartidos de archivos en el encabezado Almacenamiento de datos de la tabla
de contenido de la cuenta de almacenamiento. El estado de SMB multicanal se
puede ver en la sección Configuración del recurso compartido de archivos.
Para habilitar o deshabilitar SMB multicanal, seleccione el estado actual (Habilitado
o Deshabilitado en función del estado). El cuadro de diálogo resultante
proporciona un botón de alternancia para habilitar o deshabilitar SMB multicanal.
Seleccione el estado deseado y seleccione Guardar.
Configuración de seguridad de SMB
Azure Files expone una configuración que le permite alternar el protocolo SMB para que
sea más compatible o más seguro, en función de los requisitos de la organización. De
manera predeterminada, Azure Files está configurado para ser compatible al máximo,
por lo que tenga en cuenta que restringir esta configuración puede hacer que algunos
clientes no puedan conectarse.
Azure Files expone la siguiente configuración:
Versiones de SMB: qué versiones de SMB se permiten. Las versiones admitidas del
protocolo son SMB 3.1.1, SMB 3.0 y SMB 2.1. De forma predeterminada, se
admiten todas las versiones de SMB, salvo en el caso de SMB 2.1 si está habilitada
la opción para requerir la transferencia segura, ya que SMB 2.1 no admite el
cifrado en tránsito.
Métodos de autenticación: qué métodos de autenticación SMB se permiten. Los
métodos de autenticación admitidos son NTLMv2 (solo clave de cuenta de
almacenamiento) y Kerberos. De forma predeterminada, se admiten todos los
métodos de autenticación. La eliminación de NTLMv2 impide el uso de la clave de
la cuenta de almacenamiento para montar el recurso compartido de archivos de
Azure. Azure Files no admite el uso de la autenticación NTLM para las credenciales
de dominio.
Cifrado de vales Kerberos: qué algoritmos de cifrado se permiten. Los algoritmos
de cifrado admitidos son AES-256 (recomendado) y RC4-HMAC.
Cifrado del canal SMB: qué algoritmos de cifrado del canal SMB se permiten. Los
algoritmos de cifrado admitidos son AES-256-GCM, AES-128-GCM y AES-128-
CCM.
Puede ver y cambiar la configuración de seguridad de SMB mediante Azure Portal,

PowerShell o la CLI. Seleccione la pestaña deseada para ver los pasos sobre cómo
obtener y establecer la configuración de seguridad de SMB.
Portal
Para ver o cambiar la configuración de seguridad de SMB mediante Azure Portal,

siga estos pasos:
1. Busque Cuentas de almacenamiento y seleccione la cuenta de

almacenamiento cuya configuración de seguridad quiere ver.
2. Seleccione Almacenamiento de datos>Recursos compartido de archivos.
3. En Configuración del recurso compartido de archivos, seleccione el valor

asociado a Seguridad. Si no ha modificado la configuración de seguridad,
tiene como valor predeterminado Compatibilidad máxima.
4. En Perfil, seleccione Compatibilidad máxima, Maximum security (Seguridad

máxima) o Personalizado. Si selecciona Personalizado, podrá crear un perfil
personalizado para las versiones del protocolo SMB, el cifrado de canales
SMB, los mecanismos de autenticación y el cifrado de vales de Kerberos.
Después de especificar la configuración de seguridad deseada, seleccione Guardar.
Limitaciones
Los recursos compartidos de archivos SMB en Azure Files admiten un subconjunto de
características compatibles con el protocolo SMB y el sistema de archivos NTFS. Aunque
la mayoría de los casos de uso y de las aplicaciones no requieren estas características, es
posible que algunas aplicaciones no funcionen correctamente con Azure Files si
dependen de características no admitidas. No se admiten las características siguientes:
SMB directo
Concesión de directorio SMB
VSS para recursos compartidos de archivos SMB (esto permite a los proveedores
de VSS vaciar sus datos en el recurso compartido de archivos SMB antes de tomar
una instantánea).
Flujos de datos alternativos
Atributos ampliados
Identificadores de objeto
Vínculos físicos
Enlaces simbólicos
Puntos de repetición de análisis
Archivos dispersos
Nombres de archivos cortos (alias 8.3)
Compresión
Disponibilidad regional
Los recursos compartidos de archivos SMB de Azure están disponibles en todas las
regiones de Azure, incluidas todas las públicas y soberanas. Los recursos compartidos
de archivos SMB premium están disponibles en un subconjunto de regiones .
Pasos siguientes
Montaje de recursos compartidos de archivos SMB en su sistema operativo
preferido:
Montaje de recursos compartidos de archivos SMB en Windows
Montaje de recursos compartidos de archivos SMB en Linux
Montaje de recursos compartidos de archivos SMB en macOS
Recursos compartidos de archivos NFS
en Azure Files
Artículo • 16/10/2023
Azure Files ofrece dos protocolos de sistema de archivos estándar del sector para
montar recursos compartidos de archivos de Azure: el protocolo Bloque de mensajes
del servidor (SMB) y el protocolo Network File System (NFS) , permitiéndole elegir el
protocolo que se ajuste más a su carga de trabajo. Los recursos compartidos de archivos
de Azure no admiten el acceso a un recurso compartido de archivos de Azure individual
con los protocolos SMB y NFS, aunque se pueden crear recursos compartidos de
archivos SMB y NFS dentro de la misma cuenta de almacenamiento de FileStorage.
Azure Files ofrece recursos compartidos de archivos de nivel empresarial que se pueden
escalar verticalmente para satisfacer sus necesidades de almacenamiento y a los que
pueden acceder simultáneamente miles de clientes.
En este artículo se describen los recursos compartidos de archivos NFS de Azure. Para
obtener información acerca de los recursos compartidos de archivos SMB de Azure,
consulte Recursos compartidos de archivos SMB en Azure Files.
） Importante
Los recursos compartidos de archivos NFS de Azure no se admiten para Windows.

Antes de usar recursos compartidos de archivos de NFS de Azure en producción,
consulte Solución de problemas de recursos compartidos de archivos de NFS de
Azure para ver una lista de problemas conocidos. No se admiten las listas de
control de acceso (ACL) de NFS.
Escenarios frecuentes
Los recursos compartidos de archivos NFS se suelen usar en los escenarios siguientes:
Almacenamiento de respaldo para aplicaciones basadas en Linux o UNIX, como

aplicaciones de línea de negocio escritas con API del sistema de archivos Linux o
POSIX (incluso aunque no requieran compatibilidad con POSIX).
Cargas de trabajo que requieren recursos compartidos de archivos compatibles
con POSIX, distinción entre mayúsculas y minúsculas o permisos de estilo Unix
(UID/GID).
Desarrollo de aplicaciones y servicios nuevos, sobre todo si esa aplicación o
servicio tiene como requisito una E/S aleatoria y almacenamiento jerárquico.
Características
Sistema de archivos totalmente compatible con POSIX.
Compatibilidad con vínculos físicos.
Compatibilidad con vínculos simbólicos.
Actualmente, los recursos compartidos de archivos NFS solo admiten la mayoría
de las características de la especificación del protocolo 4.1 . No se admiten
algunas características, como delegaciones y devoluciones de llamada de todo
tipo, listas de control de acceso, la autenticación Kerberos y el cifrado en tránsito.
７ Nota
Actualmente no se admite la creación de un vínculo físico a partir de un vínculo

simbólico existente.
Seguridad y redes
En el caso del cifrado en tránsito, Azure proporciona una capa de cifrado para todos los
datos en tránsito entre los centros de datos de Azure mediante MACSec . Gracias a
esto, se produce el cifrado cuando se transfieren datos entre centros de datos de Azure.
A diferencia de Azure Files cuando usa el protocolo SMB, los recursos compartidos de
archivos que utilizan el protocolo NFS no ofrecen autenticación basada en usuario. La
autenticación de los recursos compartidos NFS se basa en las reglas de seguridad de
red configuradas. Debido a esto, para garantizar que solo se establecen conexiones
seguras a su recurso compartido NFS, debe configurar un punto de conexión privado o
un punto de conexión de servicio para su cuenta de almacenamiento.
Un punto de conexión privado (también denominado vínculo privado) proporciona a la

cuenta de almacenamiento una dirección IP privada estática dentro de la red virtual, lo
que impide que las interrupciones de conectividad cambien de dirección IP dinámica. El
tráfico a la cuenta de almacenamiento se mantiene dentro de las redes virtuales
interconectadas, incluidas las de otras regiones y las locales. Se aplican las tarifas de
procesamiento de datos estándar.
Si no necesita una dirección IP estática, puede habilitar un punto de conexión de

servicio para Azure Files dentro de la red virtual. Un punto de conexión de servicio
configura las cuentas de almacenamiento para permitir el acceso solo desde subredes
específicas. Las subredes permitidas pueden pertenecer a una red virtual de la misma
suscripción o una suscripción diferente, incluidas las que pertenecen a un inquilino de
Microsoft Entra diferente. No se realiza ningún cargo adicional por el uso de puntos de
conexión de servicio.
Si desea acceder a recursos compartidos desde un entorno local, debe configurar una
VPN o ExpressRoute, además de un punto de conexión privado. Las solicitudes que no
tengan los siguientes orígenes se rechazarán:
Un punto de conexión privado

Azure VPN Gateway
Una VPN de punto a sitio (P2S)
De sitio a sitio
ExpressRoute
Un punto de conexión público restringido
Para más información sobre las opciones de red disponibles, consulte Consideraciones
de redes para Azure Files.
Compatibilidad con las características de

Azure Storage
En la tabla siguiente, se muestra el nivel actual de compatibilidad con características de
Azure Storage en las cuentas que tienen habilitada la característica NFS 4.1.
El estado de los elementos que aparecen en esta tabla puede cambiar con el tiempo a
medida que se siga ampliando la compatibilidad.
Característica de Azure Storage Compatible con recursos

compartidos NFS
API REST del plano de administración de archivos ✔️
API REST del plano de datos de archivos ⛔
Cifrado en reposo ✔️
Cifrado en tránsito ⛔
Característica de Azure Storage Compatible con recursos
compartidos NFS
Tipos de redundancia LRS o ZRS ✔️
Conversión de LRS a ZRS ⛔
Puntos de conexión de zona de Azure DNS (versión preliminar) ✔️
Puntos de conexión privados ✔️
Montajes de subdirectorios ✔️
Concesión de acceso de red a redes virtuales de Azure ✔️

específicas
Concesión de acceso a determinadas direcciones IP ⛔
Nivel Premium ✔️
Niveles estándar (nivel de acceso frecuente, nivel de acceso ⛔

esporádico y transacción optimizados)
Permisos POSIX ✔️
Uso de root_squash ✔️
Acceder a los mismos datos desde el cliente Windows y Linux ⛔
Habilitación basada en identidad ⛔
Eliminación temporal de recursos compartidos de archivos de ⛔

Azure
Azure File Sync ⛔
Copia de seguridad de un recurso compartido de archivos de ⛔

Azure
Instantáneas de recursos compartidos de archivos de Azure ✔️(versión preliminar)
Tipos de redundancia GRS o GZRS ⛔
AzCopy ⛔
Explorador de Azure Storage ⛔
Compatibilidad con más de 16 grupos ⛔
Los recursos compartidos de archivos NFS de Azure se admiten en las mismas regiones
que admiten el almacenamiento de archivos Prémium.
Para obtener la lista más actualizada, consulte la entrada Premium Files Storage en la
página Productos de Azure disponibles por región .
Rendimiento
Los recursos compartidos de archivos de Azure NFS solo se ofrecen en recursos
compartidos de archivos premium, que almacenan datos en unidades de estado sólido
(SSD). Las IOPS y el rendimiento de los recursos compartidos de NFS se escalan con la
capacidad aprovisionada. Consulte la sección del modelo aprovisionado del artículo
Descripción de la facturación para comprender las fórmulas de IOPS, ráfagas de E/S y
rendimiento. Las latencias de E/S promedio son de un número bajo de milisegundos
inferior a 10 para los tamaños de E/S pequeños, mientras que las latencias de metadatos
promedio son de un número alto de milisegundos inferior a 10. Las operaciones de
metadatos de carga elevada, como la descompresión y las cargas de trabajo como
WordPress, pueden tener latencias adicionales debido al gran número de operaciones
de apertura y cierre.
７ Nota
Puede usar la opción de montaje de Linux nconnect para mejorar el rendimiento de

los recursos compartidos de archivos de Azure NFS a escala. Para más información,
consulte Mejora del rendimiento del recurso compartido de archivos NFS de
Azure.
Cargas de trabajo
） Importante
Antes de usar recursos compartidos de archivos de NFS de Azure en producción,

consulte Solución de problemas de recursos compartidos de archivos de NFS de
Azure para ver una lista de problemas conocidos.
NFS se ha validado para funcionar bien con cargas de trabajo como el nivel de
aplicación de SAP, copias de seguridad de bases de datos, replicación de bases de
datos, colas de mensajería, directorios particulares para servidores de archivos de uso
general y repositorios de contenido para cargas de trabajo de aplicaciones.
Pasos siguientes
Creación de un recurso compartido de archivos NFS
Comparación del acceso a Azure Files, Blob Storage y Azure NetApp Files con NFS
Consideraciones de redes para Azure
Files
Artículo • 01/06/2023
Puede acceder a los recursos compartidos de archivos de Azure mediante el punto de

conexión público accesible desde Internet, mediante uno o varios puntos de conexión
privados en las redes o almacenando en caché el recurso compartido de archivos de
Azure en el entorno local con Azure File Sync (solo recursos compartidos de archivos
SMB). Este artículo se centra en cómo configurar Azure Files para el acceso directo
mediante puntos de conexión públicos o privados. Para obtener información sobre
cómo almacenar en caché el recurso compartido de archivos de Azure en el entorno
local con Azure File Sync, consulte ¿Qué es Azure File Sync?
Se recomienda leer Planeamiento de una implementación de Azure Files antes de pasar

a esta guía conceptual.
A menudo, el acceso directo al recurso compartido de archivos de Azure requiere una

reflexión adicional con respecto a las redes:
Los recursos compartidos de archivos SMB se comunican mediante el puerto 445,

que muchas organizaciones y proveedores de servicios de Internet (ISP) bloquean
para el tráfico saliente (Internet). Esta práctica procede de las instrucciones de
seguridad heredadas sobre las versiones en desuso y no seguras para Internet del
protocolo SMB. Aunque SMB 3.x es un protocolo seguro para Internet, es posible
que no se puedan cambiar las directivas de la organización o del ISP. Por lo tanto,
el montaje de un recurso compartido de archivos SMB a menudo requiere una
configuración de redes adicional para su uso fuera de Azure.
Los recursos compartidos de archivos NFS se basan en la autenticación de nivel de

red y, por tanto, solo son accesibles mediante redes restringidas. El uso de un
recurso compartido de archivos NFS siempre requiere algún nivel de configuración
de redes.
La configuración de puntos de conexión públicos y privados para Azure Files se realiza

en el objeto de administración de nivel superior de Azure Files, la cuenta de
almacenamiento de Azure. Una cuenta de almacenamiento es una construcción de
administración que representa un grupo compartido de almacenamiento en el que
puede implementar varios recursos compartidos de archivos de Azure, así como los
recursos de almacenamiento de otros servicios de almacenamiento de Azure, como
contenedores de blobs o colas.
How to replace an on-premises file server with Azure file shares
Este vídeo es una guía y demostración sobre cómo exponer de forma segura recursos
compartidos de archivos de Azure directamente para las aplicaciones y trabajadores de
la información en cinco sencillos pasos. En las secciones siguientes se proporcionan
vínculos y contexto adicional de la documentación a la que se hace referencia en el
vídeo.
Se aplica a
Transferencia segura
De manera predeterminada, las cuentas de almacenamiento de Azure requieren
transferencia segura, independientemente de si se accede a los datos mediante el punto
de conexión público o privado. Para Azure Files, se aplica la configuración requerir
transferencia segura para todo el acceso de protocolo a los datos almacenados en
recursos compartidos de archivos de Azure, incluidos SMB, NFS y FileREST. Puede
deshabilitar la configuración requerir transferencia segura para permitir el tráfico sin
cifrar. En Azure Portal, también puede ver esta configuración etiquetada como requerir
transferencia segura para las operaciones de la API de REST.
Los protocolos SMB, NFS y FileREST tienen un comportamiento ligeramente diferente
con respecto a la configuración requerir transferencia segura:
Cuando se habilita la configuración requerir transferencia segura en una cuenta

de almacenamiento, todos los recursos compartidos de archivos SMB de esa
cuenta de almacenamiento requerirán el protocolo SMB 3.x con los algoritmos de
cifrado AES-128-CCM, AES-128-GCM o AES-256-GCM, según la negociación de
cifrado disponible y requerido entre el cliente SMB y Azure Files. Puede alternar
qué algoritmos de cifrado SMB se permiten mediante la configuración de
seguridad de SMB. Al deshabilitar la configuración requerir transferencia segura,
se permiten los montajes SMB 2.1 y SMB 3.x sin cifrado.
Los recursos compartidos de archivos NFS no admiten un mecanismo de cifrado,

por lo que para poder usar el protocolo NFS para acceder a un recurso compartido
de archivos de Azure, debe deshabilitar la configuración requerir transferencia
segura para la cuenta de almacenamiento.
Cuando se requiere transferencia segura, el protocolo FileREST solo se puede usar

con HTTPS. Actualmente, FileREST solo se admite en recursos compartidos de
archivos SMB.
Punto de conexión público

El punto de conexión público de los recursos compartidos de archivos de Azure de una
cuenta de almacenamiento es un punto de conexión expuesto a Internet. El punto de
conexión público es el punto de conexión predeterminado para una cuenta de
almacenamiento; sin embargo, se puede deshabilitar si lo desea.
Los protocolos SMB, NFS y FileREST pueden usar el punto de conexión público. Sin
embargo, cada uno tiene reglas ligeramente diferentes para el acceso:
Los recursos compartidos de archivos SMB son accesibles desde cualquier lugar
del mundo mediante el punto de conexión público de la cuenta de
almacenamiento con SMB 3.x con cifrado. Esto significa que las solicitudes
autenticadas, como las solicitudes autorizadas por la identidad de inicio de sesión
de un usuario, se pueden originar de forma segura dentro o fuera de la región de
Azure. Si se desea usar SMB 2.1 o SMB 3.x sin cifrado, se deben cumplir dos
condiciones:
1. La configuración requerir transferencia segura de la cuenta de

almacenamiento debe estar deshabilitada.
2. La solicitud se debe originar desde dentro de la región de Azure. Como se
mencionó anteriormente, se permiten las solicitudes SMB cifradas desde
cualquier lugar, dentro o fuera de la región de Azure.
Los recursos compartidos de archivos NFS son accesibles desde el punto de

conexión público de la cuenta de almacenamiento si y solo si el punto de conexión
público de la cuenta de almacenamiento está restringido a redes virtuales
específicas mediante puntos de conexión de servicio. Consulte Configuración de
firewall del punto de conexión público para obtener información adicional sobre
los puntos de conexión de servicio.
FileREST es accesible mediante el punto de conexión público. Si se requiere

transferencia segura, solo se aceptan solicitudes HTTPS. Si la transferencia segura
está deshabilitada, el punto de conexión público acepta las solicitudes HTTP
independientemente del origen.
Configuración de firewall del punto de conexión público

El firewall de la cuenta de almacenamiento restringe el acceso al punto de conexión
público de una cuenta de almacenamiento. Con el firewall de la cuenta de
almacenamiento, puede restringir el acceso a determinadas direcciones IP o intervalos
de direcciones IP, a redes virtuales específicas o deshabilitar por completo el punto de
conexión público.
Al restringir el tráfico del punto de conexión público a una o varias redes virtuales, se
usa una funcionalidad de la red virtual llamada puntos de conexión de servicio. Las
solicitudes dirigidas al punto de conexión de servicio de Azure Files aún van a la
dirección IP pública de la cuenta de almacenamiento; sin embargo, la capa de redes
realiza una comprobación adicional de la solicitud para validar que proceda de una red
virtual autorizada. Los protocolos SMB, NFS y FileREST admiten puntos de conexión de
servicio. Sin embargo, a diferencia de SMB y FileREST, solo se puede acceder a los
recursos compartidos de archivos NFS con el punto de conexión público mediante el
uso de un punto de conexión de servicio.
Para más información sobre cómo configurar el firewall de la cuenta de

almacenamiento, consulte Configuración de los firewalls y las redes virtuales de Azure
Storage.
Enrutamiento de red del punto de conexión público

Azure Files admite varias opciones de enrutamiento de red. La opción predeterminada,
el enrutamiento de Microsoft, funciona con todas las configuraciones de Azure Files. La
opción de enrutamiento de Internet no admite escenarios de unión a un dominio de AD
ni Azure File Sync.
Puntos de conexión privados

Además del punto de conexión público predeterminado para una cuenta de
almacenamiento, Azure Files ofrece la opción de tener uno o más puntos de conexión
privados. Un punto de conexión privado es un punto de conexión que solo es accesible
dentro de una red virtual de Azure. Cuando se crea un punto de conexión privado para
la cuenta de almacenamiento, esta obtiene una dirección IP privada del espacio de
direcciones de la red virtual, de forma muy parecida a cómo un servidor de archivos
local o un dispositivo NAS reciben una dirección IP dentro del espacio de direcciones
dedicado de la red local.
Un punto de conexión privado está asociado a una subred de red virtual de Azure
específica. Una cuenta de almacenamiento puede tener puntos de conexión privados en
más de una red virtual.
El uso de puntos de conexión privados con Azure Files le permite:
Conectarse de forma segura a los recursos compartidos de archivos de Azure

desde redes locales mediante una conexión VPN o ExpressRoute con
emparejamiento privado.
Proteger los recursos compartidos de archivos mediante la configuración del
firewall de la cuenta de almacenamiento para bloquear todas las conexiones el
punto de conexión público. De forma predeterminada, crear un punto de conexión
privado no bloquea las conexiones al punto de conexión público.
Aumentar la seguridad de la red virtual, al permitirle bloquear la filtración de datos
desde la red virtual (y los límites de emparejamiento).
Para crear un punto de conexión privado, consulte Configuración de puntos de conexión

privados para Azure Files.
Tunelización del tráfico a través de una red privada virtual

o de ExpressRoute
Para usar puntos de conexión privados para acceder a recursos compartidos de archivos
SMB o NFS desde el entorno local, debe establecer un túnel de red entre la red local y
Azure. Una red virtual (o VNet) es similar a una red local tradicional. Al igual que una
cuenta de almacenamiento de Azure o una máquina virtual de Azure, una red virtual es
un recurso de Azure que se implementa en un grupo de recursos.
Azure Files admite los siguientes mecanismos para tunelizar el tráfico entre los
servidores y las estaciones de trabajo locales y los recursos compartidos de archivos de
SMB y NFS de Azure:
Una puerta de enlace de VPN es un tipo específico de puerta de enlace de red

virtual que se usa para enviar tráfico cifrado entre una red virtual de Azure y una
ubicación alternativa (por ejemplo, en un entorno local) a través de Internet. Una
instancia de Azure VPN Gateway es un recurso de Azure que se puede
implementar en un grupo de recursos junto con una cuenta de almacenamiento u
otros recursos de Azure. Las puertas de enlace de VPN exponen dos tipos de
conexión distintos:
Las conexiones de puerta de enlace de VPN de punto a sitio, que son
conexiones VPN entre Azure y un cliente individual. Esta solución es
principalmente útil para los dispositivos que no forman parte de la red local de
la organización. Un caso de uso común es el de los teletrabajadores que
quieren poder montar su recurso compartido de archivos de Azure desde su
casa, una cafetería o un hotel cuando están de viaje. Para usar una conexión
VPN de punto a sitio con Azure Files, debe configurar una conexión VPN de
punto a sitio para cada cliente que quiera conectarse. Para simplificar la
implementación de una conexión VPN P2S, consulte Configuración de una VPN
de punto a sitio (P2S) en Windows para su uso con Azure Files y Configuración
de una VPN de punto a sitio (P2S) en Linux para su uso con Azure Files.
Las VPN de sitio a sitio, que son conexiones VPN entre Azure y la red de su
organización. Una conexión VPN de sitio a sitio le permite configurar una
conexión VPN una vez para un servidor o dispositivo VPN hospedado en la red
de su organización, en lugar de configurar una conexión para cada dispositivo
cliente que necesite acceder al recurso compartido de archivos de Azure. Para
simplificar la implementación de una conexión VPN S2S, consulte Configuración
de una VPN de sitio a sitio (S2S) para su uso con Azure Files.
ExpressRoute, que permite crear una ruta definida entre Azure y la red local que no
atraviesa Internet. Como ExpressRoute proporciona una ruta de acceso dedicada
entre el centro de recursos local y Azure, ExpressRoute puede resultar útil cuando
se tiene en cuenta el rendimiento de la red. ExpressRoute también es una buena
opción cuando la directiva o los requisitos normativos de la organización requieren
una ruta de acceso determinista a los recursos en la nube.
７ Nota
Aunque se recomienda usar puntos de conexión privados para ayudar a extender la

red local a Azure, técnicamente es posible enrutar al punto de conexión público
mediante la conexión VPN. Sin embargo, esto requiere codificar de forma rígida la
dirección IP del punto de conexión público del clúster de almacenamiento de Azure
que atiende la cuenta de almacenamiento. Dado que las cuentas de
almacenamiento se pueden mover entre clústeres de almacenamiento en cualquier
momento y se agregan clústeres nuevos y se quitan con frecuencia, esto requiere
codificar de forma rígida y con regularidad todas las posibles direcciones IP de
almacenamiento de Azure en las reglas de enrutamiento.
Configuración de DNS
Cuando se crea un punto de conexión privado, de forma predeterminada también se
crea una zona DNS privada (o se actualiza una existente) correspondiente al subdominio
privatelink . En sentido estricto, no es necesario crear una zona DNS privada para usar
un punto de conexión privado para la cuenta de almacenamiento. Sin embargo, se
recomienda en general y se requiere de forma explícita al montar el recurso compartido
de archivos de Azure con una entidad de seguridad de usuario de Active Directory o al
acceder a él desde la API de FileREST.
７ Nota
En este artículo se usa el sufijo DNS de la cuenta de almacenamiento para las

regiones públicas de Azure core.windows.net . Este comentario también se aplica a
las nubes soberanas de Azure, como la nube de Azure US Government y la nube de
Azure China; simplemente sustituya los sufijos adecuados para su entorno.
En la zona DNS privada, se va a crea un registro D para

storageaccount.privatelink.file.core.windows.net y un registro CNAME para el
nombre normal de la cuenta de almacenamiento, que sigue el patrón

storageaccount.file.core.windows.net . Dado que la zona DNS privada de Azure está
conectada a la red virtual que contiene el punto de conexión privado, puede observar la
configuración de DNS cuando mediante una llamada al cmdlet Resolve-DnsName desde
PowerShell en una máquina virtual de Azure (como alternativa, nslookup en Windows y
Linux):
PowerShell
Resolve-DnsName -Name "storageaccount.file.core.windows.net"
En este ejemplo, la cuenta de almacenamiento storageaccount.file.core.windows.net

se resuelve en la dirección IP privada del punto de conexión privado, que resulta ser
192.168.0.4 .
Output
Name Type TTL Section NameHost

---- ---- --- ------- --------
storageaccount.file.core.windows. CNAME 29 Answer
csostoracct.privatelink.file.core.windows.net
net
Name : storageaccount.privatelink.file.core.windows.net
QueryType : A
TTL : 1769
Section : Answer
IP4Address : 192.168.0.4
Name : privatelink.file.core.windows.net
QueryType : SOA
TTL : 269
Section : Authority
NameAdministrator : azureprivatedns-host.microsoft.com
SerialNumber : 1
TimeToZoneRefresh : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration : 2419200
DefaultTTL : 300
Si ejecuta el mismo comando en el entorno local, verá que el mismo nombre de cuenta
de almacenamiento se resuelve en la dirección IP pública de la cuenta de
almacenamiento; storageaccount.file.core.windows.net es un registro CNAME para
storageaccount.privatelink.file.core.windows.net , que, a su vez, es un registro
CNAME para el clúster de almacenamiento de Azure que hospeda la cuenta de

almacenamiento:
Output

---- ---- --- ------- --------
storageaccount.privatelink.file.core.windows.net
net
storageaccount.privatelink.file.c CNAME 60 Answer
file.par20prdstr01a.store.core.windows.net
ore.windows.net
Name : file.par20prdstr01a.store.core.windows.net
QueryType : A
TTL : 60
Section : Answer
IP4Address : 52.239.194.40
Esto refleja el hecho de que la cuenta de almacenamiento puede exponer el punto de

conexión público y uno o varios puntos de conexión privados. Para asegurarse de que el
nombre de la cuenta de almacenamiento se resuelve en la dirección IP privada del
punto de conexión privado, debe cambiar la configuración en los servidores DNS
locales. Esto puede realizarse de varias maneras:
Modifique el archivo hosts de los clientes para que

storageaccount.file.core.windows.net se resuelva en la dirección IP privada del
punto de conexión privado deseado. Este método no se recomienda en entornos
de producción, ya que estos cambios se deberán realizar en todos los clientes que
quieran montar los recursos compartidos de archivos de Azure y los cambios en la
cuenta de almacenamiento o en el punto de conexión privado no se administrarán
automáticamente.
Cree un registro D para storageaccount.file.core.windows.net en los servidores
DNS locales. Este método tiene la ventaja de que los clientes de su entorno local
podrán resolver automáticamente la cuenta de almacenamiento sin necesidad de
configurar cada cliente. Sin embargo, esta solución es igual de frágil que modificar
el archivo hosts, ya que no se reflejan los cambios. Aunque esta solución es frágil,
puede ser la mejor opción para algunos entornos.
Reenvíe la zona core.windows.net de los servidores DNS locales a la zona DNS
privada de Azure. Se puede acceder al host DNS privado de Azure a través de una
dirección IP especial ( 168.63.129.16 ) que solo es accesible dentro de las redes
virtuales que están vinculadas a la zona DNS privada de Azure. Para solucionar esta
limitación, puede ejecutar servidores DNS adicionales dentro de la red virtual que
reenviarán core.windows.net a la zona DNS privada de Azure. Para simplificar esta
configuración, se han proporcionado cmdlets de PowerShell que implementarán
automáticamente los servidores DNS en la red virtual de Azure y los configurarán
según sea necesario. Para aprender a configurar el reenvío de DNS, consulte
Configuración de DNS con Azure Files.
SMB a través de QUIC

Windows Server 2022 Azure Edition admite un nuevo protocolo de transporte llamado
QUIC para el servidor SMB proporcionado por el rol Servidor de archivos. QUIC es una
sustitución de TCP que se basa en UDP, lo que proporciona numerosas ventajas sobre
TCP, a la vez que proporciona un mecanismo de transporte confiable. Una de las
principales ventajas para el protocolo SMB es que, en lugar de usar el puerto 445, todo
el transporte se lleva a cabo mediante el puerto 443, que está generalmente abierto
para admitir HTTPS. Esto significa de forma efectiva que SMB mediante QUIC ofrece una
"VPN de SMB" para el uso compartido de archivos mediante la red pública de Internet.
Windows 11 se suministra con un cliente compatible con SMB mediante QUIC.
En este momento, Azure Files no admite directamente SMB mediante QUIC. Sin
embargo, puede obtener acceso a recursos compartidos de archivos de Azure a través
de Azure File Sync que se ejecutan en Windows Server, como se muestra en el diagrama
siguiente. Esto también le ofrece la opción de tener memorias caché de Azure File Sync
tanto locales como en diferentes centros de datos de Azure para proporcionar cachés
locales para un personal distribuido. Para más información sobre esta opción, consulte
Implementación de Azure File Sync y SMB a través de QUIC.
Consulte también
Introducción a la protección de datos de
Azure Files
Artículo • 26/07/2023
Azure Files proporciona muchas herramientas para proteger los datos, incluida la
eliminación temporal, las instantáneas de recursos compartidos, Azure Backup y Azure
File Sync. En este artículo se describe cómo proteger los datos en Azure Files y los
conceptos y procesos implicados en la copia de seguridad y recuperación de recursos
How Azure Files can help protect against ransomware and acciden…
acciden…
Consulte este vídeo para ver cómo la protección de datos avanzada de Azure Files
protege a las empresas contra el ransomware y la pérdida accidental de datos, a la vez
que ofrece una mayor continuidad empresarial.
Por qué debe proteger los datos

En el caso de Azure Files, la protección de datos hace referencia a la protección de la
cuenta de almacenamiento, los recursos compartidos de archivos y los datos que
contienen contra la eliminación o modificación. Con la protección de datos, también es
posible restaurar los datos después de eliminarlos o modificarlos.
Hay varias razones por las que debe proteger los datos del recurso compartido de
archivos.
Recuperación de la pérdida accidental de datos: Recupere los datos que se

eliminen o dañen accidentalmente.
Escenarios de actualización: Restaure a un estado correcto conocido después de
un intento de actualización erróneo.
Protección contra ransomware: Recupere datos sin pagar rescate a
ciberdelincuentes.
Retención a largo plazo: Cumpla con los requisitos de retención de datos.
Continuidad empresarial: Prepare la infraestructura para que sea de alta
disponibilidad para cargas de trabajo críticas.
Copia de seguridad y restauración de recursos

compartidos de archivos de Azure
Puede configurar Azure Backup para realizar copias de seguridad de los recursos
compartidos de archivos mediante Azure Portal, Azure PowerShell, la CLI de Azure o la
API de REST. También puede usar Azure File Sync para realizar copias de seguridad de
los datos del servidor de archivos locales en un recurso compartido de archivos de
Azure.
Azure Portal
Para obtener información sobre cómo realizar copias de seguridad y restaurar

recursos compartidos de archivos de Azure mediante Azure Portal, consulte los
siguientes artículos:
Copia de seguridad de recursos compartidos de archivos de Azure

Restauración de recursos compartidos de archivos de Azure
Administración de copias de seguridad de recursos compartidos de archivos
de Azure
Redundancia de datos
Azure Files ofrece varias opciones de redundancia, incluida la redundancia geográfica,
para ayudar a proteger los datos frente a interrupciones del servicio debido a problemas
de hardware o desastres naturales. Para averiguar qué opción es mejor para su caso de
uso, consulte Redundancia de datos de Azure Files.
） Importante
Azure Files solo admite redundancia geográfica (GRS o GZRS) para los recursos
compartidos de archivos con SMB estándar. Los recursos compartidos de archivos
Premium y los recursos compartidos de archivos NFS deben usar almacenamiento
con redundancia local (LRS) o almacenamiento con redundancia de zona (ZRS).
Recuperación ante desastres y conmutación

por error
En el caso de un desastre o una interrupción no planeada, la restauración del acceso a
los datos del recurso compartido de archivos suele ser fundamental para mantener
operativa la empresa. En función de la importancia de los datos hospedados en los
recursos compartidos de archivos, es posible que necesite una estrategia de
recuperación ante desastres que incluya errores en los recursos compartidos de archivos
de Azure en una región secundaria.
Azure Files ofrece conmutación por error administrada por el cliente para cuentas de
almacenamiento estándar si el centro de datos de la región primaria deja de estar
disponible. Consulte Recuperación ante desastres y conmutación por error para obtener
Azure Files.
Evitar la eliminación accidental de cuentas de

almacenamiento y recursos compartidos de
archivos
La pérdida de datos no siempre se produce debido a un desastre. Más a menudo, es el
resultado de un error humano. Azure proporciona herramientas para evitar la
eliminación accidental de cuentas de almacenamiento y recursos compartidos de
archivos.
Bloqueos de cuenta de almacenamiento

Los bloqueos de cuenta de almacenamiento permiten a los administradores bloquear la
cuenta de almacenamiento para evitar que los usuarios eliminen accidentalmente la
cuenta de almacenamiento. Existen dos tipos de bloqueos de cuentas de
almacenamiento:
Un bloqueo CannotDelete impide que los usuarios eliminen una cuenta de

almacenamiento, pero permite modificar su configuración.
Un bloqueo ReadOnly impide que los usuarios eliminen una cuenta de
almacenamiento o modifiquen su configuración.
Para más información, consulte Aplicación de un bloqueo de Azure Resource Manager a
una cuenta de almacenamiento.
Eliminación temporal
La eliminación temporal funciona en un nivel de recurso compartido de archivos para
proteger los recursos compartidos de archivos de Azure frente a la eliminación
accidental. Si se elimina un recurso compartido con eliminación temporal habilitada,
este pasa a un estado de eliminación temporal internamente y se puede recuperar hasta
que expire el período de retención. Los recursos compartidos de archivos de Azure se
siguen facturando en la capacidad usada cuando se eliminan temporalmente.
Para más información, consulte Habilitación de la eliminación temporal en recursos

compartidos de archivos de Azure y Prevención de la eliminación accidental de recursos
Instantáneas de recursos compartido

Las instantáneas de recurso compartido de archivos son copias a un momento dado del
recurso compartido de archivos de Azure que puede realizar manual o automáticamente
a través de Azure Backup. Después, puede restaurar archivos individuales a partir de
estas instantáneas. Puede tomar hasta 200 instantáneas por recurso compartido de
archivos.
Las instantáneas son incrementales por naturaleza, por lo que capturan solo los cambios
desde la última instantánea. Eso significa que son eficientes en cuanto a costo y espacio.
Se le factura el uso diferencial del almacenamiento de cada instantánea, por lo que
resulta práctico tener varios puntos de recuperación para satisfacer los requisitos de
RPO bajos.
Para obtener más información, consulte Información general de las instantáneas de

recurso compartido de Azure Files.
Uso de Azure File Sync para copias de

seguridad en la nube híbrida
El uso de Azure File Sync con Azure Backup es una solución sencilla para las copias de
seguridad en la nube híbridas desde el entorno local a la nube. Azure File Sync mantiene
los archivos sincronizados y centralizados.
Este método simplifica la recuperación ante desastres y proporciona varias opciones.
Puede recuperar archivos o directorios únicos, o realizar una restauración rápida de
todo el recurso compartido de archivos. Solo tiene que abrir un nuevo servidor en el
servidor principal y apuntarlo al recurso compartido de archivos de Azure centralizado
donde puede acceder a los datos. Con el tiempo, los archivos se almacenarán en caché
localmente o se almacenarán en capas en la nube en función de la configuración de
Azure File Sync.
Consulte también
Redundancia de Azure Files
Recuperación ante desastres y conmutación por error de Azure Files
Redundancia de datos de Azure Files
Artículo • 28/06/2023
Azure Files siempre almacena varias copias de los datos, con el fin de protegerlos de
eventos planeados y no planeados, como errores transitorios de hardware,
interrupciones del suministro eléctrico o cortes de la red, y desastres naturales. La
redundancia garantiza que la cuenta de almacenamiento cumple sus objetivos de
disponibilidad y durabilidad, aunque se produzcan errores.
A la hora de decidir qué opción de redundancia es la más adecuada para su escenario,

intente buscar un equilibrio entre bajo costo y alta disponibilidad. Entre los factores que
ayudan a determinar qué opción de redundancia debe elegir se incluye:
Cómo se replican los datos en la región primaria.

Si los datos se replican en una región secundaria que está alejada geográficamente
de la región primaria, para protección frente a desastres regionales (redundancia
geográfica).
Los recursos compartidos de archivos de Azure se administran a través de un recurso

común de Azure denominado cuenta de almacenamiento. La cuenta de almacenamiento
representa un grupo compartido de almacenamiento que se puede usar para
implementar recursos compartidos de archivos. Para más información sobre las cuentas
de almacenamiento, consulte Introducción a las cuentas de Storage.
Al crear una cuenta de almacenamiento, debe elegir una configuración de redundancia

para la cuenta de almacenamiento que se comparte con todos los servicios de
almacenamiento expuestos por esa cuenta. Todos los recursos compartidos de archivos
implementados en la misma cuenta de almacenamiento tienen la misma configuración
de redundancia. Se recomienda aislar los recursos compartidos de archivos en
diferentes cuentas de almacenamiento si no tienen los mismos requisitos de
redundancia.
Redundancia en la región primaria

Los datos de una cuenta de Azure Storage siempre se replican tres veces en la región
primaria. Azure Files ofrece dos métodos para replicar los datos en la región primaria:
El almacenamiento con redundancia local (LRS) copia los datos de forma

sincrónica tres veces dentro de una única ubicación física en la región primaria.
LRS es la opción de replicación menos costosa, pero no se recomienda para las
aplicaciones que requieren de alta disponibilidad o durabilidad.
El almacenamiento con redundancia de zona (ZRS) copia los datos de forma
sincrónica en tres zonas de disponibilidad de Azure en la región primaria. En el
caso de las aplicaciones que requieren de alta disponibilidad, le recomendamos
usar ZRS en la región primaria y también replicación en una región secundaria.
Almacenamiento con redundancia local

El almacenamiento con redundancia local (LRS) replica la cuenta de almacenamiento
tres veces dentro de un único centro de datos en la región primaria. LRS ofrece una
durabilidad mínima del 99,999999999 % (11 nueves) en un año determinado.
LRS es la opción de redundancia de costo más bajo y ofrece la menor durabilidad en

comparación con otras opciones. LRS protege los datos frente a errores en la estantería
de servidores y en la unidad. No obstante, si se produce un desastre como un incendio
o una inundación en el centro de datos, es posible que todas las réplicas de una cuenta
de almacenamiento con LRS se pierdan o no se puedan recuperar. Para mitigar este
riesgo, le recomendamos usar almacenamiento con redundancia de zona (ZRS), el
almacenamiento con redundancia geográfica (GRS) o el almacenamiento con
redundancia de zona geográfica (GZRS).
Las solicitudes de escritura a una cuenta de almacenamiento que usa LRS se producen
de forma sincrónica. Las operaciones de escritura se devuelven correctamente solo
después de que los datos se escriben en las tres réplicas.
En el diagrama siguiente se muestra cómo se replican los datos en un único centro de

datos con LRS:
LRS es una buena opción para los siguientes escenarios:

Si la aplicación almacena datos que se pueden reconstruir fácilmente en caso de
que se produzca una pérdida de datos.
Si la aplicación está restringida a la replicación de datos en un país o una región
debido a requisitos de gobernanza de datos. En algunos casos, las regiones
emparejadas en las que los datos se replican geográficamente pueden estar en
otro país o región. Para más información sobre las regiones emparejadas, consulte
Regiones de Azure .
Almacenamiento con redundancia de zona

El almacenamiento con redundancia de zona (ZRS) replica la cuenta de almacenamiento
de forma sincrónica en tres zonas de disponibilidad de Azure en la región primaria.
Cada zona de disponibilidad es una ubicación física individual con alimentación,
refrigeración y redes independientes. ZRS proporciona una durabilidad mínima del
99,9999999999 % (12 nueves) en un año determinado.
Con ZRS, los datos son accesibles para las operaciones de escritura y lectura incluso si
una zona deja de estar disponible. Si alguna zona deja de estar disponible, Azure realiza
las actualizaciones de la red, como el redireccionamiento de DNS. Estas actualizaciones
pueden afectar a la aplicación si se accede a los datos antes de que se completen dichas
actualizaciones. Al diseñar aplicaciones para ZRS, siga los procedimientos para el control
de errores transitorios, incluida la implementación de directivas de reintentos con
retroceso exponencial.
Las solicitudes de escritura a una cuenta de almacenamiento que usa ZRS se producen
de forma sincrónica. Las operaciones de escritura se devuelven correctamente solo
después de que los datos se escriben en todas las réplicas de las tres zonas de
disponibilidad.
Una ventaja de usar ZRS para cargas de trabajo de Azure Files es que si una zona deja
de estar disponible, no es necesario volver a montar los recursos compartidos de
archivos de Azure de los clientes conectados. Le recomendamos usar ZRS en la región
primaria para escenarios que requieren de alta disponibilidad y bajo RPO/RTO. También
recomendamos ZRS para restringir la replicación de datos a un país o región en
particular a fin de cumplir los requisitos de gobernanza de datos.
７ Nota
Azure File Sync tiene redundancia de zona en todas las regiones que admiten
zonas, excepto US Gov Virginia. En la mayoría de los casos, se recomienda que los
usuarios de Azure File Sync configuren las cuentas de almacenamiento para usar
ZRS o GZRS.
En el diagrama siguiente se muestra cómo los datos se replican en las zonas de
disponibilidad de la región primaria con ZRS:
ZRS ofrece un rendimiento excelente, una latencia baja y resistencia para los datos si
dicha región deja de estar disponible temporalmente. No obstante, ZRS por sí sola
podría no proteger los datos frente a un desastre regional en el que varias zonas
resulten afectadas permanentemente. Para la protección frente a desastres regionales,le
recomendamos usar almacenamiento con redundancia de zona geográfica (GZRS), que
usa ZRS en la región primaria y también replica geográficamente los datos en una
región secundaria.
Para obtener más información sobre qué regiones admiten ZRS, consulte Servicio de
zona de disponibilidad y compatibilidad regional.
Cuentas de almacenamiento estándar
ZRS se admite en cuentas de almacenamiento estándar de uso general v2 para los tres
niveles estándar: optimizado para transacciones, frecuente y esporádico.
Para obtener una lista de regiones que admiten ZRS para cuentas de almacenamiento
estándar, consulte Regiones de Azure que admiten almacenamiento con redundancia de
zona (ZRS) para cuentas de almacenamiento estándar.
Cuentas de recursos compartidos de archivos premium

ZRS se admite para recursos compartidos de archivos con el tipo de cuenta de
almacenamiento FileStorage .
Para obtener una lista de las regiones que admiten ZRS para las cuentas de recursos
compartidos de archivos premium, consulte Almacenamiento con redundancia de zona
de Azure Files para recursos compartidos premium.
Redundancia en una región secundaria

En el caso de las aplicaciones que requieren de alta durabilidad para los recursos
compartidos de archivos con SMB, puede elegir el almacenamiento con redundancia
geográfica para copiar los datos de la cuenta de almacenamiento en una región
secundaria que esté a cientos de kilómetros de distancia de la región primaria. Si la
cuenta de almacenamiento se copia a una región secundaria, sus datos se mantienen
incluso ante un apagón regional completo o un desastre del cual la región primaria no
se puede recuperar.
） Importante
Azure Files solo admite redundancia geográfica (GRS o GZRS) para los recursos
compartidos de archivos con SMB estándar. Los recursos compartidos de archivos
premium y los recursos compartidos de archivos NFS deben usar LRS o ZRS.
Al crear una cuenta de almacenamiento, seleccione la región principal de la cuenta. La

región secundaria emparejada se determina según la región primaria y no es posible
cambiarla. Para obtener más información sobre las regiones compatibles con Azure,
consulte Regiones de Azure .
Azure Files ofrece dos opciones para copiar los datos a una región secundaria.
Actualmente, las opciones de almacenamiento con redundancia geográfica solo están
disponibles para recursos compartidos de archivos SMB estándar que no tienen
habilitada la configuración de recursos compartidos de archivos grandes en la cuenta
de almacenamiento (hasta 5 TiB), a menos que use Redundancia geográfica de
Azure Files para recursos compartidos de archivos grandes (versión preliminar).
El almacenamiento con redundancia geográfica (GRS) copia los datos de forma
sincrónica tres veces dentro de una única ubicación física en la región primaria
mediante LRS. Luego copia los datos de forma asincrónica en una única ubicación
física en la región secundaria. Dentro de la región secundaria, los datos siempre se
replican de forma sincrónica tres veces mediante LRS.
El almacenamiento con redundancia de zona geográfica (GZRS) copia los datos
de forma sincrónica en tres zonas de disponibilidad de Azure en la región primaria
mediante ZRS. Luego copia los datos de forma asincrónica en una única ubicación
física en la región secundaria. Dentro de la región secundaria, los datos se copian
de forma sincrónica tres veces mediante LRS.
La principal diferencia entre GRS y GZRS es la forma en que los datos se replican en la
región primaria. Dentro de la región secundaria, los datos siempre se replican de forma
sincrónica tres veces mediante LRS. LRS en la región secundaria protege los datos frente
a errores de hardware.
Almacenamiento con redundancia geográfica

sincrónica tres veces dentro de una única ubicación física en la región primaria mediante
LRS. Después, copia los datos de forma asincrónica en una única ubicación física de una
región secundaria que se encuentra a cientos de miles de kilómetros de distancia de la
región primaria. GRS proporciona una durabilidad mínima del 99.99999999999999 %
(16 nueves) en un año determinado.
Una operación se escritura se confirma primero en la ubicación principal y se replica

mediante LRS. Después, la actualización se replica de manera asincrónica en la región
secundaria. Cuando los datos se escriben en la ubicación secundaria, también se
replican dentro de esa ubicación con LRS.
En el diagrama siguiente, se muestra cómo se replican los datos con GRS:

Almacenamiento con redundancia de zona geográfica
El almacenamiento con redundancia de zona geográfica (GZRS) combina la alta
disponibilidad que proporciona la redundancia entre zonas de disponibilidad con la
protección frente a interrupciones regionales que proporciona la replicación geográfica.
Los datos de una cuenta de almacenamiento de GZRS se almacenan en tres zonas de
disponibilidad de Azure en la región primaria y también se replican en una región
geográfica secundaria para protegerlos frente a desastres regionales. Le recomendamos
el uso de GZRS en aplicaciones que requieran de coherencia, durabilidad y
disponibilidad máximas, además de un excelente rendimiento y resistencia para la
recuperación ante desastres.
Con una cuenta de almacenamiento de GZRS, puede seguir leyendo y escribiendo datos
si una zona de disponibilidad deja de estar disponible o es irrecuperable. Además, los
datos se mantienen en caso de un apagón completo de una región o de un desastre
tras el que la región primaria no se puede recuperar. GZRS está diseñada para
proporcionar una durabilidad mínima del 99,99999999999999 % (16 nueves) en un año
determinado.
En el diagrama siguiente, se muestra cómo se replican los datos con GZRS:
Solo las cuentas de almacenamiento estándares de uso general v2 son compatibles con
GZRS.
Para obtener una lista de regiones que admiten GZRS, consulte Regiones de Azure que
admiten el almacenamiento con redundancia de zona geográfica (GZRS).
Recuperación ante desastres y conmutación por error
Con GRS o GZRS, los recursos compartidos de archivos no serán accesibles en la región
secundaria a menos que se produzca una conmutación por error. Si la región primaria
deja de estar disponible, puede conmutar por error a la región secundaria. El proceso de
conmutación por error actualiza la entrada DNS que proporciona Azure Files, de modo
tal que el punto de conexión secundario se convierte en el nuevo punto de conexión
principal de la cuenta de almacenamiento. Durante el proceso de conmutación por
error, los datos no son accesibles. Una vez completada la conmutación por error, puede
leer y escribir datos en la nueva región primaria. Una vez completada la conmutación
por error, la región secundaria se convierte en la región primaria y se pueden leer y
escribir datos de nuevo. Para más información, consulte Recuperación ante desastres y
conmutación por error de Azure Files.
） Importante
Azure Files no admite el almacenamiento con redundancia geográfica con acceso

de lectura (RA-GRS) ni el almacenamiento con redundancia de zona geográfica con
acceso de lectura (RA-GZRS). Si una cuenta de almacenamiento está configurada
para usar RA-GRS o RA-GZRS, los recursos compartidos de archivos se configurarán
y facturarán como GRS o GZRS.
Redundancia geográfica para recursos compartidos de

archivos premium
Como se mencionó anteriormente, las opciones de redundancia geográfica (GRS y
GZRS) no se admiten para recursos compartidos de archivos premium. Sin embargo,
puede obtener redundancia geográfica de otras maneras.
En los escenarios de Azure File Sync, puede sincronizar entre el recurso compartido de
archivos de Azure (el punto de conexión de nube), un servidor de archivos de Windows
local y un recurso compartido de archivos montado que se ejecuta en una máquina
virtual de otra región de Azure (el punto de conexión del servidor con fines de
recuperación ante desastres). Debe deshabilitar la nube por niveles para asegurarse de
que todos los datos están presentes localmente y aprovisionar suficiente
almacenamiento en la máquina virtual de Azure para contener todo el conjunto de
datos. Para asegurarse de que los cambios se replicarán rápidamente en la región
secundaria, solo se debe acceder a los archivos y modificarlos en el punto de conexión
del servidor en lugar de en Azure.
También puede crear su propio script para copiar datos en una cuenta de
almacenamiento de una región secundaria mediante herramientas como AzCopy (usar
la versión 10.4 o posterior para conservar las ACL y las marcas de tiempo).
Resumen de las opciones de redundancia

Las tablas de las siguientes secciones resumen las opciones de redundancia disponibles
para Azure Files.
Parámetros de durabilidad y disponibilidad

En la tabla siguiente se describen los parámetros clave de cada opción de redundancia:
Parámetro LRS ZRS GRS GZRS
Porcentaje de al menos al menos Como mínimo Como mínimo

durabilidad en 99,999999999 % 99,9999999999 % 99,99999999999999 % 99,99999999999999 %
un año (once nueves) (doce nueves) (dieciséis nueves) (dieciséis nueves)
determinado
Disponibilidad Al menos un Al menos un Al menos un 99,9 % Al menos un 99,9 %

de las 99,9 % (99 % 99,9 % (99 % (99 % para el nivel (99 % para el nivel
solicitudes de para el nivel para el nivel esporádico) esporádico)
lectura esporádico) esporádico)
Disponibilidad Al menos un Al menos un Al menos un 99,9 % Al menos un 99,9 %

de las 99,9 % (99 % 99,9 % (99 % (99 % para el nivel (99 % para el nivel
solicitudes de para el nivel para el nivel esporádico) esporádico)
escritura esporádico) esporádico)
Número de Tres copias Tres copias en Seis copias en total, Seis copias en total,
copias de dentro de una zonas de tres en la región tres en zonas de
datos única región disponibilidad primaria y tres en la disponibilidad
mantenidas en independientes región secundaria independientes en la
nodos dentro de una región primaria y tres
independientes única región copias con
redundancia local en
la región secundaria
Para más información, consulte el Acuerdo de Nivel de Servicio para cuentas de

Storage .
Durabilidad y disponibilidad por escenario de

interrupción
En la tabla siguiente, se indica si los datos son duraderos y están disponibles en un
escenario determinado, según el tipo de redundancia vigente para la cuenta de
almacenamiento. Azure Files no admite el acceso de lectura a la región secundaria si la
región primaria deja de estar disponible, a menos que se produzca una conmutación
por error.
Escenario de interrupción LRS ZRS GRS GZRS
Un nodo de un centro de datos deja de estar disponible Sí Sí Sí Sí
Un centro de datos completo (de zona o no de zona) deja de estar No Sí Sí1 Sí

disponible
Se produce una interrupción en toda la región en la región primaria No No Sí1 Sí1
1
Se requiere la conmutación por error de cuenta para restaurar la disponibilidad de
escritura si la región primaria deja de estar disponible.
Para obtener más información sobre los precios de las diferentes opciones de
redundancia, consulte Precios de Azure Files .
Consulte también
Cambio de la opción de redundancia para una cuenta de almacenamiento
Uso de redundancia geográfica para diseñar aplicaciones de alta disponibilidad
Recuperación ante desastres y
conmutación por error para Azure Files
Artículo • 23/10/2023
Microsoft se esfuerza por garantizar que los servicios de Azure siempre estén
disponibles. Sin embargo, es posible que se produzcan interrupciones de servicio no
planeadas y debe tener un plan de recuperación ante desastres (DR) para controlar una
interrupción del servicio regional. Parte importante de un plan de recuperación ante
desastres es preparar la conmutación por error en el punto de conexión secundario ante
la eventualidad de que el punto de conexión principal deje de estar disponible. En este
artículo se describen los conceptos y procesos implicados en la recuperación ante
desastres (DR) y la conmutación por error de la cuenta de almacenamiento.
） Importante
Azure File Sync solo admite la conmutación por error de la cuenta de

almacenamiento si el servicio de sincronización de almacenamiento también se
conmuta por error. Esto se debe a que Azure File Sync requiere que la cuenta de
almacenamiento y el servicio de sincronización de almacenamiento estén en la
misma región de Azure. Si solo se conmuta por error la cuenta de almacenamiento,
se producirá un error en las operaciones de sincronización y nube por niveles hasta
que el servicio de sincronización de almacenamiento se conmute por error a la
región secundaria. Si quiere conmutar por error una cuenta de almacenamiento
que contiene recursos compartidos de archivos de Azure que se usan como puntos
de conexión en la nube en Azure File Sync, vea Procedimientos recomendados de
recuperación ante desastres de Azure File Sync y recuperación del servidor de
Azure File Sync.
Métricas y costos de recuperación

Para formular una estrategia de recuperación ante desastres eficaz, una organización
debe comprender lo siguiente:
Cantidad de datos que puede permitirse perder en caso de interrupción (objetivo

de punto de recuperación o RPO)
La rapidez con la que debe poder restaurar las funciones empresariales y los datos
(objetivo de tiempo de recuperación o RTO)
El costo de la recuperación ante desastres generalmente aumenta con un RPO o un RTO
más bajo o cero. Las empresas que necesitan estar en funcionamiento unos segundos
después de un desastre y que no pueden soportar ninguna pérdida de datos pagarán
más por recuperación ante desastres, mientras que aquellas con números de RPO/RTO
más altos pagarán menos. Azure proporciona soluciones que pueden funcionar con
varios requisitos de RPO y RTO.
Elección de la opción de redundancia correcta

Azure Files ofrece diferentes opciones de redundancia para proteger los datos de
eventos planeados y no planeados que van desde errores transitorios de hardware, red
e interrupciones de energía hasta desastres naturales. Todos los recursos compartidos
de archivos de Azure pueden usar almacenamiento con redundancia local (LRS) o con
redundancia de zona (ZRS). Para más información, consulte Redundancia de Azure Files.
Azure Files admite la conmutación por error de cuentas para cuentas de

almacenamiento estándar configuradas con almacenamiento con redundancia
geográfica (GRS) y almacenamiento con redundancia de zona geográfica (GZRS) para
protegerse frente a interrupciones regionales. Con la conmutación por error de la
cuenta, puede iniciar el proceso de conmutación por error de la cuenta de
almacenamiento si el punto de conexión principal deja de estar disponible. La
conmutación por error actualiza el punto de conexión secundario para convertirlo en el
principal de la cuenta de almacenamiento. Una vez finalizada la conmutación por error,
los clientes pueden empezar a escribir en el nuevo punto de conexión principal.
GRS y GZRS siguen presentando un riesgo de pérdida de datos porque los datos se
copian en la región secundaria de forma asincrónica, lo que significa que hay un retraso
antes de que una escritura en la región primaria se copie en la secundaria. Si se produce
una interrupción, se perderán las operaciones de escritura del punto de conexión
principal que todavía no se hayan copiado en el punto de conexión secundario. Esto
significa que un error que afecte a la región primaria podría provocar la pérdida de
datos si no se puede recuperar dicha región. El intervalo entre las escrituras más
recientes en la región primaria y la última escritura en la región secundaria es el objetivo
de punto de recuperación. Normalmente, Azure Files tiene un RPO de 15 minutos o
menos, aunque actualmente no hay ningún Acuerdo de Nivel de Servicio sobre el
tiempo que se tarda en replicar los datos en la región secundaria.
Diseño para lograr alta disponibilidad

Es importante diseñar la aplicación para lograr alta disponibilidad desde el principio.
Consulte estos recursos de Azure para instrucciones sobre cómo diseñar la aplicación y
planificar la recuperación ante desastres:
Diseño de aplicaciones resistentes de Azure: información general de los conceptos

clave para diseñar aplicaciones altamente disponibles en Azure.
Lista de comprobación de resistencia: lista de comprobación para verificar que la
aplicación implementa los mejores procedimientos recomendados para lograr alta
disponibilidad.
Uso de redundancia geográfica para diseñar aplicaciones de alta disponibilidad:
instrucciones de diseño para compilar aplicaciones para aprovechar el
almacenamiento con redundancia geográfica.
También recomendamos diseñar la aplicación para prepararse para la posibilidad de

errores de escritura. La aplicación debe exponer los errores de escritura de manera de
avisarle sobre la posibilidad de que se produzca una interrupción en la región primaria.
Como procedimiento recomendado, diseñe la aplicación para comprobar la propiedad

Hora de la última sincronización para evaluar la pérdida de datos esperada. Por ejemplo,
si registra todas las operaciones de escritura, puede comparar la hora de las últimas
operaciones de escritura con la hora de la última sincronización para determinar las
escrituras que no se sincronizaron en la región secundaria.
Seguimiento de las interrupciones

Se puede suscribir al panel de Azure Service Health para hacer el seguimiento del
estado de Azure Files y otros servicios de Azure.
Descripción del proceso de conmutación por

error de una cuenta
La conmutación por error de una cuenta administrada por el cliente le permite
conmutar por error toda una cuenta de almacenamiento en la región secundaria si la
región principal deja de estar disponible por cualquier motivo. Cuando se fuerza una
conmutación por error en la región secundaria, los clientes pueden empezar a escribir
datos en el punto de conexión secundario una vez que se completa la conmutación por
error. Por lo general, la conmutación por error tarda aproximadamente una hora. Se
recomienda suspender la carga de trabajo tanto como sea posible antes de iniciar una
conmutación por error de cuenta.
Para más información sobre cómo iniciar una conmutación por error de una cuenta,
consulte el artículo sobre la iniciación de la conmutación por error de una cuenta.
Funcionamiento de la conmutación por error de una
cuenta
En circunstancias normales, un cliente escribe los datos en una cuenta de
almacenamiento en la región primaria y esos datos se copian de forma asincrónica en la
región secundaria. En la imagen siguiente se muestra el escenario donde está disponible
la región primaria:
Si el punto de conexión principal deja de estar disponible por cualquier motivo, el

cliente ya no puede escribir en la cuenta de almacenamiento. En la imagen siguiente
muestra el escenario en que la región primaria ha dejado de estar disponible, pero
todavía no se ha realizado la recuperación:

El cliente inicia la conmutación por error de la cuenta en el punto de conexión
secundario. El proceso de conmutación por error actualiza la entrada DNS que
proporciona Azure Storage, de modo tal que el punto de conexión secundario se
convierte en el nuevo punto de conexión principal de la cuenta de almacenamiento, tal
como se muestra en la imagen siguiente:
El acceso de escritura se restaura para las cuentas con redundancia geográfica una vez
que la entrada DNS se actualiza y las solicitudes se dirigen al nuevo punto de conexión
principal. Los puntos de conexión de servicio de almacenamiento existentes no cambian
después de la conmutación por error. Los identificadores de archivos y las concesiones
no se conservan en la conmutación por error, por lo que los clientes deben desmontar y
volver a montar los recursos compartidos de archivos.
） Importante
Una vez completada la conmutación por error, la cuenta de almacenamiento se

configura para que sea con redundancia local en el nuevo punto de conexión o
región principal. Para reanudar la replicación en el nuevo punto de conexión
secundario, vuelva a configurar la cuenta para la redundancia geográfica.
Tenga en cuenta que la conversión de una cuenta de almacenamiento con

redundancia local para usar redundancia geográfica conlleva un costo y un tiempo.
Para más información, consulte Implicaciones importantes de la conmutación por
error de la cuenta.
Previsión de la pérdida de datos

Ｕ Precaución
Por lo general, la conmutación por error de una cuenta implica perder algunos
datos. Es importante entender las implicaciones que tiene iniciar la conmutación
por error de una cuenta.
Como los datos se escriben de forma asincrónica desde la región primaria a la

secundaria, si la región primaria deja de estar disponible, es posible que las escrituras
más recientes aún no se hayan copiado en la región secundaria.
Al forzar una conmutación por error, todos los datos de la región primaria se pierden a
medida que la región secundaria se convierte en la nueva región primaria. La nueva
región primaria está configurada para tener redundancia local después de la
conmutación por error.
Todos los datos ya copiados en la región secundaria se conservan cuando se produce la

conmutación por error. Sin embargo, los datos escritos en la región primaria que no se
hayan copiado en la región secundaria se perderán de forma permanente.
Comprobación de la propiedad Hora de la última

sincronización
La propiedad Last Sync Time (LST) indica la hora más reciente en que se garantiza que
los datos de la región primaria se escribieron en la secundaria. Todos los datos escritos
antes de la última hora de sincronización están disponibles en la base de datos
secundaria, mientras que es posible que los datos escritos después de la última hora de
sincronización no se hayan escrito en la base de datos secundaria y que se pierdan. Use
esta propiedad si se produce una interrupción para calcular la cantidad de datos
perdidos que puede haber al iniciar la conmutación por error de una cuenta.
Para asegurarse de que los recursos compartidos de archivos estén en un estado

coherente cuando se produce una conmutación por error, se crea una instantánea del
sistema en la región primaria cada 15 minutos y se replica en la región secundaria.
Cuando se produce una conmutación por error a la región secundaria, el estado del
recurso compartido se basará en la instantánea del sistema más reciente de la región
secundaria. Si se produce un error en la región primaria, es probable que la región
secundaria esté retrasada en relación con la región primaria, ya que todas las
operaciones de escritura en la primaria no se habrían replicado todavía en la secundaria.
Debido al retraso geográfico u otros problemas, la instantánea del sistema más reciente
de la región secundaria podría ser mayor que 15 minutos.
Todas las operaciones de escritura en la región primaria antes de la LST se han replicado
correctamente en la región secundaria, lo que significa que están disponibles para
leerse desde la región secundaria. Es posible que las operaciones de escritura en la
región primaria, después de la hora de la última sincronización, se hayan replicado o no
en la región secundaria, lo que significa que podrían no estar disponibles para las
operaciones de lectura.
Puede consultar el valor de la propiedad Hora de la última sincronización mediante

Azure PowerShell, la CLI de Azure o la biblioteca cliente. La propiedad Hora de la última
sincronización es un valor de fecha y hora GMT. Para obtener más información, consulte
Comprobación de la propiedad Hora de la última sincronización de una cuenta de
almacenamiento.
Precaución al conmutar por recuperación en la región

primaria original
Como se mencionó anteriormente, después de conmutar por error desde la región
primaria a la secundaria, la cuenta de almacenamiento se configura con redundancia
local en la nueva región primaria. A continuación, puede configurar la cuenta en la
nueva región primaria para la redundancia geográfica. Cuando la cuenta se configura
para usar la redundancia geográfica después de una conmutación por error, la nueva
región primaria empieza de inmediato a copiar los datos en la nueva región secundaria,
que antes de la conmutación por error original era la primaria. Sin embargo, puede
tardar algún tiempo antes de que los datos existentes en la nueva base de datos
principal se copien completamente en la nueva secundaria.
Una vez que la cuenta de almacenamiento se vuelve a configurar para la redundancia

geográfica, es posible iniciar una conmutación por recuperación de la nueva región
primaria a la nueva región secundaria. En este caso, la región primaria original de antes
de la conmutación por error se convierte de nuevo en la región primaria y se configura
para redundancia local o redundancia de zona, en función de si la configuración
primaria original era GRS o GZRS. Todos los datos de la región primaria posterior a la
conmutación por error (la región secundaria original) se pierden durante la conmutación
por recuperación. Si la mayoría de los datos de la cuenta de almacenamiento nunca se
ha copiado en la nueva región secundaria antes de la conmutación por recuperación,
podría ocurrir una pérdida de datos importante.
Para evitar que suceda esto, compruebe el valor de la propiedad Hora de última
sincronización antes de la conmutación por recuperación. Compare la hora de última
sincronización con las últimas horas en que los datos se escribieron en la nueva región
primaria para evaluar la pérdida de datos esperada.
Después de una operación de conmutación por recuperación, puede configurar la nueva
región primaria para redundancia geográfica de nuevo. Si la región primaria original se
configuró para LRS, puede configurarla para que tenga GRS. Si la región primaria
original se configuró para LRS, puede configurarla para que tenga GZRS. Para otras
opciones, consulte Cambio de la forma en que se replica una cuenta de
almacenamiento.
Iniciación de una conmutación por error de la

cuenta
Puede iniciar la conmutación por error de una cuenta desde Azure Portal, PowerShell, la
CLI de Azure o la API de proveedor de recursos de Azure Storage. Para más información
sobre cómo iniciar una conmutación por error, consulte el artículo sobre la iniciación de
la conmutación por error de una cuenta.
Conmutación por error administrada por

Microsoft
En casos extremos en los que se pierde una región debido a un desastre importante,
Microsoft puede iniciar una conmutación por error regional. En este caso, no se
requieren acciones por su parte. No tendrá acceso de escritura a la cuenta de
almacenamiento hasta que se complete la conmutación por error administrada por
Microsoft.
Consulte también
Introducción a la protección de datos de Azure Files
Inicio de una conmutación por error de la cuenta de almacenamiento
Acerca de la copia de seguridad de
recursos compartidos de archivos de
Azure
Artículo • 01/06/2023
La copia de seguridad de recursos compartidos de archivos de Azure es una solución de

copia de seguridad nativa basada en la nube que protege los datos en la nube y elimina
las sobrecargas de mantenimiento adicionales implicadas en las soluciones de copia de
seguridad locales. El servicio Azure Backup se integra completamente con Azure File
Sync y permite centralizar los datos de recursos compartidos de archivos, así como las
copias de seguridad. Esta solución sencilla, confiable y segura le permite configurar la
protección de los recursos compartidos de archivos de su empresa en unos cuantos
pasos fáciles con la garantía de poder recuperar los datos en caso de eliminación
accidental.
Principales ventajas de la copia de seguridad

de recursos compartidos de archivos de Azure
Cero infraestructura: no se necesita ninguna implementación para configurar la
protección de los recursos compartidos de archivos.
Retención personalizada: Puede configurar copias de seguridad con retención
diaria, semanal, mensual o anual según sus requisitos.
Funcionalidades de administración integradas: puede programar copias de
seguridad y especificar el período de retención deseado sin la sobrecarga adicional
de eliminación de datos.
Restauración instantánea: la copia de seguridad de recursos compartidos de
archivos de Azure usa instantáneas de recursos compartidos de archivos, por lo
que puede seleccionar justo los archivos que quiera restaurar al instante.
Alertas e informes: puede configurar alertas para los errores de copia de
seguridad y restauración y usar la solución de generación de informes que se
proporciona en Azure Backup para obtener información sobre las copias de
seguridad en los recursos compartidos de archivos.
Protección contra la eliminación accidental de recursos compartidos de archivos:
Azure Backup habilita la característica de eliminación temporal en el nivel de
cuenta de almacenamiento con un período de retención de 14 días. Incluso si un
actor malintencionado elimina el recurso compartido de archivos, su contenido y
puntos de recuperación (instantáneas) se conservan durante un período de
retención configurable, lo que permite recuperar correctamente y por completo el
contenido de origen y las instantáneas sin pérdida de datos.
Protección contra la eliminación accidental de instantáneas: Azure Backup
adquiere un contrato de arrendamiento de las instantáneas tomadas por trabajos
de copia de seguridad programados o a petición. La concesión actúa como un
bloqueo que agrega una capa de protección y protege las instantáneas contra la
eliminación accidental.
Architecture
Cómo funciona el proceso de copia de

seguridad
1. El primer paso para configurar la copia de seguridad de recursos compartidos de
archivos de Azure es crear un almacén de Recovery Services. El almacén
proporciona una vista consolidada de las copias de seguridad configuradas en
diferentes cargas de trabajo.
2. Una vez que se crea un almacén, el servicio Azure Backup detecta las cuentas de
almacenamiento que se pueden registrar en él. Puede seleccionar la cuenta de
almacenamiento que hospeda los recursos compartidos de archivos que quiere
proteger.
3. Después de seleccionar la cuenta de almacenamiento, el servicio Azure Backup

muestra el conjunto de recursos compartidos de archivos presentes en ella y
almacena sus nombres en el catálogo de niveles de administración.
4. Luego, configure la directiva de copia de seguridad (programación y retención)
según sus requisitos y seleccione los recursos compartidos de archivos de los que
quiere realizar una copia de seguridad. El servicio Azure Backup registra las
programaciones en el plano de control para realizar copias de seguridad
programadas.
5. Según la directiva especificada, el programador de Azure Backup desencadena las

copias de seguridad a la hora programada. Como parte de ese trabajo, se crea la
instantánea de recursos compartidos de archivos mediante la API de recurso
compartido de archivos. Solo la dirección URL de la instantánea se almacena en el
almacén de metadatos.
７ Nota
Los datos de los recursos compartidos de archivos no se transfieren al servicio

Azure Backup, dado que este crea y administra las instantáneas que forman
parte de la cuenta de almacenamiento y las copias de seguridad no se
transfieren al almacén.
6. Puede restaurar el contenido de los recursos compartidos de archivos de Azure

(archivos individuales o el recurso compartido completo) de las instantáneas
disponibles en el recurso compartido de archivos de origen. Una vez que se
desencadena la operación, la dirección URL de la instantánea se recupera del
almacén de metadatos y los datos se muestran y transfieren desde la instantánea
de origen al recurso compartido de archivos de destino que elija.
7. Si usa Azure File Sync, el servicio de copia de seguridad indica al servicio Azure File
Sync las rutas de acceso de los archivos que se están restaurando, lo que
desencadena un proceso de detección de cambios en segundo plano en estos
archivos. Los archivos que han cambiado se sincronizan con el punto de conexión
del servidor. Este proceso se produce en paralelo a la restauración original en el
recurso compartido de archivos de Azure.
8. Los datos de supervisión de los trabajos de copia de seguridad y restauración se

insertan en el servicio de supervisión de Azure Backup. Esto le permite supervisar
las copias de seguridad en la nube de los recursos compartidos de archivos en un
único panel. Además, también puede configurar alertas o notificaciones por correo
electrónico cuando resulte afectado el estado de la copia de seguridad. Se envían
correos electrónicos a través del servicio de correo electrónico de Azure.
Costos de la copia de seguridad

Existen dos costos asociados con la solución de copia de seguridad del recurso
1. Costo del almacenamiento de instantáneas: Los cargos por almacenamiento

incurridos por las instantáneas se facturan junto con el uso de Azure Files según
los detalles de precios que figuran aquí .
2. Cuota de instancia protegida: a partir del 1 de septiembre de 2020, se le cobrará

una cuota de instancia protegida según los detalles de precios . La cuota de
instancia protegida depende del tamaño total de los recursos compartidos de
archivos protegidos en una cuenta de almacenamiento.
Para obtener estimaciones detalladas para realizar copias de seguridad de los recursos
compartidos de archivos de Azure, puede descargar el estimador de precios de Azure
Backup detallado.
¿Cómo funciona la instantánea del tiempo de la

concesión?
Cuando Azure Backup toma una instantánea, programada o a petición, agrega un
bloqueo en la instantánea con la funcionalidad de instantánea de concesión de la
plataforma Archivos. El bloqueo protege las instantáneas de eliminación accidental y la
duración del bloqueo es infinita. Si un archivo compartido tiene instantáneas
concedidas, la eliminación ya no es una operación de un solo clic. Por lo tanto, también
obtiene protección contra la eliminación accidental del recurso compartido de archivos
de copia de seguridad.
Para proteger una instantánea de la eliminación mientras la operación de restauración

está en curso, Azure Backup comprueba el estado de concesión de la instantánea. Si no
está concedida, agrega un bloqueo al tomar un contrato de arrendamiento en la
instantánea.
En el siguiente diagrama se explica el ciclo de vida de la concesión adquirida por Azure

Backup:
Pasos siguientes
Más información sobre cómo realizar copias de seguridad de recursos compartidos
Encuentre respuestas a las preguntas sobre la copia de seguridad de Azure Files.
Información general de las instantáneas
de recurso compartido de Azure Files
Artículo • 16/10/2023
Azure Files proporciona la capacidad de tomar instantáneas de recursos compartidos de

SMB. Las instantáneas de recursos compartidos capturan el estado del recurso
compartido en ese momento dado. En este artículo se describen las funcionalidades que
proporcionan las instantáneas del recurso compartido de archivos y cómo sacar
provecho de ellas en el caso de uso personalizado.
Las instantáneas de recursos compartidos de archivos NFS se encuentran actualmente

en versión preliminar pública con disponibilidad regional limitada.
Se aplica a
Cuándo usar instantáneas de recursos

compartidos
Error de protección frente a la aplicación y datos dañados

Las aplicaciones que usan recursos compartidos de archivos realizan operaciones tales
como escritura, lectura, almacenamiento, transmisión o procesamiento. Si se
desconfigura una aplicación o se produce un error accidental, es posible que se
produzca una sobrescritura involuntaria o daños en algunos bloques. Para evitar estas
circunstancias, puede tomar una instantánea del recurso compartido antes de
implementar un código de aplicación nuevo. Si se produce un error o hay algún
problema con la aplicación al llevar a cabo la nueva implementación, puede volver a la
versión anterior de los datos de ese recurso compartido de archivos.
Protección frente a eliminaciones accidentales y cambios
no intencionados
Imagine que está trabajando en un archivo de texto en un recurso compartido de
archivos. Una vez que se cierra el archivo de texto pierde la capacidad de deshacer los
cambios. En estos casos, necesitará recuperar una versión anterior del archivo. Gracias a
las instantáneas de recursos compartidos, podrá recuperar versiones anteriores del
archivo si se cambia el nombre o se elimina accidentalmente.
Propósitos generales de copia de seguridad

Después de crear un recurso compartido de archivos, puede crear periódicamente una
instantánea de recurso compartido del recurso compartido de archivos para usarla
como una copia de seguridad de los datos. Si toma instantáneas de recurso compartido
de forma periódica, podrá tener versiones de datos previas y usarlas si son necesarias en
posibles auditorías o en una recuperación ante desastres. Se recomienda usar la copia
de seguridad del recurso compartido de archivos de Azure para tomar y administrar
instantáneas. También puede tomar y administrar instantáneas usted mismo, mediante
Azure Portal, Azure PowerShell o la CLI de Azure.
Capacidades
Una instantánea de recurso compartido es una copia de solo lectura de un momento
dado de sus datos. En el nivel del recurso compartido de archivos se proporciona la
funcionalidad de la instantánea de recurso compartido. La recuperación se ofrece en el
nivel de archivos individuales para permitir la restauración de archivos individuales.
Puede restaurar un recurso compartido de archivos completo mediante el SMB, NFS
(versión preliminar), la API REST, Azure Portal, la biblioteca cliente o con PowerShell o
CLI.
Puede ver las instantáneas de un recurso compartido con la API REST, SMB o NFS
(versión preliminar). Igualmente, puede recuperar la lista de versiones del directorio o
archivo y también puede montar una versión específica directamente como unidad
(disponible solo en Windows: consulte los Límites).
Una vez se crea la instantánea de recurso compartido, puede leerla, copiarla o

eliminarla, pero no modificarla. Recuerde que no puede copiar una instantánea de
recurso compartido completa en otra cuenta de almacenamiento. Si quiere copiarla,
deberá hacerlo archivo por archivo, mediante AzCopy u otros mecanismos de copia.
Una instantánea de recurso compartido de un recurso compartido de archivos es
idéntica a su recurso compartido de archivos base. La única diferencia es que se anexa
un valor DateTime al URI del recurso compartido para indicar el momento en que se
tomó la instantánea de recurso compartido. Por ejemplo, si el URI de un recurso
compartido de archivos es http://storagesample.core.file.windows.net/myshare, el URI
de instantánea es similar a:
http://storagesample.core.file.windows.net/myshare?snapshot=2011-03-
09T01:42:34.9360000Z
Las instantáneas de recurso compartido se conservan hasta que se eliminan

explícitamente. Una instantánea de recurso compartido no puede durar más que su
recurso compartido de archivos base. Puede enumerar las instantáneas asociadas al
recurso compartido de archivos base para llevar a cabo un seguimiento de las
instantáneas actuales.
Cuando crea una instantánea de recurso compartido de un recurso compartido de

archivos, los archivos que se encuentren en las propiedades del sistema del recurso
compartido se copian en la instantánea de recurso compartido con los mismos valores.
Los metadatos del recurso compartido de archivos y los archivos base también se
copian en la instantánea de recurso compartido, a menos que especifique los metadatos
independientes de la instantánea de recurso compartido al crearla.
No puede eliminar un recurso compartido que disponga de instantáneas de recurso

compartido sin antes eliminar todas las instantáneas de ese recurso compartido de
archivos.
Uso del espacio

Las instantáneas de recurso compartido son de naturaleza incremental. Solo se guardan
los datos que hayan cambiado después de realizar la instantánea de recurso compartido
más reciente. Esto minimiza el tiempo necesario para crear la instantánea de recurso
compartido y ahorra en costos de almacenamiento. Cualquier operación de escritura en
el objeto o propiedad o cualquier operación de actualización de metadatos se agrega al
"contenido cambiado" y se guarda en la instantánea de recurso compartido.
Para ahorrar espacio, puede eliminar la instantánea de recurso compartido durante el

periodo en el que la renovación se encuentra en su punto álgido.
Incluso si las instantáneas de recurso compartido se guardan de forma incremental,
solamente deberá guardar la instantánea de recurso compartido más reciente para
poder restaurar el recurso compartido. Cuando elimine una instantánea de recurso
compartido, solo se quitan los datos exclusivos para esa instantánea de recurso
compartido. Las instantáneas activas contienen toda la información necesaria para
examinar y restaurar sus datos (desde el momento en el que se realizó la instantánea de
recurso compartido) en la ubicación original o en una alternativa. Puede restaurarlas en
el nivel de elemento.
Las instantáneas no cuentan para el límite máximo de tamaño de recurso compartido,

que es 100 TiB para recursos compartidos de archivos Premium y recursos compartidos
de archivos estándar con recursos compartidos de archivos grandes habilitados. No hay
ninguna restricción en la cantidad de espacio que ocupan las instantáneas de recurso
compartido. Los límites de cuenta de almacenamiento se siguen aplicando.
Límites
El número máximo de instantáneas de recurso compartido que permite Azure Files
actualmente es de 200 por recurso compartido. Una vez se llegue a las 200 instantáneas
de recurso compartido, tiene que eliminar las más antiguas para poder crear otras
nuevas. Puede conservar instantáneas durante un máximo de 10 años.
No hay ningún límite en las llamadas simultáneas dedicadas a crear instantáneas de

recurso compartido. Asimismo, tampoco hay ningún límite en la cantidad de espacio
que las instantáneas de recurso compartido de un recurso compartido de archivos
determinado pueden consumir.
Las instantáneas de recursos compartidos de archivos NFS se encuentran actualmente

en versión preliminar pública con disponibilidad regional limitada. La versión preliminar
solo admite las API de administración ( AzRmStorageShare ), no las API del plano de datos
( AzStorageShare ), lo que permite a los usuarios crear, listar y eliminar instantáneas de
recursos compartidos de archivos de Azure NFS.
Volver a copiar datos en un recurso compartido

desde una instantánea de recurso compartido
Las operaciones de copia que implican archivos e instantáneas de recurso compartido
siguen estas reglas:
Puede copiar archivos individuales en una instantánea de recurso compartido de

archivos por encima de su recurso compartido base o en cualquier otra ubicación.
Puede restaurar una versión anterior de un archivo o restaurar un recurso compartido
de archivos completo copiando archivo por archivo desde la instantánea de recurso
compartido. La instantánea de recurso compartido no se promociona al recurso
compartido base.
La instantánea de recurso compartido se mantiene intacta después de la operación de

copia, pero el recurso compartido de archivos base se sobrescribe con una copia de los
datos que estaban disponibles en la instantánea de recurso compartido. Todos los
archivos restaurados se tienen en cuenta como "contenido cambiado".
Puede copiar un archivo en una instantánea de recurso compartido en un destino

diferente con un nombre distinto. El archivo de destino resultante es un archivo en el
que se puede escribir y no una instantánea de recurso compartido. En este caso, el
recurso compartido de archivos de base permanecerá intacto.
Cuando un archivo de destino se sobrescribe con una copia, las instantáneas de recurso
compartido asociadas al archivo de destino original no se modifican.
Procedimientos recomendados generales

Automatice las copias de seguridad para la recuperación de datos siempre que sea
posible. Las acciones automatizadas son más fiables que los procesos manuales, lo que
le ayuda a mejorar la recuperabilidad y la protección de datos. Puede usar la copia de
seguridad de recursos compartidos de archivos de Azure, la API REST, el SDK del cliente
o el scripting de automatización.
Antes de implementar el programador de la instantánea de recurso compartido, tenga

en cuenta la frecuencia de la instantánea de recurso compartido y la configuración de
retención para evitar gastos innecesarios.
Las instantáneas de recurso compartido solo proporcionan protección a nivel de

archivo. Recuerde que las instantáneas de recurso compartido no previenen
eliminaciones que se hayan producido por errores involuntarios en un recurso
compartido de archivos o en una cuenta de almacenamiento. Para impedir la
eliminación accidental de una cuenta de almacenamiento, puede habilitar la eliminación
temporal o bloquear la cuenta de almacenamiento o el grupo de recursos.
Consulte también
Trabajo con instantáneas de recurso compartido en:
Copia de seguridad de un recurso compartido de archivos de Azure
Azure PowerShell
CLI de Azure
Windows
Preguntas más frecuentes sobre instantáneas de recurso compartido
Evitar la eliminación accidental de
Azure
Artículo • 01/06/2023
Azure Files ofrece eliminación temporal para los recursos compartidos de archivos de
SMB. La eliminación temporal permite recuperar el recurso compartido de archivos
cuando una aplicación u otro usuario de la cuenta de almacenamiento lo ha eliminado
por error.
Se aplica a
Cómo funciona la eliminación temporal

Cuando la eliminación temporal de recursos compartidos de archivos de Azure está
habilitada en una cuenta de almacenamiento, si se elimina uno de ellos, realiza la
transición a un estado de eliminación temporal, en lugar de borrarse de forma
permanente. Se puede configurar el tiempo durante el que los datos eliminados de
forma temporal se pueden recuperar antes de que se eliminen permanentemente y
durante este período de retención el recurso compartido se puede recuperar en
cualquier momento. Después de recuperarlo, tanto el recurso compartido como todo su
contenido, incluidas las instantáneas, se restaurarán al estado en que se encontraban
antes de la eliminación. La eliminación temporal solo funciona a nivel de recurso
compartido de archivos (los archivos individuales que se eliminen se borrarán de forma
permanente).
La eliminación temporal se puede habilitar en recursos compartidos de archivos nuevos

o existentes. La eliminación temporal también es compatible con versiones anteriores
por lo que no es necesario realizar ningún cambio en las aplicaciones para aprovechar
las ventajas de las protecciones que se obtienen con esta característica. La eliminación
temporal no funciona con los recursos compartidos de NFS, incluso si está habilitada
para la cuenta de almacenamiento.
Para eliminar de forma permanente un recurso compartido de archivos en un estado de

eliminación temporal antes de su hora de expiración, debe recuperar el recurso
compartido, deshabilitar la eliminación temporal y, después, volver a eliminar el recurso
compartido. Luego, debe volver a habilitar la eliminación temporal, ya que los restantes
recursos compartidos de archivos de esa cuenta de almacenamiento serán vulnerables a
la eliminación accidental mientras la eliminación temporal esté desactivada.
En el caso de los recursos compartidos de archivos Premium eliminados temporalmente,

la cuota de recursos compartidos de archivos (el tamaño aprovisionado de un recurso
compartido de archivos) se usa en el cálculo de la cuota de cuenta de almacenamiento
total hasta la fecha de expiración del recurso compartido con eliminación temporal,
cuando este se elimina de forma completa.
Parámetros de configuración
Habilitación o deshabilitación de la eliminación temporal

La eliminación temporal de recursos compartidos de archivos está habilitada en el nivel
de cuenta de almacenamiento, a causa de ello, la configuración de eliminación temporal
se aplica a todos los recursos compartidos de archivos de una cuenta de
almacenamiento. La eliminación temporal está habilitada de forma predeterminada para
las nuevas cuentas de almacenamiento y se puede deshabilitar o habilitar en cualquier
momento. La eliminación temporal no se habilita automáticamente en las cuentas de
almacenamiento existentes a menos que se haya configurado la copia de seguridad del
recurso compartido de archivos de Azure para un recurso compartido de archivos de
Azure en dicha cuenta de almacenamiento. Si se configuró la copia de seguridad del
recurso compartido de archivos de Azure, la eliminación temporal de estos recursos
compartidos de archivos de Azure se habilita automáticamente en la cuenta de
almacenamiento de ese recurso compartido.
Si habilita la eliminación temporal para recursos compartidos de archivos, elimina

algunos y, después, deshabilita la eliminación temporal, si durante ese período se han
guardado los recursos compartidos, todavía podrá acceder a ellos y recuperarlos. Al
habilitar la eliminación temporal, también debe configurar el período de retención.
Período de retención
El período de retención es la cantidad de tiempo durante el que los recursos
compartidos de archivos eliminados temporalmente se almacenan y están disponibles
para su recuperación. En el caso de los recursos compartidos de archivos que se
eliminan explícitamente, el reloj del período de retención se pone en marcha cuando se
eliminan los datos. Actualmente se puede especificar un periodo de retención que oscile
entre 1 y 365 días. El período de retención de la eliminación temporal se puede cambiar
en cualquier momento. Un período de retención actualizado solo se aplicará a los
recursos compartidos eliminados una vez que se haya actualizado el período de
retención. Los recursos compartidos eliminados antes del período de retención
expirarán en función del período de retención que se ha configurado en el momento de
eliminar los datos.
Precios y facturación
Los recursos compartidos de archivos Estándar y Premium se facturan según la
capacidad usada cuando se han eliminado temporalmente, en lugar de la capacidad
aprovisionada. Además, los recursos compartidos de archivos Premium se facturan
según la tasa de instantáneas mientras se encuentran en el estado de eliminación
temporal. Los recursos compartidos de archivos Estándar se facturan según la tasa
habitual mientras se encuentran en el estado de eliminación temporal. Los datos que se
eliminen permanentemente después del período de retención configurado no se
cobrarán.
Para más información sobre los precios de Azure Files en general, consulte la página de
precios de Azure Files .
Cuando se habilita inicialmente la eliminación temporal, se recomienda usar un período

de retención pequeño para comprender mejor cómo afecta la característica a la
facturación.
Pasos siguientes
Para aprender a habilitar y usar la eliminación temporal, vaya a Habilitación de la
eliminación temporal.
Para obtener información sobre cómo evitar que una cuenta de almacenamiento se
elimine o modifique, consulte Aplicación de un bloqueo de Azure Resource Manager a
una cuenta de almacenamiento.
Para obtener información sobre cómo aplicar bloqueos a recursos y grupos de recursos,
consulte Bloqueo de recursos para evitar cambios inesperados.
Redundancia geográfica de Azure Files
para recursos compartidos de archivos
grandes (versión preliminar)
Artículo • 28/08/2023
La redundancia geográfica de Azure Files para recursos compartidos de archivos

grandes (versión preliminar) mejora significativamente la capacidad y el rendimiento de
los recursos compartidos de archivos SMB estándar al usar las opciones de
almacenamiento con redundancia geográfica (GRS) y almacenamiento con redundancia
de zona geográfica (GZRS).
Durante varios años, Azure Files ha sido compatible con recursos compartidos de
archivos grandes. Esto no solo proporciona una capacidad de recurso compartido de
archivos de hasta 100 TiB, sino que también mejora el rendimiento y las IOPS. En gran
medida, los clientes han adoptado el uso de recursos compartidos de archivos grandes
mediante el almacenamiento con redundancia local (LRS) y almacenamiento con
redundancia de zona (ZRS). No obstante, las opciones de almacenamiento con
redundancia geográfica (GRS) y almacenamiento con redundancia de zona geográfica
(GZRS) no han estado disponibles hasta ahora.
Redundancia geográfica de Azure Files para recursos compartidos de archivos grandes

(la "versión preliminar") está sujeta a los condiciones de uso complementarios para las
versiones preliminares de Microsoft Azure . Puede usar la versión preliminar en
entornos de producción.
Se aplica a
Almacenamiento con redundancia geográfica

Azure mantiene varias copias de los datos para garantizar su durabilidad y alta
disponibilidad. Para protegerse frente a interrupciones regionales, puede configurar la
cuenta de almacenamiento para GRS o GZRS para copiar los datos de forma asincrónica
en dos regiones geográficas separadas por cientos de kilómetros. Esta versión
preliminar agrega la compatibilidad con GRS y GZRS para las cuentas de
almacenamiento estándar que tienen habilitada la característica de recursos
compartidos de archivos grandes.

sincrónica tres veces dentro de una única ubicación física en la región primaria.
Luego copia los datos de forma asincrónica en una única ubicación física en la
región secundaria. Dentro de la región secundaria, los datos se copian de forma
sincrónica tres veces.
El almacenamiento con redundancia de zona geográfica (GZRS) copia los datos

de manera sincrónica en tres zonas de disponibilidad de Azure de la región
primaria. Luego copia los datos de forma asincrónica en una única ubicación física
en la región secundaria. Dentro de la región secundaria, los datos se copian de
forma sincrónica tres veces.
Si la región primaria deja de estar disponible por cualquier motivo, puede iniciar una
conmutación por error de cuenta en la región secundaria.
７ Nota
Azure Files no admite el almacenamiento con redundancia geográfica con acceso

de lectura (RA-GRS) ni el almacenamiento con redundancia de zona geográfica con
acceso de lectura (RA-GZRS). Si una cuenta de almacenamiento está configurada
para usar RA-GRS o RA-GZRS, los recursos compartidos de archivos se configurarán
como GRS o GZRS. Los recursos compartidos de archivos no serán accesibles en la
región secundaria a menos que se produzca una conmutación por error.
Límites de recursos compartidos de archivos

grandes
La habilitación de los recursos compartidos de archivos grandes, al usar el
almacenamiento con redundancia geográfica (GRS) y el almacenamiento con
redundancia de zona geográfica (GZRS), aumenta significativamente los límites de
capacidad y rendimiento de los recursos compartidos de archivos estándar:
Atributo Límite Límite de recursos compartidos de
actual archivos grandes
Capacidad por recurso compartido 5 TiB 100 TiB (aumento de 20 veces)
Máximo de IOPS por recurso 1000 IOPS 20 000 IOPS (aumento de 20 veces)
compartido
Rendimiento máximo por recurso Up to 60 Hasta el límite de la cuenta de

compartido MiB/s almacenamiento
Disponibilidad en regiones
Actualmente, la versión preliminar de redundancia geográfica para recursos
compartidos de archivos grandes de Azure Files está disponible en las siguientes
regiones:
Centro de Australia
Centro de Australia 2
Este de Australia
Sudeste de Australia
Sur de Brasil
Sur de Brasil
Centro de Canadá
Este de Canadá
Centro de la India
Centro de EE. UU.
Este de China 2
Este de China 3
Norte de China 2
Norte de China 3
Este de Asia
Este de EE. UU.
Este de EE. UU. 2
Centro de Francia
Sur de Francia
Norte de Alemania
Centro-oeste de Alemania
Japón Oriental
Japón Occidental
Centro de Corea del Sur
Corea del Sur
Centro-Norte de EE. UU
Norte de Europa
Este de Noruega
Oeste de Noruega
Norte de Sudáfrica
Oeste de Sudáfrica
Centro-sur de EE. UU.
Sur de la India
Sudeste de Asia
Centro de Suecia
Sur de Suecia
Norte de Suiza
Oeste de Suiza
Centro de Emiratos Árabes Unidos
Norte de Emiratos Árabes Unidos
Sur de Reino Unido
Oeste de Reino Unido
US Gov: Arizona
US Gov Texas
US Gov - Virginia
Centro-Oeste de EE. UU.
Oeste de Europa
Oeste de la India
Oeste de EE. UU.
Oeste de EE. UU. 2
Oeste de EE. UU. 3
Precios
Los precios se basan en el nivel de recurso compartido de archivos estándar y la opción
de redundancia configurada para la cuenta de almacenamiento. Para más información,
consulte precios de Azure Files .
Registro para obtener la versión preliminar

Para empezar, regístrese para la versión preliminar mediante Azure Portal o PowerShell.
Azure Portal
1. Inicie sesión en Azure Portal .

2. Busque y seleccione Características en versión preliminar.
3. Haga clic en el filtro Tipo y seleccione Microsoft.Storage.
4. Seleccione Versión preliminar de redundancia geográfica para recursos
compartidos de archivos grandes de Azure Files y haga clic en Registrar.
Habilitación de la redundancia geográfica y

recursos compartidos de archivos grandes para
los recursos compartidos de archivos de SMB
estándar
Con la versión preliminar de redundancia geográfica para recursos compartidos de
archivos grandes de Azure Files, puede habilitar la redundancia geográfica y los recursos
compartidos de archivos grandes para los recursos compartidos de archivos de SMB
estándar nuevos y existentes.
Creación de una nueva cuenta de almacenamiento y un

recurso compartido de archivos
Realice los pasos siguientes para configurar la redundancia geográfica y los recursos
compartidos de archivos grandes para un nuevo recurso compartido de archivos de
Azure.
1. Cree una cuenta de almacenamiento estándar.
Seleccione almacenamiento con redundancia geográfica (GRS) o

almacenamiento con redundancia de zona geográfica (GZRS) para la opción
Redundancia.
En la sección Opciones avanzadas, seleccione Habilitar recursos compartidos
de archivos grandes.
2. Cree un recurso compartido de archivos SMB de Azure.
Cuentas de almacenamiento y recursos compartidos de

archivos existentes
Los pasos para habilitar la redundancia geográfica para los recursos compartidos de
archivos grandes variarán en función de la opción de redundancia configurada
actualmente para la cuenta de almacenamiento. Siga los pasos que se indican a
continuación en función de la opción de redundancia adecuada para la cuenta de
almacenamiento.
Cuentas de almacenamiento existentes con una opción de

redundancia de LRS o ZRS
1. Cambie la opción de redundancia de la cuenta de almacenamiento a GRS o GZRS.
2. Compruebe que la configuración de recursos compartidos de archivos grandes
está habilitada en la cuenta de almacenamiento.
3. Opcional:aumente la cuota del recurso compartido de archivos hasta 100 TiB.
Cuentas de almacenamiento existentes con una opción de

redundancia de GRS, GZRS, RA-GRS o RA-GZRS
1. Habilite la configuración de recursos compartidos de archivos grandes en la cuenta

de almacenamiento.
2. Opcional:aumente la cuota del recurso compartido de archivos hasta 100 TiB.
Frecuencia de instantánea y sincronización

Para asegurarse de que los recursos compartidos de archivos estén en un estado
coherente cuando se produce una conmutación por error, se crea una instantánea del
sistema en la región primaria cada 15 minutos y se replica en la región secundaria.
Cuando se produce una conmutación por error a la región secundaria, el estado del
recurso compartido se basará en la instantánea del sistema más reciente de la región
secundaria. Debido al retraso geográfico u otros problemas, la instantánea del sistema
más reciente de la región secundaria puede ser mayor de 15 minutos.
La propiedad Hora de la última sincronización (LST) de la cuenta de almacenamiento

indica la hora más reciente en que los datos de la región primaria se escribieron
correctamente en la secundaria. Para Azure Files, la hora de la última sincronización se
basa en la instantánea del sistema más reciente de la región secundaria. Puede usar
PowerShell o la CLI de Azure para comprobar la hora de la última sincronización de una
Es importante comprender lo siguiente sobre la propiedad Hora de la última

sincronización:
La propiedad Hora de la última sincronización de la cuenta de almacenamiento se

basa en el servicio (archivos, blobs, tablas, colas) de la cuenta de almacenamiento
que está más lejos.
La hora de la última sincronización no se actualiza si no se han realizado cambios
en la cuenta de almacenamiento.
El cálculo de hora de la última sincronización puede agotar el tiempo de espera si
el número de recursos compartidos de archivos supera los 100 por cuenta de
almacenamiento. Se recomienda menos de 100 recursos compartidos de archivos
por cuenta de almacenamiento.
Consideraciones sobre la conmutación por

error
En esta sección, se enumeran las consideraciones que podrían afectar a la capacidad de
conmutar por error a la región secundaria.
La conmutación por error de la cuenta de almacenamiento se bloqueará si no

existe una instantánea del sistema en la región secundaria.
Los identificadores de archivo y las concesiones no se conservan en la

conmutación por error y los clientes deben desmontar y volver a montar los
recursos compartidos de archivos.
La cuota del recurso compartido de archivos puede cambiar después de la

conmutación por error. La cuota del recurso compartido de archivos en la región
secundaria se basará en la cuota que se ha configurado cuando se ha capturado la
instantánea del sistema en la región primaria.
Las operaciones de copia en curso se anularán cuando se produzca una

conmutación por error. Cuando se complete la conmutación por error en la región
secundaria, vuelva a intentar la operación de copia.
Para probar la conmutación por error de la cuenta de almacenamiento, consulte Iniciar

una conmutación por error de cuenta.
Consulte también
Recuperación ante desastres y conmutación por error de la cuenta de
almacenamiento
Descripción del rendimiento de Azure
Files
Artículo • 20/07/2023
Azure Files puede satisfacer los requisitos de rendimiento de la mayoría de las

aplicaciones y casos de uso. En este artículo se explican los distintos factores que
pueden afectar al rendimiento del recurso compartido de archivos y cómo optimizar el
rendimiento de los recursos compartidos de archivos de Azure para la carga de trabajo.
Se aplica a
Glosario
Antes de leer este artículo, resulta útil comprender algunos términos clave relacionados
con el rendimiento del almacenamiento:
Operaciones de E/S por segundo (IOPS)
IOPS u operaciones de entrada/salida por segundo, mide el número de

operaciones del sistema de archivos por segundo. En la documentación de Azure
Files, el término "E/S" es un sinónimo de los términos "operación" y "transacción".
Tamaño de E/S
El tamaño de E/S, a veces denominado tamaño de bloque, es el tamaño de la

solicitud que una aplicación usa para realizar una única operación de
entrada/salida (E/S) en el almacenamiento. En función de la aplicación, el tamaño
de E/S puede variar de tamaños muy pequeños, como 4 KiB, a tamaños mucho
mayores. El tamaño de E/S desempeña un papel importante en el rendimiento
factible.
Rendimiento
El rendimiento mide el número de bits leídos o escritos en el almacenamiento por
segundo y se mide en mebibytes por segundo (MiB/s). Para calcular el
rendimiento, multiplique las IOPS por el tamaño de E/S. Por ejemplo, 10 000 IOPS *
1 MiB de tamaño de E/S = 10 GiB/s, mientras que 10 000 IOPS * 4 KiB de tamaño
de E/S = 38 MiB/s.
Latency
La latencia es un sinónimo de retraso y normalmente se mide en milisegundos

(ms). Hay dos tipos de latencia: de un extremo a otro y del servicio. Para obtener
más información, vea latencia.
Profundidad de la cola
La profundidad de la cola es el número de solicitudes de E/S pendientes que un

recurso de almacenamiento puede controlar en cualquier momento. Para obtener
más información, vea Profundidad de la cola.
Elección de un nivel de rendimiento basado en

patrones de uso
Azure Files proporciona una variedad de niveles de almacenamiento que ayudan a
reducir los costos al permitirle almacenar datos en el nivel adecuado de rendimiento y
precio. En el nivel más elevado, Azure Files ofrece dos niveles de rendimiento: Estándar y
Premium. Los recursos compartidos de archivos Estándar se hospedan en un sistema de
almacenamiento respaldado por unidades de disco duro (HDD), mientras que los
recursos compartidos de archivos Premium están respaldados por unidades de estado
sólido (SSD) para mejorar el rendimiento. Los recursos compartidos de archivos Estándar
tienen varios niveles de almacenamiento (optimizados para transacciones, frecuente y
esporádico) entre los que puede moverse sin problemas a fin de maximizar los datos en
reposo y los precios de transacción. Pero no puede moverse entre los niveles Estándar y
Premium sin migrar físicamente los datos entre diferentes cuentas de almacenamiento.
Al elegir entre recursos compartidos de archivos Estándar y Premium, es importante

comprender los requisitos del patrón de uso esperado que tiene previsto ejecutar en
Azure Files. Si necesita grandes cantidades de IOPS, velocidades de transferencia de
datos extremadamente rápidas o una latencia muy baja, debe elegir recursos
compartidos de archivos de Azure Premium.
En la tabla siguiente se resumen los objetivos de rendimiento esperados entre los

recursos Estándar y Premium. Para obtener más información, vea Objetivos de
escalabilidad y rendimiento de Azure Files.
Requisitos del patrón de uso Estándar Premium
Latencia de escritura (milisegundos de un solo dígito) Sí Sí
Latencia de lectura (milisegundos de un solo dígito) No Sí
Los recursos compartidos de archivos Premium ofrecen un modelo de

aprovisionamiento que garantiza el perfil de rendimiento siguiente en función del
tamaño del recurso compartido. Para obtener más información, vea Modelo
aprovisionado. Cada vez que el tráfico para el recurso compartido de archivos se
encuentra por debajo del valor de IOPS de la línea base, se acumulan créditos de ráfaga
en un cubo de ráfagas. Los créditos obtenidos se usan más adelante para habilitar la
expansión cuando las operaciones superen la IOPS de línea base.
Capacidad IOPS IOPS de Créditos de Rendimiento (entrada +

(GiB) base ráfaga ráfaga salida)
100 3100 Hasta 10 000 24 840 000 110 MiB/s
500 3500 Hasta 10 000 23 400 000 150 MiB/s
1024 4 024 Hasta 10 000 21 513 600 203 MiB/s
5120 8120 Hasta 15 360 26 064 000 613 MiB/s
10 240 13 240 Hasta 30 720 62 928 000 1125 MiB/s
33 792 36 792 Hasta 100 000 227 548 800 3480 MiB/s
51 200 54 200 Hasta 100 000 164 880 000 5220 MiB/s
102 400 100 000 Hasta 100 000 0 10 340 MiB/s
Azure Database for PostgreSQL: Lista de comprobación

de rendimiento
Si va a evaluar los requisitos de rendimiento de una carga de trabajo nueva o existente,
comprender los patrones de uso le permitirá lograr un rendimiento predecible. Consulte
con el administrador de almacenamiento o el desarrollador de aplicaciones para
determinar los patrones de uso siguientes.
Sensibilidad de latencia: ¿los usuarios abren archivos o interactúan con escritorios

virtuales que se ejecutan en Azure Files? Estos son ejemplos de cargas de trabajo
que son sensibles a la latencia de lectura y que también tienen alta visibilidad para
los usuarios finales. Estos tipos de cargas de trabajo son más adecuados para los
recursos compartidos de archivos Premium de Azure, que pueden proporcionar
una latencia de milisegundos para las operaciones de lectura y escritura (< 2 ms
para tamaño de E/S pequeño).
Requisitos de IOPS y rendimiento: los recursos compartidos de archivos Premium

admiten mayores límites de IOPS y rendimiento que los recursos compartidos de
archivos estándar. Consulte Destinos de escalado de recursos compartidos de
archivos para obtener más información.
Duración y frecuencia de la carga de trabajo: es menos probable que las cargas

de trabajo cortas (minutos) y poco frecuentes (por hora) logren los límites de
rendimiento superiores de los recursos compartidos de archivos Estándar en
comparación con las cargas de trabajo que se producen con frecuencia. En los
recursos compartidos de archivos Premium, la duración de la carga de trabajo es
útil al determinar el perfil de rendimiento correcto que se va a usar en función del
tamaño de aprovisionamiento. En función del tiempo que necesite expandirse la
carga de trabajo y el tiempo que tarda por debajo de las IOPS de línea base, puede
determinar si va a acumular suficientes créditos de ráfaga para satisfacer
constantemente la carga de trabajo en horas punta. La búsqueda del equilibrio
correcto reducirá los costos en comparación con el exceso de aprovisionamiento
del recurso compartido de archivos. Un error común consiste en ejecutar pruebas
de rendimiento solo unos minutos, lo que a menudo es engañoso. Para obtener
una vista realista del rendimiento, asegúrese de probar con una frecuencia y una
duración suficientemente altas.
Paralelización de cargas de trabajo: en el caso de las cargas de trabajo que

realizan operaciones en paralelo, como a través de varios subprocesos, procesos o
instancias de aplicación en el mismo cliente, los recursos compartidos de archivos
premium proporcionan una ventaja clara sobre los recursos compartidos de
archivos estándar: SMB multicanal. Consulte SMB multicanal para obtener más
información.
Distribución de operaciones de API: ¿los metadatos de la carga de trabajo son

pesados con las operaciones de apertura y cierre de archivos? Esto es habitual para
las cargas de trabajo que realizan operaciones de lectura en un número elevado de
archivos. Consulte Carga de trabajo pesada del espacio de nombres o los
metadatos.
Latencia
Al pensar en la latencia, es importante comprender primero cómo se determina esta con
Azure Files. Las medidas más comunes son la latencia asociada a las métricas de latencia
de un extremo a otro y latencia del servicio. El uso de estas métricas de transacción
puede ayudar a identificar problemas de latencia o de redes del lado cliente al
determinar el tiempo que pasa el tráfico de la aplicación en tránsito hacia el cliente y
desde este.
La latencia de un extremo a otro (SuccessE2ELatency) es el tiempo total que tarda

una transacción en realizar un recorrido de ida y vuelta completo desde el cliente,
por la red, al servicio Azure Files y de vuelta al cliente.
La latencia del servicio (SuccessServerLatency) es el tiempo que tarda una

transacción en realizar un recorrido de ida y vuelta solo dentro del servicio Azure
Files. Esto no incluye ninguna latencia de red o cliente.
La diferencia entre los valores de SuccessE2ELatency y SuccessServerLatency es la

latencia que probablemente provocan la red y el cliente.
Es habitual confundir la latencia del cliente con la latencia del servicio (en este caso, el
rendimiento de Azure Files). Por ejemplo, si la latencia del servicio notifica baja latencia y
la de un extremo a otro notifica una latencia muy alta para las solicitudes, eso sugiere
que todo el tiempo se invierte en el tránsito hacia el cliente y desde este, y no en el
servicio Azure Files.
Además, tal como se muestra en el diagrama, cuanto más lejos esté del servicio, más
lenta será la experiencia de latencia y más difícil será alcanzar límites de escalado de
rendimiento con cualquier servicio en la nube. Esto sucede especialmente al acceder a
Azure Files desde el entorno local. Aunque las opciones como ExpressRoute son ideales
para el entorno local, siguen sin coincidir con el rendimiento de una aplicación (proceso
y almacenamiento) que se ejecuta exclusivamente en la misma región de Azure.
 Sugerencia
El uso de una máquina virtual en Azure para probar el rendimiento entre el entorno
local y Azure es una manera eficaz y práctica de establecer como base las
capacidades de red de la conexión a Azure. A menudo, un circuito ExpressRoute o
una puerta de enlace de VPN con un tamaño insuficiente o incorrectamente
enrutado puede ralentizar una carga de trabajo.
Profundidad de la cola
La profundidad de la cola es el número de solicitudes de E/S pendientes que un recurso
de almacenamiento puede atender. A medida que los discos que usan los sistemas de
almacenamiento han evolucionado de los ejes HDD (IDE, SATA, SAS) a los dispositivos
de estado sólido (SSD, NVMe), también han evolucionado para admitir una mayor
profundidad de cola. Un ejemplo de profundidad de cola baja consiste en una carga de
trabajo que consta de un único cliente que interactúa en serie con un único archivo
dentro de un conjunto de datos grande. Por el contrario, una carga de trabajo que
admite paralelismo con varios subprocesos y varios archivos puede lograr fácilmente
una profundidad de cola alta. Dado que Azure Files es un servicio de archivos
distribuido que abarca miles de nodos de clúster de Azure y está diseñado para ejecutar
cargas de trabajo a gran escala, se recomienda compilar y probar cargas de trabajo con
una profundidad de cola alta.
La profundidad de cola alta se puede alcanzar de varias maneras diferentes en

combinación con clientes, archivos y subprocesos. Para determinar la profundidad de
cola de la carga de trabajo, multiplique el número de clientes por el número de archivos
y por el número de subprocesos (clientes * archivos * subprocesos = profundidad de
cola).
En la tabla siguiente se muestran las distintas combinaciones que puede usar para
lograr una mayor profundidad de cola. Aunque puede superar la profundidad de cola
óptima de 64, esta opción no se recomienda. Si lo hace, no observará más mejoras en el
rendimiento y corre el riesgo de aumentar la latencia debido a la saturación de TCP.
Clientes Archivos Subprocesos Profundidad de la cola
1 1 1 1
1 1 2 2
1 2 2 4
2 2 2 8
2 2 4 16
Clientes Archivos Subprocesos Profundidad de la cola
2 4 4 32
1 8 8 64
4 4 2 64
 Sugerencia
Para lograr límites de rendimiento superiores, asegúrese de que la carga de trabajo

o la prueba de punto de referencia sea de varios subprocesos con varios archivos.
Aplicaciones de un solo subproceso frente a

varios subprocesos
Azure Files es más adecuado para aplicaciones de varios subprocesos. La manera más
fácil de comprender el impacto en el rendimiento que tiene la opción de varios
subprocesos en una carga de trabajo es recorrer el escenario con E/S. En el ejemplo
siguiente, tenemos una carga de trabajo que necesita copiar 10 000 archivos pequeños
lo antes posible hacia un recurso compartido de archivos de Azure o desde este.
En esta tabla se desglosa el tiempo necesario (en milisegundos) para crear un único
archivo de 16 KiB en un recurso compartido de archivos de Azure, basado en una
aplicación de un solo subproceso que escribe en tamaños de bloque de 4 KiB.
Operación de Crear Escritura de Escritura de Escritura de Escritura de Close Total

E/S 4 KiB 4 KiB 4 KiB 4 KiB
Subproceso 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
En este ejemplo, tardaría aproximadamente 14 ms en crear un único archivo de 16 KiB a

partir de las seis operaciones. Si una aplicación de un solo subproceso quiere mover
10 000 archivos a un recurso compartido de archivos de Azure, esto supondría
140 000 ms (14 ms * 10 000) o 140 segundos, porque cada archivo se mueve
secuencialmente de uno en uno. Tenga en cuenta que el tiempo de servicio de cada
solicitud lo determina principalmente la proximidad entre el proceso y el
almacenamiento, tal como se describe en la sección anterior.
Al usar ocho subprocesos en lugar de uno, la carga de trabajo anterior se puede reducir
de 140 000 ms (140 segundos) hasta 17 500 ms (17,5 segundos). Tal como se muestra
en la tabla siguiente, cuando se mueven ocho archivos en paralelo en lugar de hacerlo
de uno en uno, puede mover la misma cantidad de datos empleando un 87,5 % menos
de tiempo.
Operación de Crear Escritura de Escritura de Escritura de Escritura de Close Total

E/S 4 KiB 4 KiB 4 KiB 4 KiB
Vea también
Solución de problemas de rendimiento de recursos compartidos de archivos de
Azure
Supervisión de Azure Files
Descripción de la facturación de Azure Files
Precios de Azure Files
Mejora del rendimiento del recurso compartido
de archivos de Azure SMB
Artículo • 03/09/2023
En este artículo se explica cómo puede mejorar el rendimiento de los recursos compartidos de archivos de
Azure SMB, incluido el uso de SMB multicanal.
Se aplica a
Optimización del rendimiento

Las siguientes sugerencias pueden ayudarte a optimizar el rendimiento:
Asegúrese de que la cuenta de almacenamiento y el cliente se colocan en la misma región de Azure

para reducir la latencia de red.
Use aplicaciones multiproceso y distribuya la carga entre varios archivos.
Las ventajas de rendimiento de SMB multicanal aumentan con el número de archivos que distribuyen la
carga.
El rendimiento del recurso compartido Premium está limitado por el tamaño del recurso compartido
aprovisionado (IOPS/salida/entrada) y los límites de un solo archivo. Para obtener detalles, consulte
Descripción del aprovisionamiento de recursos compartidos de archivos Premium.
El rendimiento máximo de un solo cliente de VM sigue estando enlazado a los límites de máquina
virtual. Por ejemplo, Standard_D32s_v3 puede admitir un ancho de banda máximo de 16 000 MBps (o
2 GBps), la salida de la máquina virtual (escrituras en el almacenamiento) se mide, la entrada (lecturas
del almacenamiento) no. El rendimiento de los recursos compartidos de archivos está sujeto a los
límites de red de la máquina, las CPU, el almacenamiento interno, el ancho de banda de red disponible,
los tamaños de E/S, el paralelismo, así como otros factores.
La prueba inicial suele ser una preparación. Descarte los resultados y repita la prueba.
Si el rendimiento está limitado por un solo cliente y la carga de trabajo sigue estando por debajo de los
límites de cuota provisionados, puede conseguir un mayor rendimiento repartiendo la carga entre
varios clientes.
La relación entre IOPS, el rendimiento y los tamaños de E/S

Rendimiento = tamaño de E/S * IOPS
Cuanto mayor sea el tamaños de E/S mayores serán el rendimiento y las latencias, lo que dará lugar a un
número menor de IOPS de red. Los tamaños de E/S menores aumentarán la IOPS, pero provocarán unas
latencias y un rendimiento menores. Para más información, consulte Descripción del rendimiento de Azure
Files.
SMB multicanal
SMB multicanal permite que un cliente SMB 3.x establezca varias conexiones de red a un recurso compartido
de archivos SMB. Azure Files admite SMB multicanal en recursos compartidos de archivos premium (recursos
compartidos de archivos en el tipo de cuenta de almacenamiento FileStorage) para clientes de Windows. En
el lado del servicio, el SMB multicanal está deshabilitado de forma predeterminada en Azure Files, pero no
hay ningún costo adicional por habilitarlo.
Ventajas
SMB multicanal permite a los clientes usar varias conexiones de red que proporcionan un mayor rendimiento
a la vez que se reduce el costo de propiedad. El mayor rendimiento se logra a través de la agregación de
ancho de banda en varias NIC y el uso de la compatibilidad con Ajuste de escala en lado de recepción (RSS)
para que las NIC distribuyan la carga de E/S entre varias CPU.
Rendimiento aumentado: varias conexiones permiten la transferencia de los datos a través de varias
rutas de acceso en paralelo y, por tanto, benefician significativamente a las cargas de trabajo que usan
tamaños de archivo más grandes con tamaños de E/S más grandes, y requieren un alto rendimiento de
una sola máquina virtual o un conjunto de máquinas virtuales más pequeño. Entre algunas de estas
cargas de trabajo se incluyen medios y entretenimiento para la creación de contenido o la
transcodificación, la genómica y el análisis de riesgos de servicios financieros.
E/S por segundo más alta: la funcionalidad RSS de NIC permite una distribución de carga eficaz entre
varias CPU con varias conexiones. Esto ayuda a lograr una escala de IOPS más alta y un uso eficaz de las
CPU de VM. Esto es útil para las cargas de trabajo que tienen tamaños de E/S pequeños, como las
aplicaciones de base de datos.
Tolerancia a los fallos de la red: varias conexiones mitigan el riesgo de interrupción, ya que los clientes
ya no dependen de una conexión individual.
Configuración automática: cuando SMB multicanal está habilitado en los clientes y las cuentas de
almacenamiento, permite la detección dinámica de las conexiones existentes y puede crear rutas de
acceso de conexión adicionales según sea necesario.
Optimización de costos: las cargas de trabajo pueden alcanzar una mayor escala de una sola máquina
virtual o un conjunto pequeño de máquinas virtuales mientras se conectan a recursos compartidos
Premium. Esto podría reducir el costo total de propiedad al reducir el número de máquinas virtuales
necesarias para ejecutar y administrar una carga de trabajo.
Para obtener más información sobre SMB multicanal, consulte la documentación de Windows.
Esta característica proporciona mayores ventajas de rendimiento a las aplicaciones multiproceso, pero
normalmente no ayuda a las aplicaciones de un único subproceso. Consulte la sección Comparación del
rendimiento para obtener más detalles.
Limitaciones
SMB multicanal para los recursos compartido de archivos de Azure tiene actualmente las siguientes
restricciones:
Solo se admite en clientes de Windows que utilizan SMB 3.1.1. Asegúrese de que los sistemas
operativos cliente de SMB tengan las revisiones aplicadas hasta los niveles recomendados.
Actualmente no se admite ni se recomienda para los clientes de Linux.
El número máximo de canales es cuatro. Para más información, consulte este artículo.
Configuración
SMB multicanal solo funciona cuando la característica está habilitada tanto en el lado del cliente (su cliente)
como en el lado del servicio (su cuenta de almacenamiento de Azure).
En los clientes Windows, SMB multicanal está habilitado de manera predeterminada. Puede comprobar la
configuración ejecutando el siguiente comando de PowerShell:
PowerShell
Get-SmbClientConfiguration | Select-Object -Property EnableMultichannel
En la cuenta de almacenamiento de Azure, deberás habilitar SMB multicanal. Consulte Implementación de

SMB multicanal.
Deshabilitar SMB multicanal

En la mayoría de los escenarios, concretamente las cargas de trabajo multiproceso, los clientes deben ver un
rendimiento mejorado con SMB multicanal. Sin embargo, algunos escenarios específicos, como las cargas de
trabajo con un único subproceso o con fines de prueba, es posible que desee deshabilitar el SMB multicanal.
Consulte Comparación del rendimiento para obtener más detalles.
Comprobar que SMB multicanal está configurado correctamente

1. Crea un nuevo recurso compartido de archivos premium o use uno premium existente.
2. Asegúrese de que el cliente admite SMB multicanal (uno o varios adaptadores de red tienen habilitado
el ajuste de escala en lado de recepción). Consulte la documentación de Windows para obtener más
detalles.
3. Monte un recurso compartido de archivos en el cliente.
4. Genere carga con la aplicación. Una herramienta de copia como robocopy o MT, o bien cualquier
herramienta de rendimiento como Deskspd para archivos de lectura/escritura, pueden generar carga.
5. Abra PowerShell como administrador y use el siguiente comando: Get-SmbMultichannelConnection |fl
6. Busque las propiedades MaxChannels y CurrentChannels.
Comparación del rendimiento

Hay dos categorías de patrones de carga de trabajo de lectura/escritura: de un único subproceso y
multiproceso. La mayoría de las cargas de trabajo usan varios archivos, pero podría haber casos de uso
específicos en los que la carga de trabajo funcione con un solo archivo en un recurso compartido. En esta
sección se tratan diversos casos de uso y el impacto en el rendimiento de cada uno de ellos. En general, la
mayoría de las cargas de trabajo son multiproceso y distribuyen la carga de trabajo por varios archivos, por
lo que deberían poder observar mejoras significativas en el rendimiento con SMB multicanal.
Varios archivos/Multiproceso: según el patrón de carga de trabajo, deberías poder observar una
mejora significativa en el rendimiento en E/S de lectura y escritura a través de varios canales. Las
mejoras de rendimiento varían desde cualquier punto entre 2x y 4x en términos de IOPS, rendimiento y
latencia. En esta categoría, SMB multicanal debe habilitarse para obtener el mejor rendimiento.
Un solo archivo/Multiproceso: en la mayoría de los casos de uso de esta categoría, las cargas de
trabajo se beneficiarán de tener habilitado SMB multicanal, especialmente si la carga de trabajo tiene
un tamaño medio de E/S > ~16 k. Algunos escenarios de ejemplo que se benefician de SMB multicanal
son la copia de seguridad o la recuperación de un solo archivo grande. Una excepción en la que es
posible que desees deshabilitar SMB multicanal es si tu carga de trabajo es pesada en E/S pequeñas. En
ese caso, tal vez observes una ligera pérdida de rendimiento (10 %). Dependiendo del caso de uso,
considere la posibilidad de distribuir la carga entre varios archivos o deshabilitar la característica.
Consulte la sección Configuración para obtener más información.
Varios archivos o un solo archivo/Multiproceso: en la mayoría de las cargas de trabajo de un único
subproceso, existen unas ventajas de rendimiento mínimas debido a la falta de paralelismo. Por lo
general, hay una ligera degradación del rendimiento de ~10 % si el SMB multicanal está habilitado. En
este caso, es ideal deshabilitar SMB multicanal, con una excepción. Si la carga de trabajo de un único
subproceso puede distribuir la carga entre varios archivos y usa un tamaño medio de E/S más grande
(> ~16 k), deben existir unas ventajas de rendimiento mínimas del SMB multicanal.
Configuración de prueba de rendimiento

En los gráficos de este artículo, se usó la siguiente configuración: una sola máquina virtual D32s v3 Estándar
con una sola NIC habilitada para RSS con cuatro canales. La carga se generó mediante diskspd.exe,
multiproceso con una profundidad de E/S de 10 y E/S aleatorias con diversos tamaños de E/S.
Size vCPU Memoria: GiB de Discos Rendimiento Rendimiento Nº Ancho

GiB almacenamiento de máximo de máximo del máx. de
temporal (SSD) datos almacenamiento disco sin NIC banda
máx. temporal y en almacenamiento de red
caché: en la caché: esperado
IOPS/Mbps IOPS/Mbps (Mbps)
(tamaño de
caché en GiB)
Standard_D32s_v3 32 128 256 32 64000/512 (800) 51200/768 8 16000
Multihilo/múltiples archivos con SMB Multicanal

La carga se realizó con respecto a 10 archivos con diversos tamaños de E/S. Los resultados de la prueba de
escalado vertical mostraron mejoras significativas en los resultados de la prueba de rendimiento e IOPS con
SMB multicanal habilitado. En los diagramas siguientes se describen los resultados:

En una sola NIC, en el caso de las lecturas, el rendimiento aumentó entre el doble y el triple, mientras
que en el caso de las escrituras, una mejora en términos de IOPS y rendimiento se multiplicó por 3 y
hasta por 4.
SMB multicanal permitió que IOPS y el rendimiento alcanzaran los límites de VM incluso con una sola
NIC y el límite de cuatro canales.
Dado que la salida (o las lecturas en el almacenamiento) no se mide, el rendimiento de lectura pudo
superar el límite publicado de VM de 16 000 Mbps (2 GiB/s). La prueba alcanzó >2,7 GiB/s. La entrada
(o las escrituras en el almacenamiento) sigue estando sujeta a límites de VM.
Distribución de la carga por varios archivos permitidos para mejoras sustanciales.
Un comando de ejemplo utilizado en esta prueba es:
diskspd.exe -W300 -C5 -r -w100 -b4k -t8 -o8 -Sh -d60 -L -c2G -Z1G z:\write0.dat z:\write1.dat
z:\write2.dat z:\write3.dat z:\write4.dat z:\write5.dat z:\write6.dat z:\write7.dat z:\write8.dat

z:\write9.dat .
Cargas de trabajo multiproceso o de un solo archivo con SMB

multicanal
La carga se realizó con respecto a un solo archivo de 128 GiB. Con SMB multicanal habilitado, la prueba de
escalado vertical con archivos multiproceso o únicos mostró mejoras en la mayoría de los casos. En los
diagramas siguientes se describen los resultados:

En una sola NIC con un tamaño medio de E/S mayor (> ~16 k), había mejoras significativas tanto en las
lecturas como en las escrituras.
Para tamaños de E/S más pequeños, hubo un ligero impacto de ~10 % en el rendimiento con el SMB
multicanal habilitado. Esto podría mitigarse mediante la distribución de la carga por varios archivos, o
la deshabilitación de la característica.
El rendimiento sigue estando sujeto a los límites de un solo archivo.
Pasos siguientes
Habilitar SMB multicanal
Consulta la documentación de Windows para el SMB multicanal
Mejora del rendimiento del recurso
compartido de archivos NFS de Azure
Artículo • 26/10/2023
En este artículo se explica cómo puede mejorar el rendimiento de los archivos

compartidos de NFS de Azure.
Se aplica a
Aumento del tamaño de la lectura anticipada

para mejorar el rendimiento de lectura
El parámetro del kernel read_ahead_kb en Linux representa la cantidad de datos que
deben "leerse de forma anticipada" o capturarse previamente durante una operación de
lectura secuencial. Las versiones del kernel de Linux anteriores a la versión 5.4
establecen el valor de la lectura anticipada en el equivalente de 15 veces el valor de
rsize del sistema de archivos montado (la opción de montaje del lado cliente para el
tamaño del búfer de lectura). Esto establece el valor de lectura anticipada lo

suficientemente alto como para mejorar el rendimiento de lectura secuencial del cliente
en la mayoría de los casos.
Sin embargo, a partir de la versión 5.4 del kernel de Linux, el cliente NFS de Linux usa un
valor predeterminado de read_ahead_kb de 128 KiB. Este valor pequeño puede reducir la
cantidad de rendimiento de lectura para archivos grandes. Los clientes que actualizan
desde versiones de Linux con un mayor valor de lectura anticipada en comparación con
los que tienen el valor predeterminado de 128 KiB podrían experimentar una
disminución en el rendimiento de lectura secuencial.
En el caso de los kernels de Linux 5.4 o posteriores, se recomienda establecer de forma

persistente el valor de read_ahead_kb en 15 MiB para mejorar el rendimiento.
Para cambiar este valor, establezca el tamaño de lectura anticipada agregando una regla
en udev, un administrador de dispositivos del kernel de Linux. Siga estos pasos:
1. En un editor de texto, cree el archivo /etc/udev/rules.d/99-nfs.rules escribiendo y

guardando el texto siguiente:
Resultados
SUBSYSTEM=="bdi" \
, ACTION=="add" \
, PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi)
{ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
, ATTR{read_ahead_kb}="15360"
2. En una consola, aplique la regla udev ejecutando el comando udevadm como

superusuario y vuelva a cargar los archivos de reglas y otras bases de datos. Solo
tiene que ejecutar este comando una vez para que udev sea consciente del nuevo
archivo.
Bash
sudo udevadm control --reload
Nconnect
Nconnect es una opción de montaje de Linux del lado cliente que aumenta el
rendimiento a escala al permitirle usar más conexiones TCP entre el cliente y el servicio
Azure Premium Files para NFSv4.1, a la vez que mantiene la resistencia de la plataforma
como servicio (PaaS).
Ventajas de nconnect
Con nconnect , puede aumentar el rendimiento a escala mediante menos máquinas
cliente para reducir el costo total de propiedad (TCO). Nconnect aumenta el rendimiento
mediante el uso de varios canales TCP en una o varias NIC, mediante uno o varios
clientes. Sin nconnect , necesitaría aproximadamente 20 máquinas cliente para lograr los
límites de escala de ancho de banda (10 GiB/s) ofrecidos por el mayor tamaño de
aprovisionamiento de recursos compartidos de archivos premium de Azure. Con
nconnect , puede lograr esos límites usando solo de 6 a 7 clientes. Esa es casi una
reducción del 70 % en el costo informático, al tiempo que proporciona mejoras

significativas en la IOPS y el rendimiento a escala (consulte la tabla).
Métrica (operación) Tamaño de E/S Mejora del rendimiento
IOPS (escritura) 64K, 1024K 3x
IOPS (lectura) Todos los tamaños de E/S 2-4x
Rendimiento (escritura) 64K, 1024K 3x
Rendimiento (lectura) Todos los tamaños de E/S 2-4x
Requisitos previos
Las distribuciones de Linux más recientes son totalmente compatibles con
nconnect . En el caso de las distribuciones anteriores de Linux, asegúrese de que la
versión del kernel de Linux es 5.3 o posterior.

La configuración por montaje solo se admite cuando se usa un único recurso
compartido de archivos por cuenta de almacenamiento a través de un punto de
conexión privado.
Impacto en el rendimiento de nconnect

Hemos logrado los siguientes resultados de rendimiento al usar la nconnect opción de
montaje con recursos compartidos de archivos NFS de Azure en clientes Linux a gran
escala. Para obtener más información sobre cómo logramos estos resultados, consulte
Configuración de pruebas de rendimiento.
Recomendaciones para nconnect
Siga estas recomendaciones para obtener los mejores resultados de nconnect .
Establezca nconnect=4 .
Aunque Azure Files admite la configuración nconnect hasta el máximo de 16, se

recomienda configurar las opciones de montaje con el valor óptimo de nconnect=4 .
Actualmente, no hay ganancias más allá de cuatro canales para la implementación de
Azure Files de nconnect . De hecho, superar cuatro canales en un único recurso
compartido de archivos de Azure de un solo cliente podría afectar negativamente al
rendimiento debido a la saturación de la red TCP.
Ajustar el tamaño de las máquinas virtuales cuidadosamente
En función de los requisitos de la carga de trabajo, es importante ajustar correctamente

el tamaño de las máquinas cliente para evitar que se vean limitados por el ancho de
banda de red esperado. No necesita varias NIC para lograr el rendimiento de red
esperado. Aunque es habitual usar máquinas virtuales de uso general con Azure Files,
hay varios tipos de máquinas virtuales disponibles en función de las necesidades de la
carga de trabajo y la disponibilidad de las regiones. Para más información, consulte
Selector de máquinas virtuales de Azure .
Mantener la profundidad de la cola menor o igual que 64

La profundidad de la cola es el número de solicitudes de E/S pendientes que un recurso
de almacenamiento puede atender. No se recomienda superar la profundidad óptima
de la cola de 64. Si lo hace, no verá más mejoras de rendimiento. Para obtener más
información, vea Profundidad de la cola.
Nconnect configuración por montaje
Si una carga de trabajo requiere montar varios recursos compartidos con una o varias
cuentas de almacenamiento con una configuración de nconnect diferente de un solo
cliente, no podemos garantizar que esa configuración persista al montarse a través del
punto de conexión público. La configuración por montaje solo se admite cuando se usa
un único recurso compartido de archivos de Azure por cuenta de almacenamiento a
través del punto de conexión privado, como se describe en Escenario 1.
Escenario 1: configuración de nconnect por montaje (compatible) a

través de un punto de conexión privado con varias cuentas de
almacenamiento
StorageAccount.file.core.windows.net = 10.10.10.10
StorageAccount2.file.core.windows.net = 10.10.10.11
Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1
nconnect=4
Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1
Escenario 2: configuración de nconnect por montaje (no

compatible) a través del punto de conexión público
StorageAccount2.file.core.windows.net = 52.239.238.7
nconnect=4
Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1
７ Nota
Incluso si la cuenta de almacenamiento se resuelve en una dirección IP diferente,

no podemos garantizar que la dirección persistirá porque los puntos de conexión
públicos no son direcciones estáticas.
Escenario 3: configuración de nconnect por montaje (no

compatible) a través de un punto de conexión privado con varios
recursos compartidos de archivos en una cuenta de
almacenamiento
nconnect=4
Configuración de prueba de rendimiento

Usamos los siguientes recursos y herramientas de pruebas comparativas para lograr y
medir los resultados descritos en este artículo.
Cliente único: Máquina virtual de Azure (serie DSv4) con una sola NIC
Sistema operativo: Linux (Ubuntu 20.40)
Almacenamiento NFS: Recurso compartido de archivos premium de Azure Files
(aprovisionado 30 TiB, configurado nconnect=4 )
Tamaño vCPU Memoria Almacenamiento Discos Nº Ancho de

temporal (SSD) de datos máx. banda de red
máx. NIC esperado
Standard_D16_v4 16 64 GiB Solo 32 8 12 500 Mbps

almacenamiento
remoto
Pruebas y herramientas de pruebas comparativas

Usamos Flexible I/O Tester (FIO), una herramienta de E/S de disco libre y de código
abierto que se usa tanto para pruebas comparativas como para comprobación del
esfuerzo y el hardware. Para instalar FIO, siga la sección Paquetes binarios que aparece
en el archivo README de FIO para instalar la versión correspondiente a la plataforma
que prefiera.
Aunque estas pruebas se centran en patrones de acceso de E/S aleatorios, obtendrá

resultados similares al usar E/S secuencial.
IOPS elevadas: lecturas del 100 %
Tamaño de E/S de 4 k - lectura aleatoria - profundidad de 64 colas
Bash
fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --

time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --
group_reporting --ramp_time=300
Bash

Alto rendimiento: 100 % de lecturas

Bash

Tamaño de E/S de 1024 k - 100 % de lectura aleatoria - profundidad de 64 colas
Bash

IOPS elevadas: 100 % de escrituras
Tamaño de E/S de 4 k - 100 % de escritura aleatoria - profundidad de 64 colas
Bash

time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --
Bash

Alto rendimiento: 100 % de escrituras

Bash

Bash

Consideraciones de rendimiento para nconnect

Al usar la opción de montaje de nconnect , debe evaluar detenidamente las cargas de
trabajo que tienen las siguientes características:
Cargas de trabajo de escritura sensibles a la latencia que son un único subproceso

o usan una profundidad de cola baja (menos de 16)
Cargas de trabajo de lectura confidenciales de latencia que son un único
subproceso o usan una profundidad de cola baja en combinación con tamaños de
E/S más pequeños
No todas las cargas de trabajo requieren rendimiento de alta escala en todo el sistema o
de IOPS. En el caso de cargas de trabajo de escala más pequeñas, es posible que no
tenga sentido usar nconnect . Use la tabla siguiente para decidir si nconnect será
ventajoso para la carga de trabajo. Se recomiendan escenarios resaltados en verde,
mientras que los resaltados en rojo no. Los resaltados en amarillo son neutros.
Consulte también
Para obtener instrucciones de montaje, consulte Montaje del recurso compartido
de archivos NFS en Linux.
Para obtener una lista completa de las opciones de montaje, consulte página man
de NFS de Linux .
Para obtener información sobre la latencia, las IOPS, el rendimiento y otros
conceptos de rendimiento, consulte Descripción del rendimiento de Azure Files.
Objetivos de escalabilidad y
rendimiento de Azure Files
Artículo • 06/04/2023
Azure Files ofrece recursos compartidos de archivos en la nube totalmente

administrados a los que se puede acceder mediante los protocolos SMB y del sistema
de archivos NFS. En este artículo se explican los objetivos de escalabilidad y rendimiento
de Azure Files y Azure File Sync.
Los objetivos enumerados aquí pueden verse afectados por otras variables de la
implementación. Por ejemplo, el rendimiento de E/S de un archivo puede verse afectado
tanto por el comportamiento del cliente SMB como por el ancho de banda de red
disponible. Debe probar el patrón de uso para determinar si la escalabilidad y el
rendimiento de Azure Files cumplen sus requisitos. También debería esperar que estos
límites aumenten con el tiempo.
Se aplica a
Objetivos de escalabilidad de Azure Files

implementar varios recursos compartidos de archivos. Por tanto, existen tres categorías
que se deben tener en cuenta: cuentas de almacenamiento, recursos compartidos de
archivo de Azure y archivos individuales.
Objetivos de escalabilidad de la cuenta de

almacenamiento
Los objetivos de escalabilidad de la cuenta de almacenamiento se aplican en el nivel de
cuenta de almacenamiento. Hay dos tipos principales de cuentas de almacenamiento
para Azure Files:

como contenedores de blobs, colas o tablas. Los recursos compartidos de archivos
se pueden implementar en los niveles de transacción optimizada (valor
predeterminado), acceso frecuente o acceso esporádico.

(contenedores de blobs, colas, tablas, etc.) en una cuenta FileStorage.
Atributo Cuentas de Cuentas de almacenamiento

almacenamiento GPv2 FileStorage (prémium)
(estándar)
Número de cuentas de 2501 2501

almacenamiento por
suscripción y región
Capacidad máxima de la cuenta 5 PiB2 100 TiB (aprovisionados)

de almacenamiento
Número máximo de recursos Sin límite Sin límite, el tamaño total

compartidos de archivos aprovisionado de todos los recursos
compartidos debe ser inferior al
máximo que la capacidad máxima de
la cuenta de almacenamiento.
Velocidad máxima de 20 000 IOPS2 100 000 IOPS

solicitudes simultáneas
(estándar)
Rendimiento (entrada + salida) Entrada: 10,340 MiB/s

para LRS/GRS 7,152 MiB/s
Salida:
Este de Australia 14,305 MiB/s
Centro de EE. UU.
Este de Asia
Este de EE. UU. 2
Japón Oriental
Centro de Corea del Sur
Norte de Europa
Sudeste de Asia
Sur de Reino Unido 2
Oeste de Europa
Oeste de EE. UU.

para ZRS 7,152 MiB/s
Salida:
Este de Australia 14,305 MiB/s
Centro de EE. UU.
Este de EE. UU.
Este de EE. UU. 2
Japón Oriental
Norte de Europa
Sudeste de Asia
Sur de Reino Unido 2
Oeste de Europa
Oeste de EE. UU. 2

para combinaciones de 2,980 MiB/s
redundancia y región no Salida:
enumeradas en la fila anterior 5,960 MiB/s
Número máximo de reglas de 200 200

red virtual
Número máximo de reglas de 200 200

dirección IP
Operaciones de lectura de 800 por cada 5 minutos 800 por cada 5 minutos
administración
(estándar)
Operaciones de escritura de 10 por segundo/1200 10 por segundo/1200 por hora

administración por hora
Operaciones de lista de 100 por cada 5 minutos 100 por cada 5 minutos
administración
1
Con un aumento de cuota, puede crear hasta 500 cuentas de almacenamiento con
puntos de conexión estándar por región. Para más información, consulte Aumento de
las cuotas de la cuenta de Azure Storage. 2 Las cuentas de almacenamiento de uso
general, versión 2, admiten límites más altos de capacidad y límites más altos de entrada
por solicitud. Para solicitar un aumento en los límites de cuenta, póngase en contacto
con el soporte técnico de Azure .
Objetivos de escala de recursos compartidos de archivos

de Azure
Los objetivos de escalabilidad de los recursos compartidos de archivos de Azure se
aplican en el nivel de recurso compartido de archivos.
Atributo Recursos compartidos de Recursos compartidos

archivos estándar1 de archivos Prémium
Tamaño máximo de un recurso Sin mínimo 100 GiB

compartido de archivos (aprovisionados)
Unidad de aumento/reducción de N/D 1 GiB

tamaño aprovisionada
Tamaño máximo de un recurso 100 TiB, con la 100 TiB

compartido de archivos característica de
recurso compartido de
archivos grande
habilitada2
5 TiB, valor
predeterminado
Número máximo de archivos en un Sin límite Sin límite

Atributo Recursos compartidos de Recursos compartidos
archivos estándar1 de archivos Prémium
Velocidad máxima de solicitud (IOPS 20 000, con la IOPS de línea

máx.) característica de base: 3000 +
recurso compartido de 1 IOPS por GiB,
archivos grandes hasta 100 000
habilitada2 Expansión de
1000 o 100 solicitudes IOPS: Máximo
por 100 ms, valor (10 000, 3x IOPS
predeterminado por GiB), hasta
100 000
Rendimiento (entrada y salida) de un Hasta los límites de la 100 + CEILING (0,04 *

único recurso compartido de archivos cuenta de ProvisionedStorageGiB)
(MiB/seg) almacenamiento, con la + CEILING (0,06 *
característica de ProvisionedStorageGiB)
archivos de gran
tamaño habilitada2
Hasta 60 MiB/s, valor
predeterminado
Número máximo de instantáneas de 200 instantáneas 200 instantáneas

recurso compartido
La longitud máxima del nombre de 2048 caracteres 2048 caracteres

3
objeto (nombre de ruta de acceso
completo que incluye todos los
directorios, los nombres de archivo y
caracteres de barra diagonal inversa)
La longitud máxima del componente 255 caracteres 255 caracteres

nombre de ruta de acceso individual3
(en la ruta de acceso \A\B\C\D, cada
letra representa un directorio o archivo
que constituye un componente
individual)
Límite de vínculo físico (solo NFS) N/D 178
Número máximo de canales de SMB N/D 4

multicanal
Número máximo de directivas de 5 5

acceso almacenadas por recurso
compartido de archivos
1
Los límites de los recursos compartidos de archivos estándar se aplican a los tres
niveles disponibles para dichos recursos: optimizado para transacciones, acceso
frecuente y acceso esporádico.
2 El valor predeterminado de los recursos compartidos de archivos estándar es 5 TiB;

consulte Creación de un recurso compartido de archivos de Azure para obtener más
información sobre cómo crear recursos compartidos de archivos con un tamaño de
100 TiB y aumentar los recursos compartidos de archivos estándar existentes hasta
100 TiB. Para aprovechar las ventajas de los destinos de mayor escala, debe cambiar la
cuota para que sea mayor que 5 TiB.
3
Azure Files aplica ciertas reglas de nomenclatura para los nombres de los directorios y
archivos.
Objetivos de escalabilidad de archivos

Los objetivos de escalabilidad de los archivos se aplican a los archivos individuales
almacenados en los recursos compartidos de archivos de Azure.
Atributo Archivos en recursos Archivos en recursos

compartidos de archivos compartidos de archivos
estándar prémium
Tamaño de archivo máximo 4 TiB 4 TiB
Velocidad máxima de solicitudes 1000 IOPS Hasta 80001

simultáneas
Entrada máxima de un archivo 60 MiB/s 200 MiB/s (hasta 1 GiB/s con

SMB multicanal)2
Salida máxima de un archivo 60 MiB/s 300 MiB/s (hasta 1 GiB/s con

SMB multicanal)2
Número máximo de identificadores 10 000 identificadores 10 000 identificadores

simultáneos para el directorio raíz3
Número máximo de identificadores 2000 identificadores 2000 identificadores

simultáneos por archivo y
directorio3
1 Se aplica a entradas y salidas de lectura y escritura (normalmente los tamaños de E/S son iguales o menores que
64 KiB). Las operaciones de metadatos, que no sean lecturas y escrituras, pueden ser más lentas. Estos límites son
flexibles y la limitación puede producirse más allá de estos límites.

2 En función de los límites de red de la máquina, el ancho de banda disponible, los tamaños de E/S, la profundidad de
la cola y otros factores. Para más información, consulte Rendimiento multicanal de SMB.
3 Azure Files admite 10 000 identificadores abiertos en el directorio raíz y 2000 identificadores abiertos por archivo y
directorio dentro del recurso compartido. El número de usuarios activos admitidos por recurso compartido depende
de las aplicaciones que acceden al recurso compartido. Si las aplicaciones no abren un identificador en el directorio
raíz, Azure Files puede admitir más de 10 000 usuarios activos por recurso compartido.
Objetivos de escalabilidad de Azure File Sync

En la tabla siguiente, se indica qué destinos son flexibles, que representan el límite
probado por Microsoft, y qué destinos son rígidos, lo que indica un máximo obligatorio:
Recurso Destino Límite

máximo
Servicios de sincronización 100 servicios de sincronización de Storage Sí

de almacenamiento por
región
Grupos de sincronización 200 grupos de sincronización Sí

por servicio de
sincronización de
almacenamiento
Servidores registrados por 99 servidores Sí

servicio de sincronización
de almacenamiento
Puntos de conexión en la 1 punto de conexión en la nube Sí

nube por grupo de
sincronización
Puntos de conexión del 100 puntos de conexión de servidor Sí

servidor por grupo de
sincronización
Puntos de conexión del 30 puntos de conexión de servidor Sí

servidor por servidor
Objetos del sistema de 100 millones de objetos No

archivos (archivos y
directorios) por grupo de
sincronización
Recurso Destino Límite
máximo
Número máximo de 5 millones de objetos Sí

objetos del sistema de
archivos (directorios y
archivos) en un directorio
(no recursivo)
Tamaño máximo del 64 KiB Sí

descriptor de seguridad de
(archivos y directorios) del
objeto
Tamaño de archivo 100 GiB No
Tamaño mínimo de un basado en el tamaño del clúster del sistema de archivos Sí

archivo que se va a (tamaño del clúster del sistema de archivos doble). Por
organizar en niveles ejemplo, si el tamaño del clúster del sistema de archivos
es 4 KiB, el tamaño mínimo del archivo será de 8 KiB.
７ Nota
Un punto de conexión de Azure File Sync puede escalar verticalmente hasta el

tamaño de un recurso compartido de archivos de Azure. Si se alcanza el límite de
tamaño de recurso compartido de archivos de Azure, la sincronización no podrá
funcionar.
Métricas de rendimiento de Azure File Sync

Dado que el agente de Azure File Sync se ejecuta en una máquina con Windows Server
que se conecta a los recursos compartidos de archivos de Azure, el rendimiento de
sincronización efectivo depende de una serie de factores de su infraestructura: Windows
Server y la configuración del disco subyacente, el ancho de banda de la red entre el
servidor y Azure Storage, el tamaño del archivo, el tamaño total del conjunto de datos y
la actividad en el conjunto de datos. Dado que Azure File Sync funciona en el nivel de
archivo, las características de rendimiento de una solución basada en Azure File Sync se
debe medir según el número de objetos (archivos y directorios) que se procesan por
segundo.
En el caso de Azure File Sync, el rendimiento es fundamental en dos fases:
1. Aprovisionamiento inicial que se realiza una sola vez: para optimizar el

rendimiento del aprovisionamiento inicial, consulte Incorporación con Azure File
Sync, donde obtendrá los detalles de una implementación óptima.
2. Sincronización en curso: después de que los datos se inicializan en los recursos
compartidos de archivos de Azure, Azure File Sync mantiene varios puntos de
conexión sincronizados.
７ Nota
Cuando muchos puntos de conexión de servidor del mismo grupo de

sincronización se están sincronizando al mismo tiempo, compiten por los recursos
del servicio en la nube. Como resultado, el rendimiento de la carga se ve afectado.
En casos extremos, algunas sesiones de sincronización no podrán acceder a los
recursos y se producirá un error. Sin embargo, esas sesiones de sincronización se
reanudarán en breve y finalmente se realizarán correctamente una vez que se
reduzca la congestión.
Resultados de las pruebas internas

Para ayudarle a planear la implementación de cada una de las fases (aprovisionamiento
inicial de una sola vez y sincronización continua), a continuación encontrará los
resultados observados durante las pruebas internas en un sistema con la siguiente
configuración:
Configuración del sistema Detalles
CPU 64 núcleos virtuales con una memoria caché L3 de 64 MiB
Memoria 128 GB
Disco Discos SAS con RAID 10 con caché con respaldo de batería
Red Red de 1 Gbps
Carga de trabajo Servidor de archivos de uso general
Aprovisionamiento inicial que se realiza una sola vez
Aprovisionamiento inicial que se realiza una Detalles

sola vez
Número de objetos 25 millones de objetos
Tamaño del conjunto de datos ~4,7 TiB

Aprovisionamiento inicial que se realiza una Detalles
sola vez
Tamaño de archivo medio ~200 KiB (archivo más grande: 100 GiB)
Enumeración inicial de cambios de nube 80 objetos por segundo
Rendimiento de carga 20 objetos por segundo por grupo de

sincronización
Rendimiento de descarga de espacio de 400 objetos por segundo

nombres
Enumeración inicial de cambios de nube: Cuando se crea un nuevo grupo de

sincronización, la enumeración inicial de cambios en la nube es el primer paso que se
ejecutará. En este proceso, el sistema enumerará todos los elementos del recurso
compartido de archivos de Azure. Durante este proceso, no habrá ninguna actividad de
sincronización; es decir, no se descargará ningún elemento del punto de conexión de la
nube al punto de conexión del servidor, y no se cargará ningún elemento desde el
punto de conexión del servidor al punto de conexión en la nube. La actividad de
sincronización se reanudará una vez que se complete la enumeración inicial de cambios
en la nube. La tasa de rendimiento es de 80 objetos por segundo. Para calcular el
tiempo que se tarda en completar la enumeración inicial de cambios en la nube, los
clientes pueden calcular el número de elementos del recurso compartido de nube y usar
la siguiente fórmula para obtener el tiempo en días.
Tiempo (en días) para la enumeración inicial en la nube = (número de objetos en el

punto de conexión de nube)/(80*60*60*24)
Sincronización inicial de datos de Windows Server con un recurso compartido de

archivos de Azure: muchas implementaciones de Azure File Sync comienzan con un
recurso compartido de archivos de Azure vacío porque todos los datos están en el
servidor de Windows. En estos casos, la enumeración inicial de cambios en la nube es
rápida y la mayor parte del tiempo se dedica a sincronizar los cambios de
Windows Server con los recursos compartidos de archivos de Azure.
Mientras la sincronización carga los datos en el recurso compartido de archivos de

Azure, no hay tiempo de inactividad en el servidor de archivos local y los
administradores pueden configurar los límites de red para restringir la cantidad de
ancho de banda que se usa para la carga de datos en segundo plano.
La sincronización inicial suele estar limitada por la velocidad de carga inicial de

20 archivos por segundo/por grupo de sincronización. Los clientes pueden calcular el
tiempo de carga de todos sus datos en Azure con las siguientes fórmulas para obtener
el tiempo en días:
Tiempo (en días) para la carga de archivos en un grupo de sincronización = (número

de objetos en el punto de conexión del servidor)/(20*60*60*24)
Dividir los datos en varios puntos de conexión de servidor y grupos de sincronización

puede acelerar esta carga de datos inicial, ya que la operación puede realizarse en
paralelo con varios grupos de sincronización a una velocidad de 20 elementos por
segundo. Por lo tanto, se ejecutarían dos grupos de sincronización con una tasa
combinada de 40 elementos por segundo. El tiempo total para terminar la operación
sería el tiempo estimado del grupo de sincronización con el mayor número de archivos
que se van a sincronizar.
Rendimiento de descarga de espacio de nombres Cuando se agrega un nuevo punto

de conexión de servidor a un grupo de sincronización existente, el agente de Azure File
Sync no descarga ningún contenido de archivo del punto de conexión en la nube. En
primer lugar sincroniza el espacio de nombres completo y, después, desencadena la
recuperación en segundo plano para descargar los archivos, ya sea en su totalidad o, si
está habilitada la organización en niveles en la nube, la directiva de niveles en la nube
establecida en el punto de conexión del servidor.
Sincronización en curso
Sincronización en curso Detalles
Número de objetos sincronizados 125 000 objetos (renovación ~ 1 %)
Tamaño del conjunto de datos 50 GiB
Tamaño de archivo medio ~500 KiB
Rendimiento de carga 20 objetos por segundo por grupo de sincronización
Rendimiento de descarga completa* 60 objetos por segundo
*Si están habilitados los niveles de la nube, es probable que observe un rendimiento
mejor, ya que solo se descargan algunos de los datos de los archivos. Azure File Sync
solo descarga los datos de los archivos almacenados en la memoria caché cuando
cambian en cualquiera de los puntos de conexión. En el caso de los archivos en niveles o
recién creados, el agente no descarga los datos de los archivos, solo sincroniza el
espacio de nombres en todos los puntos de conexión del servidor. El agente también
admite descargas parciales de archivos en capas cuando el usuario accede a ellos.
７ Nota
Los números anteriores no indican el rendimiento que experimentará. El

rendimiento real dependerá de varios factores, como se ha indicado al principio de
esta sección.
Como guía general para la implementación, debería tener varios factores en cuenta:
El rendimiento de los objetos se escala aproximadamente en proporción al número

de grupos de sincronización del servidor. La división de los datos en varios grupos
de sincronización en un servidor mejora el rendimiento, que también está limitado
por el servidor y la red.
El rendimiento de los objetos es inversamente proporcional al rendimiento de MiB
por segundo. En archivos pequeños, el rendimiento será mayor en cuanto al
número de objetos procesados por segundo, pero el rendimiento en MiB por
segundo será inferior. Por el contrario, en archivos grandes, se procesarán menos
objetos por segundo, pero el rendimiento en MiB por segundo será superior. El
rendimiento en MiB por segundo está limitado por los destinos del escalado de
Azure Files.
Consulte también
Descripción del rendimiento de Azure Files
Introducción a las opciones de
autenticación basada en la identidad de
Azure Files con el acceso SMB
Artículo • 22/11/2023
En este artículo se explica la forma en que los recursos compartidos de archivos de

Azure pueden usar los servicios de dominio, ya sea de forma local o en Azure, para
admitir el acceso basado en la identidad a los recursos compartidos de archivos de
Azure en SMB. La habilitación del acceso basado en identidad de los recursos
compartidos de archivos de Azure permite reemplazar los servidores de archivos
existentes por recursos compartidos de archivos de Azure sin reemplazar el servicio de
directorio existente, con lo que se mantiene el acceso sin problemas de los usuarios a
los recursos compartidos.
Se aplica a
Glosario
Es útil comprender algunos términos clave relacionados con la autenticación basada en
la identidad para recursos compartidos de archivos de Azure:
Autenticación Kerberos
Kerberos es un protocolo de autenticación que se utiliza para comprobar la

identidad de un usuario o un host. Para más información sobre Kerberos, consulte
Introducción a la autenticación Kerberos.
Protocolo Bloque de mensajes del servidor (SMB)
SMB es un protocolo de uso compartido de archivos de red estándar del sector.

Para más información sobre SMB, consulte Microsoft SMB Protocol and CIFS
Protocol Overview (Introducción a los protocolos CIFS y SMB de Microsoft).
Microsoft Entra ID
Microsoft Entra ID (anteriormente Azure AD) es el directorio multiinquilino basado

en la nube y el servicio de administración de identidades de Microsoft. Microsoft
Entra ID combina servicios de directorio fundamentales, administración del acceso
a las aplicaciones y protección de identidades en una única solución.
Servicios de dominio de Microsoft Entra
Microsoft Entra Domain Services proporciona servicios de dominio administrados

como, por ejemplo, unión a un dominio, directivas de grupo, LDAP y autenticación
Kerberos/NTLM. Estos servicios son totalmente compatibles con Active Directory
Domain Services. Para más información, consulte Microsoft Entra Domain Services.
Active Directory Domain Services (AD DS) local
La integración de Active Directory Domain Services (AD DS) local en Azure Files
proporciona los métodos para almacenar datos de directorio y poner dichos datos
a disposición de los usuarios y administradores de la red. La seguridad se integra
en AD DS mediante la autenticación de inicio de sesión y el control de acceso a los
objetos del directorio. Con un único inicio de sesión de red, los administradores
pueden administrar los datos del directorio y la organización a través de su red, y
los usuarios de red autorizados pueden tener acceso a los recursos en cualquier
parte de la red. Normalmente, las que adoptan AD DS son empresas en entornos
locales o en máquinas virtuales hospedadas en la nube, que usan las credenciales
de AD DS para el control de acceso. Para obtener más información, consulte
Introducción a Active Directory Domain Services.
Control de acceso basado en roles de Azure (Azure RBAC)
RBAC de Azure permite la administración detallada del acceso a Azure. Con Azure
RBAC, puede administrar el acceso a los recursos mediante la concesión a los
usuarios del menor número de permisos necesarios para realizar su trabajo. Para
obtener más información, consulte ¿Qué es el control de acceso basado en rol de
Azure (RBAC)?
Identidades híbridas
Las identidades de usuario híbridas son identidades de AD DS sincronizadas con

Microsoft Entra ID mediante la aplicación de sincronización de Microsoft Entra
Connect local o Microsoft Entra Connect Cloud Sync, un agente ligero que se
puede instalar desde el Centro de Administración de Microsoft Entra.
Escenarios de autenticación admitidos
Azure Files admite la autenticación basada en la identidad en SMB mediante los
métodos siguientes. Solo puede usar un método por cuenta de almacenamiento.
Autenticación AD DS local: Las máquinas Windows unidas a AD DS local o a

Microsoft Entra Domain Services pueden acceder a los recursos compartidos de
archivos de Azure con las credenciales de Active Directory local que se sincronizan
con Microsoft Entra ID a través de SMB. El cliente debe tener conectividad de red
no impedida a su AD DS. Si ya tiene AD DS configurado en el entorno local o en
una máquina virtual en Azure donde los dispositivos están unidos a un dominio de
AD, debe usar AD DS para la autenticación en los recursos compartidos de
archivos de Azure.
autenticación de Microsoft Entra Domain Services: máquinas virtuales basadas en
la nube de Windows unidas a Microsoft Entra Domain Services pueden acceder a
recursos compartidos de archivos de Azure con credenciales de Microsoft Entra. En
esta solución, Microsoft Entra ID ejecuta un dominio de Windows Server Active
Directory tradicional en nombre del cliente, que es un elemento secundario del
inquilino de Microsoft Entra del cliente.
Kerberos de Microsoft Entra para identidades híbridas: el uso de Microsoft Entra
ID para la autenticación de identidades híbridas de usuario permite a los usuarios
de Microsoft Entra acceder a recursos compartidos de archivos de Azure mediante
la autenticación Kerberos. Esto significa que los usuarios finales pueden acceder a
los recursos compartidos de archivos de Azure a través de Internet sin necesidad
de tener conectividad de red a los controladores de dominio desde máquinas
virtuales unidas a Microsoft Entra híbrido y a Microsoft Entra. Las identidades solo
en la nube no se admiten actualmente.
Autenticación Kerberos de AD para clientes Linux: los clientes Linux pueden usar
la autenticación Kerberos a través de SMB para Azure Files mediante AD DS local o
Microsoft Entra Domain Services.
Restricciones
Ninguno de los métodos de autenticación admite la asignación de permisos de
nivel de recurso compartido a cuentas de equipo (cuentas de máquina) mediante
RBAC de Azure, ya que las cuentas de equipo no se pueden sincronizar con una
identidad en Microsoft Entra ID. Si quiere permitir que una cuenta de equipo
acceda a recursos compartidos de archivos de Azure mediante la autenticación
basada en identidades, use un permiso de nivel de recurso compartido
predeterminado o considere la posibilidad de usar una cuenta de inicio de sesión
del servicio en su lugar.
No se admite la autenticación basada en identidad con recursos compartidos de
archivos de Network File System (NFS).
Casos de uso comunes

La autenticación basada en identidades con Azure Files puede ser útil en diversos
escenarios:
Reemplazo de servidores de archivos locales

Dejar de usar y reemplazar servidores de archivos locales dispersos es un problema
común que toda empresa encuentra en su recorrido de modernización de TI. Los
recursos compartidos de archivos de Azure con la autenticación de AD DS local son los
más idóneos aquí, cuando puede migrar los datos a Azure Files. Una migración
completa le permitirá aprovechar las ventajas de alta disponibilidad y escalabilidad, a la
vez que minimiza los cambios del lado cliente. Proporciona una experiencia de
migración perfecta para los usuarios finales, para que puedan seguir accediendo a sus
datos con las mismas credenciales mediante sus equipos unidos a un dominio existente.
Migración "lift-and-shift" de aplicaciones a Azure

Al aplicar migraciones "lift-and-shift" de aplicaciones a la nube, querrá mantener el
mismo modelo de autenticación para los datos. A medida que se amplía la experiencia
de control de acceso basado en identidad a los recursos compartidos de archivos de
Azure, se elimina la necesidad de cambiar la aplicación a los métodos de autenticación
modernos y acelerar la adopción de la nube. Los recursos compartidos de archivos de
Azure ofrecen la opción de integrarse en Microsoft Entra Domain Services o AD DS local
para la autenticación. Si tiene pensado pasarse un 100 % a la nube nativa y minimizar
los esfuerzos de administración de infraestructuras en la nube, puede que Microsoft
Entra Domain Services sea una mejor opción como servicio de dominio totalmente
administrado. Si necesita compatibilidad total con las funcionalidades de AD DS, puede
tener en cuenta la posibilidad de ampliar el entorno de AD DS a la nube mediante
controladores de dominio autohospedados en máquinas virtuales. En cualquier caso,
proporcionamos flexibilidad para elegir el servicio de dominio que mejor se adapte a
sus necesidades empresariales.
Copia de seguridad y recuperación ante desastres (DR)

Si mantiene el almacenamiento de archivos principal en el entorno local, los recursos
compartidos de archivos de Azure pueden servir como almacenamiento ideal para
copias de seguridad o recuperación ante desastres, lo que mejora la continuidad
empresarial. Puede usar recursos compartidos de archivos de Azure para realizar copias
de seguridad de los datos a partir de servidores de archivos existentes, a la vez que
conserva las listas de control de acceso discrecionales de Windows (DACL). En
escenarios de recuperación ante desastres, puede configurar una opción de
autenticación para admitir el cumplimiento adecuado del control de acceso en la
Ventajas de la autenticación basadas en

identidad
La autenticación basada en identidad para Azure Files ofrece varias ventajas respecto al
uso de la autenticación de clave compartida:
Ampliar la experiencia tradicional de acceso compartido de archivos basada en

identidad en la nube
Si tiene previsto realizar una migración "lift-and-shift" de su aplicación a la nube,
mediante el reemplazo de los servidores de archivos tradicionales con recursos
compartidos de archivos de Azure, tal vez quiera que la aplicación se autentique
con las credenciales de AD DS local o Microsoft Entra Domain Services para
acceder a los datos de los archivos. Azure Files admite el uso de credenciales de
AD DS local o de Microsoft Entra Domain Services para tener acceso a los recursos
compartidos de archivos de Azure a través de SMB desde VM unidas a un dominio
de AD DS local o Microsoft Entra Domain Services.
Aplicar el control de acceso granular en recursos compartidos de archivos de

Azure
Puede conceder permisos a una identidad específica en el nivel de recurso
compartido, directorio o archivo. Por ejemplo, suponga que tiene varios equipos
que utilizan un solo recurso compartido de archivos de Azure para la colaboración
en proyectos. Puede conceder a todos los equipos acceso a directorios no
confidenciales, al tiempo que limita el acceso a directorios que contienen datos
financieros confidenciales únicamente a su equipo de financiero.
Realizar copias de seguridad de ACL de Windows (también conocidas como

permisos NTFS) junto con los datos
Puede usar recursos compartidos de archivos de Azure para realizar copias de
seguridad de los recursos compartidos de archivos locales existentes. Azure Files
conserva las listas de control de acceso junto con los datos cuando se hace una
copia de seguridad de un recurso compartido de archivos en recursos compartidos
de archivos de Azure sobre SMB.
Funcionamiento
Los recursos compartidos de archivos de Azure utilizan el protocolo Kerberos para la
autenticación con un origen de AD. Cuando una identidad asociada con un usuario o
una aplicación que se ejecuta en un cliente intenta acceder a los datos de recursos
compartidos de archivos de Azure, la solicitud se envía al origen de AD para autenticar
la identidad. Si la autenticación es correcta, devuelve un token de Kerberos. El cliente
envía una solicitud que incluye el token de Kerberos, y los recursos compartidos de
archivos de Azure usan ese token para autorizar la solicitud. Los recursos compartidos
de archivos de Azure solo reciben el token de Kerberos, no las credenciales de acceso
del usuario.
Puede habilitar la autenticación basada en la identidad en las cuentas de

almacenamiento nuevas y existentes mediante uno de los tres orígenes de AD: AD DS,
Microsoft Entra Domain Services y Kerberos de Microsoft Entra (solo para las
identidades híbridas). Solo se puede usar un origen de AD para la autenticación de
acceso a archivos en la cuenta de almacenamiento, lo que se aplica a todos los recursos
compartidos de archivos de la cuenta. Para poder habilitar la autenticación basada en
identidades en la cuenta de almacenamiento, primero debe configurar el entorno del
dominio.
AD DS
En el caso de la autenticación de AD DS local, primero debe configurar los controladores
de dominio de AD y unir el dominio de sus máquinas o máquinas virtuales. Puede
hospedar los controladores de dominio en máquinas virtuales de Azure o en un entorno
local. En cualquier caso, los clientes unidos a un dominio deben tener una conectividad
de red no impedida al controlador de dominio, por lo que deben estar en la red
corporativa o en la red virtual (VNet) del servicio de dominio.
En este diagrama se muestra la autenticación de AD DS local en recursos compartidos

de archivos de Azure a través de SMB. El AD DS local debe sincronizarse con Microsoft
Entra ID mediante Microsoft Entra Connect Sync o la sincronización en la nube de
Microsoft Entra Connect. Solo se pueden autenticar y autorizar a las identidades de los
usuarios híbridos que existen en el AD DS local y en Microsoft Entra ID para el acceso a
recursos compartidos de archivos de Azure. Esto se debe a que el permiso de nivel de
recurso compartido se configura con respecto a la identidad representada en Microsoft
Entra ID, mientras que el permiso de nivel de archivo o directorio se aplica con el de AD
DS. Asegúrese de configurar los permisos correctamente con el mismo usuario híbrido.
Para más información sobre cómo habilitar la autenticación de AD DS, primero lea
Introducción: autenticación de Active Directory Domain Services local en SMB para
recursos compartidos de archivos de Azure y, después, Habilitar la autenticación de AD
DS para los recursos compartidos de archivos de Azure.

En el caso de la autenticación de Microsoft Entra Domain Services, debe habilitar
Microsoft Entra Domain Services y unir a un dominio las VM desde las que tiene
pensado obtener acceso a los datos de los archivos. La VM unida a un dominio debe
residir en la misma red virtual (Vnet) que la instancia de Microsoft Entra Domain
Services.
Este diagrama representa el flujo de trabajo para la autenticación de Microsoft Entra

Domain Services en recursos compartidos de archivos de Azure a través de SMB. Sigue
un patrón similar a la autenticación de AD DS local, pero hay dos diferencias principales:
1. No es necesario crear la identidad en Microsoft Entra Domain Services para

representar la cuenta de almacenamiento. Esto lo realiza el proceso de habilitación
en segundo plano.
2. Todos los usuarios que existen en Microsoft Entra ID se pueden autenticar y

autorizar. El usuario puede ser híbrido o estar solo en la nube. La plataforma
administra la sincronización de Microsoft Entra ID a Microsoft Entra Domain
Services sin necesidad de ninguna configuración de usuario. Sin embargo, el
cliente debe estar unido al dominio hospedado de Microsoft Entra Domain
Services. No se puede estar unido ni registrado a Microsoft Entra. Microsoft Entra
Domain Services no admite los clientes que no son de Azure (es decir, los equipos
portátiles de usuario, las estaciones de trabajo, las máquinas virtuales en otras
nubes, etc.) que se unan a al dominio hospedado de Microsoft Entra Domain
Services. Sin embargo, es posible montar un recurso compartido de archivos desde
un cliente no unido a un dominio proporcionando credenciales explícitas como
DOMAINNAME\username o mediante el nombre de dominio completo
(username@FQDN).
Para aprender a habilitar la autenticación de Microsoft Entra Domain Services, consulte

Habilitación de la autenticación de Microsoft Entra Domain Services en Azure Files.
Microsoft Entra Kerberos para identidades híbridas

La habilitación y configuración de Microsoft Entra ID para autenticar identidades de
usuarios híbridas permite a los usuarios de Microsoft Entra acceder a recursos
compartidos de archivos de Azure mediante la autenticación Kerberos. Esta
configuración usa Microsoft Entra ID para emitir los vales de Kerberos necesarios para
acceder al recurso compartido de archivos con el protocolo SMB estándar del sector.
Esto significa que los usuarios finales pueden acceder a los recursos compartidos de
archivos de Azure a través de Internet sin necesidad de tener conectividad de red a los
controladores de dominio desde máquinas virtuales unidas a Microsoft Entra híbrido y a
Microsoft Entra. Sin embargo, la configuración de permisos de nivel de archivo y
directorio de usuarios y grupos requiere conectividad de red no impedida al controlador
de dominio local.
） Importante
La autenticación Kerberos de Microsoft Entra solo admite las identidades de

usuario híbridas; no admite identidades solo en la nube. Se necesita una
implementación tradicional de AD DS y debe sincronizarse con Microsoft Entra ID
mediante Microsoft Entra Connect Sync o la sincronización en la nube de Microsoft
Entra Connect. Los clientes deben estar unido a Microsoft Entra o a Microsoft Entra
híbrido. Kerberos de Microsoft Entra no se admite en clientes unidos a Microsoft
Entra Domain Services o unidos solo a AD.
Para aprender a habilitar la autenticación Kerberos de Microsoft Entra para identidades
híbridas, consulte Activación de la autenticación Kerberos de Microsoft Entra para
identidades híbridas en Azure Files.
También puede usar esta característica para almacenar perfiles de FSLogix en recursos
compartidos de archivos de Azure para máquinas virtuales unidas a Microsoft Entra.
Para obtener más información, consulte Creación de un contenedor de perfil con Azure
Files y Microsoft Entra ID.
Control de acceso
Azure Files aplica la autorización en el acceso del usuario tanto a nivel del recurso
compartido como a los niveles de directorio o archivo. La asignación de permisos de
nivel de recurso compartido se puede llevar a cabo en usuarios o grupos de Microsoft
Entra administrados con Azure RBAC. Con Azure RBAC, las credenciales que se usan
para el acceso a archivos deben estar disponibles o sincronizadas con Microsoft Entra
ID. Para conceder acceso a un recurso compartido de archivos de Azure, puede asignar
roles integrados de Azure, como el de lector de recursos compartidos de SMB de datos
de archivos de almacenamiento, a usuarios o grupos en Microsoft Entra ID.
En el nivel de directorio o archivo, Azure Files admite la conservación, la herencia y la

aplicación de listas ACL de Windows, igual que cualquier servidor de archivos de
Windows. Si lo desea, puede mantener las listas ACL de Windows al copiar datos a
través de SMB entre su recurso compartido de archivos y los recursos compartidos de
archivos de Azure. Independientemente de que se tenga previsto aplicar la autorización
o no, se pueden usar los recursos compartidos de archivos de Azure para hacer copias
de seguridad de las ACL junto con los datos.
Configuración de los permisos de nivel de recurso

compartido para Azure Files
Una vez que haya habilitado un origen de AD en la cuenta de almacenamiento, debe
realizar una de las siguientes acciones para acceder al recurso compartido de archivos:
Establecer un permiso de nivel de recurso compartido predeterminado que se

aplique a todos los usuarios y grupos autenticados
Asignación de roles RBAC de Azure integrados a usuarios y grupos, o
Configurar roles personalizados para las identidades de Microsoft Entra y asignar
derechos de acceso a los recursos compartidos de archivos en la cuenta de
almacenamiento.
El permiso de nivel de recurso compartido asignado permite a la identidad concedida

obtener acceso solo al recurso compartido, a nada más, ni siquiera al directorio raíz. Aún
es necesario configurar por separado los permisos de nivel de directorio y de archivo.
Configuración de los permisos de nivel de archivo o

directorio para Azure Files
Los recursos compartidos de archivos de Azure aplican listas de control de acceso
estándar de Windows en el nivel de archivo y directorio, incluido el directorio raíz. La
configuración de permisos de nivel de archivo o directorio se admite sobre SMB y REST.
Monte el recurso compartido de archivos de destino de la VM y configure los permisos
mediante el Explorador de archivos de Windows, o el comando de Windows icacls o
Set-ACL.
Uso de la clave de cuenta de almacenamiento para los

permisos de superusuario
Un usuario con la clave de cuenta de almacenamiento puede acceder a los recursos
compartidos de archivos de Azure con permisos de superusuario. Los permisos de
superusuario omiten todas las restricciones de control de acceso.
） Importante
Nuestro procedimiento recomendado de seguridad es evitar el uso compartido de

las claves de cuenta de almacenamiento y aprovechar la autenticación basada en
identidad siempre que sea posible.
Conservación de las listas de control de acceso de

archivos y directorios al importar datos a recursos
Azure Files admite la conservación de las listas de control de acceso de directorios o
archivos al copiar datos a recursos compartidos de archivos de Azure. Puede copiar
listas de control de acceso de un directorio o archivo en recursos compartidos de
archivos de Azure mediante Azure File Sync o conjuntos de herramientas comunes para
mover archivos. Por ejemplo, puede usar robocopy con la marca /copy:s para copiar
tanto los datos como las listas de control de acceso en un recurso compartido de
archivos de Azure. Las listas de control de acceso se conservan de forma
predeterminada, no es necesario habilitar la autenticación basada en la identidad en la
cuenta de almacenamiento para conservarlas.
Precios
No hay ningún cargo adicional por servicio por habilitar la autenticación basada en la
identidad en SMB en la cuenta de almacenamiento. Para obtener más información sobre
los precios, consulte Precios de Azure Files y Precios de Microsoft Entra Domain
Services .
Pasos siguientes
Para obtener más información sobre Azure Files y la autenticación basada en identidad a
través de SMB, consulte estos recursos:

recursos compartidos de archivos de Azure
Habilitación de la autenticación de Microsoft Entra Domain Services en Azure Files
Habilitación de la autenticación Kerberos de Microsoft Entra para identidades
híbridas en Azure Files
Habilitar la autenticación Kerberos de AD para clientes Linux
P+F
Acceso a recursos compartidos de
archivos de Azure mediante Microsoft
Entra ID con OAuth de Azure Files a
través de REST
Artículo • 21/10/2023
OAuth de Azure Files a través de REST permite acceso de lectura y escritura de nivel de
administrador a los recursos compartidos de archivos de Azure para usuarios y aplicaciones
a través del protocolo de autenticación de OAuth , por medio de Microsoft Entra ID para
el acceso basado en la API de REST. Los usuarios, grupos, servicios de primera entidad,
como Azure Portal, y servicios y aplicaciones de terceros que usan interfaces de REST,
ahora pueden usar la autenticación y autorización de OAuth con una cuenta de Microsoft
Entra para acceder a los datos de recursos compartidos de archivos de Azure. Los cmdlets
de PowerShell y los comandos de la CLI de Azure que llaman a las API de REST también
pueden usar OAuth para acceder a recursos compartidos de archivos de Azure.
） Importante
Debe llamar a la API de REST mediante un encabezado explícito para indicar la

intención de usar el privilegio adicional. Esto también es cierto para el acceso a Azure
PowerShell y la CLI de Azure.
Limitaciones
OAuth de Azure Files a través de REST (versión preliminar) solo admite las API de datos de
REST de Files que admiten operaciones en archivos y directorios. OAuth no se admite en
las API del plano de datos de FilesREST que administran los recursos FileService y FileShare.
Estas API de administración se llaman mediante la clave de cuenta de almacenamiento o el
token de SAS, y se exponen a través del plano de datos por motivos heredados. Se
recomienda usar las API del plano de control (el proveedor de recursos de
almacenamiento: Microsoft.Storage) que admitan OAuth para todas las actividades de
administración relacionadas con los recursos FileService y FileShare.
La autorización de operaciones de datos de archivos con Microsoft Entra ID solo se admite

para las versiones 2022-11-02 y posteriores de la API de REST. Control de versiones para
servicios de Azure Storage.
Casos de uso de clientes
La autenticación y autorización de OAuth con Azure Files a través de la interfaz de la API de
REST pueden beneficiar a los clientes en los escenarios siguientes.
Integración del servicio y desarrollo de aplicaciones

La autenticación y autorización de OAuth permiten a los desarrolladores crear aplicaciones
que accedan a las API de REST de Azure Storage mediante identidades de usuario o
aplicación de Microsoft Entra ID.
Los clientes y asociados también pueden permitir que los servicios propios y de terceros
configuren el acceso necesario de forma segura y transparente a una cuenta de
almacenamiento del cliente.
Las herramientas de DevOps, como Azure Portal, PowerShell y la CLI, AzCopy y Explorador
de Azure Storage pueden administrar datos mediante la identidad del usuario, lo que
elimina la necesidad de administrar o distribuir claves de acceso de almacenamiento.
Identidades administradas
Los clientes con aplicaciones e identidades administradas que requieren acceso a los datos
del recurso compartido de archivos con fines de copia de seguridad, restauración o
auditoría pueden beneficiarse de la autenticación y autorización de OAuth. La aplicación de
permisos de nivel de archivo y directorio para cada identidad agrega complejidad y podría
no ser compatible con determinadas cargas de trabajo. Por ejemplo, es posible que los
clientes quieran autorizar a un servicio de solución de copia de seguridad para acceder a
recursos compartidos de archivos de Azure con acceso de solo lectura a todos los archivos
sin tener en cuenta los permisos específicos del archivo.
Reemplazo de la clave de la cuenta de almacenamiento

Microsoft Entra ID proporciona una mayor seguridad y facilidad de uso que el acceso de
clave compartida. Puede reemplazar el acceso a la clave de la cuenta de almacenamiento
por la autenticación y autorización de OAuth para acceder a recursos compartidos de
archivos de Azure con privilegios de lectura y escritura. Este enfoque también ofrece una
mejor auditoría y seguimiento del acceso específico de los usuarios.
Permisos de acceso y acceso con privilegios para

las operaciones de datos
Para usar la característica OAuth de Azure Files sobre REST, se requieren permisos
adicionales para incluirse en el rol RBAC asignado al usuario, grupo o entidad de servicio.
Se presentan dos nuevas acciones de datos como parte de esta característica:
Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action
Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action
Los usuarios, grupos o entidades de servicio que llaman a la API de REST con OAuth deben
tener asignada la acción readFileBackupSemantics o writeFileBackupSemantics al rol que
permita el acceso a los datos. Este es un requisito para usar esta característica. Para
obtener información sobre los permisos necesarios para llamar a operaciones concretas de
servicio de archivos, vea Permisos para llamar a operaciones de datos.
Esta característica proporciona dos nuevos roles integrados que incluyen estas nuevas
acciones.
Rol Acciones de datos
Lector con Microsoft.Storage/storageAccounts/fileServices/fileShares/files/read

privilegios Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action
de datos de
archivos de
Storage
Colaborador Microsoft.Storage/storageAccounts/fileServices/fileShares/files/read
con Microsoft.Storage/storageAccounts/fileServices/fileShares/files/write
privilegios Microsoft.Storage/storageAccounts/fileServices/fileShares/files/delete
de datos de Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action
archivos de Microsoft.Storage/storageAccounts/fileServices/fileshares/files/modifypermissions/action
Storage
Estos nuevos roles son similares a los roles integrados existentes Lector de recursos
compartidos de SMB de datos de archivos de Storage y Colaborador con privilegios
elevados de recursos compartidos de SMB de datos de archivos de almacenamiento, pero
hay algunas diferencias:
Los nuevos roles contienen las acciones de datos adicionales necesarias para el
acceso de OAuth.
Cuando el usuario, el grupo o la entidad de servicio a los que se asignan los roles
Lector con privilegios de datos de archivo de almacenamiento o Colaborador con
privilegios de archivos de almacenamiento llama a la API de FilesREST Data
mediante OAuth, el usuario, el grupo o la entidad de servicio tendrán:
Lector con privilegios de datos de archivo de almacenamiento: Acceso de lectura
completo en todos los datos de los recursos compartidos para todas las cuentas
de almacenamiento configuradas, independientemente de los permisos NTFS de
nivel de archivo o directorio establecidos.
Colaborador con privilegios de datos de archivo de almacenamiento: Acceso de
lectura, escritura, eliminación y modificación de ACL completo en todos los datos
de los recursos compartidos para todas las cuentas de almacenamiento
configuradas, independientemente de los permisos NTFS de nivel de archivo o
directorio establecidos.
Con estos permisos y roles especiales, el sistema omitirá los permisos de nivel de
archivo o directorio y permitirá el acceso a los datos del recurso compartido de
archivos.
Con los nuevos roles y acciones de datos, esta característica proporcionará privilegios para
toda la cuenta de almacenamiento, que reemplazan todos los permisos en los archivos y
carpetas de todos los recursos compartidos de los archivos de la cuenta de
almacenamiento. Sin embargo, los nuevos roles solo contienen permisos para acceder a los
servicios de datos. No incluyen ningún permiso para acceder a los servicios de
administración de recursos compartidos de archivos (acciones en recursos compartidos de
archivos). Para usar esta característica, asegúrese de que tiene permisos para acceder a:
la cuenta de almacenamiento
servicios de administración de recursos compartidos de archivos
servicios de datos (los datos del recurso compartido de archivos)
Hay muchos roles integrados que proporcionan acceso a los servicios de administración.
También puede crear roles personalizados con los permisos apropiados. Para más
información sobre el control de acceso basado en roles, consulte Azure RBAC. Para más
información sobre cómo se definen los roles integrados, consulte Descripción de
definiciones de roles.
） Importante
Los casos de uso con caracteres comodín definidos para la ruta de acceso
Microsoft.Storage/storageAccounts/fileServices/* o el ámbito superior heredarán
automáticamente el acceso adicional y los permisos concedidos a través de esta

nueva acción de datos. Para evitar el acceso no deseado o con privilegios excesivos a
Azure Files, hemos implementado comprobaciones adicionales que requieren que los
usuarios y las aplicaciones indiquen explícitamente su intención de usar el privilegio
adicional. Además, se recomienda encarecidamente que los clientes revisen sus
asignaciones de roles RBAC de usuario y reemplacen cualquier uso de caracteres
comodín con permisos explícitos para garantizar la administración adecuada del
acceso a los datos.
Autorización del acceso a los datos de archivo en
el código de la aplicación
La biblioteca cliente de Azure Identity simplifica el proceso de obtener un token de acceso
de OAuth 2.0 para la autorización con Microsoft Entra ID a través del SDK de Azure . Las
versiones más recientes de las bibliotecas cliente de Azure Storage para .NET, Java, Python,
JavaScript y Go se integran con las bibliotecas de Azure Identity para dichos lenguajes para
proporcionar un medio sencillo y seguro de obtener un token de acceso para la
autorización de las solicitudes del servicio de archivos de Azure.
Una ventaja de la biblioteca cliente de Azure Identity es que permite usar el mismo código
para adquirir el token de acceso tanto si la aplicación se ejecuta en el entorno de
desarrollo como en Azure. La biblioteca cliente de Azure Identity devuelve un token de
acceso para una entidad de seguridad. Cuando el código se ejecuta en Azure, la entidad de
seguridad puede ser una identidad administrada para recursos de Azure, una entidad de
servicio, un usuario o un grupo. En el entorno de desarrollo, la biblioteca cliente
proporciona un token de acceso para un usuario o una entidad de servicio con fines de
prueba.
El token de acceso devuelto por la biblioteca cliente de Azure Identity se encapsula en una
credencial de token. A continuación, puede usar la credencial de token para obtener un
objeto de cliente de servicio que se usará para realizar operaciones autorizadas en el
servicio de Azure Files.
Este es un código de ejemplo:
ASP.NET (C#)
using Azure.Core;
using Azure.Identity;
using Azure.Storage.Files.Shares;
using Azure.Storage.Files.Shares.Models;
namespace FilesOAuthSample
{
internal class Program
{
static async Task Main(string[] args)
{
string tenantId = "";
string appId = "";
string appSecret = "";
string aadEndpoint = "";
string accountUri = "";
string connectionString = "";
string shareName = "testShare";
string directoryName = "testDirectory";
string fileName = "testFile";
ShareClient sharedKeyShareClient = new
ShareClient(connectionString, shareName);
await sharedKeyShareClient.CreateIfNotExistsAsync();
TokenCredential tokenCredential = new ClientSecretCredential(

tenantId,
appId,
appSecret,
new TokenCredentialOptions()
{
AuthorityHost = new Uri(aadEndpoint)
});
ShareClientOptions clientOptions = new

ShareClientOptions(ShareClientOptions.ServiceVersion.V2021_12_02);
// Set Allow Trailing Dot and Source Allow Trailing Dot.

clientOptions.AllowTrailingDot = true;
clientOptions.SourceAllowTrailingDot = true;
// x-ms-file-intent=backup will automatically be applied to all

APIs
// where it is required in derived clients.
clientOptions.ShareTokenIntent = ShareTokenIntent.Backup;
ShareServiceClient shareServiceClient = new ShareServiceClient(
new Uri(accountUri),
tokenCredential,
clientOptions);
ShareClient shareClient =
shareServiceClient.GetShareClient(shareName);
ShareDirectoryClient directoryClient =
shareClient.GetDirectoryClient(directoryName);
await directoryClient.CreateAsync();
ShareFileClient fileClient =
directoryClient.GetFileClient(fileName);
await fileClient.CreateAsync(maxSize: 1024);
await fileClient.GetPropertiesAsync();
await sharedKeyShareClient.DeleteIfExistsAsync();
}
}
}
Autorización del acceso mediante la API del

plano de datos FileREST
También puede autorizar el acceso a los datos de archivo mediante el Azure Portal o Azure
PowerShell.
Azure Portal
Azure Portal puede usar la cuenta de Microsoft Entra o las claves de acceso de
cuenta de almacenamiento para acceder a los datos de archivos de una cuenta de
almacenamiento de Azure. El esquema de autorización que use Azure Portal depende
de los roles de Azure que tenga asignados.
Si intenta acceder a datos de archivos, Azure Portal primero comprueba si tiene

asignado un rol de Azure con Microsoft.Storage/storageAccounts/listkeys/action . Si
tiene un rol asignado con esta acción, Azure Portal usa la clave de cuenta para acceder
a los datos de archivos mediante la autorización de clave compartida. Si no tiene un
rol asignado con esta acción, Azure Portal intenta acceder a los datos mediante la
cuenta de Microsoft Entra.
Para acceder a datos de archivos desde Azure Portal con la cuenta de Microsoft Entra,
necesita permisos para acceder a datos de archivos y, también, permisos para
examinar los recursos de la cuenta de almacenamiento en Azure Portal. Los roles
integrados que proporciona Azure conceden acceso a recursos de archivos, pero no
conceden permisos a los recursos de la cuenta de almacenamiento. Por este motivo, el
acceso al portal también requiere la asignación de un rol de Azure Resource Manager
(ARM), como el rol Lector, con ámbito limitado al nivel de la cuenta de
almacenamiento o superior. El rol Lector concede los permisos más restringidos, pero
otro rol de ARM que conceda acceso a los recursos de administración de la cuenta de
almacenamiento también es aceptable.
Azure Portal indica qué esquema de autorización se está usando al examinar un

contenedor. Para obtener más información sobre acceso a los datos en el portal,
consulte Elección de la forma de autorizar el acceso a los datos de archivos en Azure
Portal.
Consulte también
Elegir cómo autorizar el acceso a los datos de archivo en Azure Portal
Descripción de la facturación de Azure
Files
Artículo • 09/04/2023
Azure Files proporciona dos modelos de facturación distintos: aprovisionado y pago por
uso. El modelo aprovisionado solo está disponible para los recursos compartidos de
archivos prémium, que son recursos compartidos de archivos implementados en el tipo
de cuenta de almacenamiento FileStorage. El modelo de pago por uso solo está
disponible para los recursos compartidos de archivos estándar, que son recursos
compartidos de archivos implementados en el tipo de cuenta de almacenamiento de
uso general, versión 2 (GPv2) . En este artículo se explica cómo funcionan ambos
modelos con el fin de ayudarle a entender la factura mensual de Azure Files.
Azure Unblogged - Pricing Up Azure Files
Este vídeo es una entrevista donde se describen los conceptos básicos del modelo de
facturación de Azure Files. Se abordan la optimización de los recursos compartidos de
archivos de Azure para lograr los costos más bajos posibles y la comparación de
Azure Files con otras ofertas de almacenamiento de archivos en el entorno local y en la
nube.
Para obtener información sobre los precios de Azure Files, vea la página de precios de
Azure Files .
Se aplica a
Unidades de almacenamiento
Azure Files usa unidades de medida de base 2 para representar la capacidad de
almacenamiento: KiB, MiB, GiB y TiB.
Acrónimo Definición Unidad
KiB 1024 bytes kibibyte
MiB 1024 KiB (1 048 576 bytes) mebibyte
GiB 1024 MiB (1 073 741 824 bytes) gibibyte
TiB 1024 GiB (1 099 511 627 776 bytes) tebibyte
Aunque la mayoría de los sistemas operativos y las herramientas utilizan habitualmente

las unidades de medida de base 2 para medir las cantidades de almacenamiento, con
frecuencia se etiquetan erróneamente como unidades de base 10, con las que quizá
esté más familiarizado: KB, MB, GB y TB. Aunque los motivos pueden variar, la razón
común por la que los sistemas operativos como Windows etiquetan incorrectamente las
unidades de almacenamiento es porque muchos sistemas operativos comenzaron a usar
estos acrónimos antes de que se estandarizaran mediante IEC, BIPM y NIST.
En la tabla siguiente, se muestra cómo miden y etiquetan el almacenamiento los

sistemas operativos comunes:
Sistema Sistema de medición Etiquetado

operativo
Windows Base 2 Etiquetas incorrectas uniformes como base 10.
Distribuciones de Normalmente base 2, El etiquetado y la alineación incoherentes entre

Linux algún software puede la medición y el etiquetado depende del paquete
usar base 10 de software.
macOS, iOS y el Base 10 Etiquetas uniformes como base 10 .

sistema operativo
para iPad
Consulte con el proveedor del sistema operativo si su sistema operativo no aparece en
la lista.
Lista de comprobación del costo total de

propiedad del recurso compartido de archivos
Si va a migrar a Azure Files desde el entorno local o va a comparar Azure Files con otras
soluciones de almacenamiento en la nube, debe tener en cuenta los siguientes factores
para garantizar una comparación justa entre elementos equivalentes:
¿Cómo se paga por el almacenamiento, IOPS y el ancho de banda? Con Azure

Files, el modelo de facturación que use depende de si va a implementar recursos
compartidos de archivos prémium o estándar. La mayoría de las soluciones en la
nube tienen modelos en consonancia con los principios del almacenamiento
aprovisionado, como determinismo de precios y simplicidad, o el almacenamiento
de pago por uso, que puede optimizar los costes al cobrar solo por lo que
realmente se usa. En el caso de los modelos aprovisionados, son de especial
interés el tamaño mínimo del recurso compartido aprovisionado, la unidad de
aprovisionamiento y la posibilidad de aumentar y disminuir el aprovisionamiento.
¿Hay algún método para optimizar los costos de almacenamiento? Puede usar
reservas de Azure Files para lograr un descuento de hasta un 36 % en el
almacenamiento. Otras soluciones pueden emplear estrategias como la
desduplicación o compresión para optimizar de manera opcional la eficacia del
almacenamiento. Sin embargo, estas estrategias de optimización del
almacenamiento suelen tener costos no monetarios, como una reducción del
rendimiento. Las reservas no tienen efectos secundarios en el rendimiento.
¿Cómo se consigue la resistencia y la redundancia del almacenamiento? Con

Azure Files, la resistencia y la redundancia del almacenamiento están integradas en
la oferta del producto. Todos los niveles y opciones de redundancia garantizan una
alta disponibilidad de los datos y el acceso a al menos tres copias de estos. Al
considerar otras opciones de almacenamiento de archivos, tenga en cuenta si la
resistencia y redundancia del almacenamiento están integradas o es algo de lo que
tenga que encargarse personalmente.
¿Qué tiene que administrar? Con Azure Files, la unidad básica de administración
es una cuenta de almacenamiento. Otras soluciones pueden requerir
administración adicional, como actualizaciones del sistema operativo o
administración de recursos virtuales (máquinas virtuales, discos, direcciones IP de
red, etc.).
¿Cuáles son los costos de los productos de valor añadido, como la copia de
seguridad, la seguridad, etc.? Azure Files admite integraciones con varios servicios
de valor añadido propios y de terceros. Servicios de valor añadido como Azure
Backup, Azure File Sync y Azure Defender, que proporcionan copia de seguridad,
replicación y almacenamiento en caché, y funcionalidad de seguridad adicional
para Azure Files. Las soluciones de valor añadido, ya sean locales o en la nube,
tienen sus propios costos de licencias y de producto, pero a menudo se consideran
parte del costo total de propiedad para el almacenamiento de archivos.
Reservations
Azure Files admite reservas (también conocidas como instancias reservadas), lo que le
permite lograr un descuento en el almacenamiento mediante la confirmación previa del
uso del almacenamiento. Debe considerar la posibilidad de comprar instancias
reservadas para cualquier carga de trabajo de producción o cargas de trabajo de
desarrollo y pruebas con superficies coherentes. Al comprar una reserva, debe
especificar las siguientes dimensiones:
Tamaño de capacidad: las reservas pueden ser de 10 TiB o 100 TiB, con descuentos
más significativos por la compra de una reserva de capacidad mayor. Puede
comprar varias reservas, incluso reservas de diferentes tamaños de capacidad para
satisfacer los requisitos de la carga de trabajo. Por ejemplo, si la implementación
de producción tiene 120 TiB de recursos compartidos de archivos, podría comprar
una reserva de 100 TiB y dos reservas de 10 TiB para satisfacer los requisitos
totales de capacidad de almacenamiento.
Período: las reservas se pueden comprar durante un período de un año o tres
años, con descuentos más significativos por comprar un período de reserva más
largo.
Nivel: el nivel de Azure Files para la reserva. Las reservas están disponibles
actualmente para los niveles de acceso prémium, frecuente y esporádico.
Ubicación: la región de Azure para la reserva. Las reservas están disponibles en un
subconjunto de regiones de Azure.
Redundancia: la redundancia de almacenamiento para la reserva. Las reservas se
admiten para todas los redundancias que admite Azure Files, como LRS, ZRS, GRS
y GZRS.
Frecuencia de facturación: indica la frecuencia con la que se factura la cuenta para
la reserva. Entre las opciones se incluyen Mensual o Por adelantado.
Una vez que compre una reserva, el uso de almacenamiento existente la consumirá
automáticamente. Si usa más espacio de almacenamiento del que ha reservado, pagará
el precio de venta del saldo que no esté cubierto por la reserva. Los cargos por
transacción, ancho de banda, transferencia de datos y almacenamiento de metadatos no
se incluyen en la reserva.
Hay diferencias en el funcionamiento de las reservas con las instantáneas de recursos

compartidos de archivos de Azure para recursos compartidos de archivos estándar y
premium. Si va a tomar instantáneas de recursos compartidos estándar, las diferenciales
de instantáneas se cuentan para la reserva y se facturan como parte del medidor de
almacenamiento usado normal. Sin embargo, si va a tomar instantáneas de recursos
compartidos de archivos Premium, se usa un medidor independiente para facturar las
instantáneas y estas no cuentan para la reserva. Para más información, consulte
Instantánea.
Para más información sobre cómo comprar reservas, consulte Optimización de costos
para Azure Files con las reservas.
Modelo aprovisionado
Azure Files usa un modelo aprovisionado para los recursos compartidos de archivos
prémium. En un modelo de facturación aprovisionado, debe especificar de forma
proactiva cuáles son los requisitos de almacenamiento del servicio Azure Files, en lugar
de que se le aplique una factura basada en lo que usa. Un modelo aprovisionado para el
almacenamiento es similar a comprar una solución de almacenamiento local porque, al
aprovisionar un recurso compartido de archivos de Azure con una determinada cantidad
de capacidad de almacenamiento, se paga por esa capacidad de almacenamiento
independientemente de si la usa o no. A diferencia de la compra de soportes físicos
locales, los recursos compartidos de archivos aprovisionados se pueden escalar o
reducir verticalmente de forma dinámica en función de las características de
rendimiento de almacenamiento y de E/S.
El tamaño aprovisionado del recurso compartido de archivos puede aumentar en

cualquier momento, pero solo se puede reducir una vez transcurridas 24 horas desde el
último aumento. Después de esperar 24 horas sin un aumento de cuota, puede reducir
el recurso compartido tantas veces como quiera hasta que lo vuelva a aumentar. Los
cambios de escala de IOPS/rendimiento se aplicarán minutos después del cambio de
tamaño aprovisionado.
Es posible reducir el tamaño del recurso compartido aprovisionado por debajo de los
GiB usados. Si lo hace, no perderá datos, pero se le seguirá facturando el tamaño usado
y seguirá recibiendo el rendimiento del recurso compartido aprovisionado, no del
tamaño usado.
Método de aprovisionamiento
Al aprovisionar un recurso compartido de archivos prémium, se especifica la cantidad de
GiB que requiere la carga de trabajo. Cada GiB aprovisionado permite beneficiarse de
más IOPS y rendimiento con una proporción fija. Además de la IOPS de línea de base
garantizada, cada recurso compartido de archivos prémium admite ráfagas dentro de lo
posible. Las fórmulas de IOPS y rendimiento son las siguientes:
Elemento Value
Tamaño máximo de un recurso 100 GiB

Unidad de aprovisionamiento 1 GiB
Fórmula de IOPS de línea de base MIN(3000 + 1 * ProvisionedStorageGiB, 100000)
Límite de aumento MIN(MAX(10000, 3 * ProvisionedStorageGiB), 100000)
Créditos de ráfaga (BurstLimit - BaselineIOPS) * 3600
Tasa de rendimiento (entrada + 100 + CEILING(0.04 * ProvisionedStorageGiB) +

salida) (MiB/seg.) CEILING(0.06 * ProvisionedStorageGiB)
En la tabla siguiente se ilustran algunos ejemplos de estas fórmulas para los tamaños de
recursos compartidos aprovisionados:
Capacidad IOPS IOPS de Créditos de Rendimiento (entrada + salida)

(GiB) base ráfaga ráfaga (MiB/s)
100 3100 Hasta 10 000 24 840 000 110
500 3500 Hasta 10 000 23 400 000 150
1024 4 024 Hasta 10 000 21 513 600 203
5120 8120 Hasta 15 360 26 064 000 613
10 240 13 240 Hasta 30 720 62 928 000 1125
33 792 36 792 Hasta 227 548 800 3480

100 000
51 200 54 200 Hasta 164 880 000 5220

100 000
102 400 100 000 Hasta 0 10 340

100 000
El rendimiento efectivo de los recursos compartidos de archivos está sujeto a los límites
de red de la máquina, el ancho de banda de red disponible, los tamaños de E/S y el
paralelismo, entre muchos otros factores. Para aprovechar al máximo la paralelización,
se recomienda habilitar SMB multicanal en los recursos compartidos de archivos
premium. Para más información, consulte Habilitar SMB multicanal. Consulte en el
artículo sobre rendimiento de SMB multicanal y en la guía de solución de problemas de
rendimiento algunos problemas de rendimiento comunes y sus soluciones alternativas.
Creación de ráfagas
Si la carga de trabajo necesita un rendimiento adicional para satisfacer los picos de
demanda, el recurso compartido puede usar créditos de expansión para superar el límite
de IOPS de línea base del recurso compartido, con el fin de proporcionar al recurso
compartido el rendimiento que necesita para satisfacer la demanda. La creación de
ráfagas está automatizada y funciona de acuerdo con un sistema de crédito. La
expansión funciona en la medida de lo posible y el límite de expansión no es una
garantía.
Cada vez que el tráfico para el recurso compartido de archivos se encuentra por debajo
del valor de IOPS de la línea de base, se acumulan créditos en un cubo de ráfagas. Los
créditos obtenidos se usan más adelante para habilitar la expansión cuando las
operaciones superarían la IOPS de línea base.
Cada vez que un recurso compartido supera el valor de IOPS de línea base y tiene
créditos en un cubo de expansión, este aumentará hasta alcanzar la velocidad máxima
permitida. Los recursos compartidos pueden seguir con la expansión siempre y cuando
queden créditos, pero esto se basa en el número de créditos de expansión acumulados.
Cada E/S que supere el valor de IOPS de línea base consume un crédito y, una vez que
se consumen todos los créditos, el recurso compartido volvería al valor de IOPS de la
línea base.
Los créditos de recursos compartidos tienen tres estados:
Acumulado: cuando el recurso compartido de archivos usa un valor inferior al de

IOPS de línea de base.
Rechazado: cuando el recurso compartido de archivos usa más que el valor de
IOPS de la línea base y en el modo de aumento.
Constante: cuando el recurso compartido de archivos usa exactamente el valor de
IOPS de línea de base, no hay créditos acumulados ni usados.
Los nuevos recursos compartidos de archivo empiezan con la cantidad total de créditos
del cubo de ráfagas. Los créditos de expansión no se acumularán si el valor de IOPS del
recurso compartido cae por debajo del valor de IOPS de la línea base debido a una
limitación por parte del servidor.
Modelo de pago por uso

Azure Files usa un modelo de facturación de pago por uso para los recursos
compartidos de archivos estándar. En un modelo de facturación de pago por uso, la
cantidad que se paga se determina según el volumen que se usa realmente, en lugar de
basarse en una cantidad aprovisionada. En un nivel alto, se paga un costo por la
cantidad de datos lógicos almacenados y, a continuación, un conjunto adicional de
transacciones en función del uso de esos datos. Un modelo de pago por uso puede ser
rentable, ya que no es necesario sobreaprovisionar para tener en cuenta los requisitos
futuros de crecimiento o rendimiento. Tampoco es necesario desaprovisionar si la carga
de trabajo y la superficie de datos varían con el tiempo. Por otro lado, un modelo de
pago por uso también puede ser difícil de planear como parte de un proceso de
presupuesto, porque este modelo se basa en el consumo del usuario final.
Diferencias en los niveles estándar

Al crear un recurso compartido de archivos estándar, puede elegir entre los siguientes
niveles: optimizado para transacciones, acceso frecuente y acceso esporádico. Los tres
niveles se almacenan en el mismo hardware de almacenamiento estándar. La principal
diferencia de estos tres niveles son los precios de almacenamiento de datos en reposo,
que son menores en los niveles de acceso esporádico, y los precios de las transacciones,
que son más altos en estos mismos niveles. Esto significa lo siguiente:
La transacción optimizada, como su nombre implica, optimiza el precio de las

cargas de trabajo de mucha transacción. La transacción optimizada tiene el precio
de almacenamiento de datos en reposo más alto, pero los precios de transacción
más bajos.
El acceso frecuente es para cargas de trabajo activas que no implican un gran
número de transacciones, y tiene un precio de almacenamiento de datos en
reposo ligeramente inferior, pero los precios de transacción son algo mayores en
comparación con la transacción optimizada. Considérelo como el punto medio
entre los niveles de transacción optimizada y acceso esporádico.
El acceso esporádico optimiza el precio de las cargas de trabajo que no tienen
mucha actividad y ofrece el precio más bajo de datos en reposo, pero el más alto
en las transacciones.
Si coloca una carga de trabajo a la que se accede con poca frecuencia en el nivel de
transacción optimizada, no pagará casi nada por las pocas horas del mes en que realiza
transacciones en el recurso compartido. Sin embargo, pagará una cantidad elevada por
los costos de almacenamiento de datos. Si tuviera que trasladar este mismo recurso
compartido al nivel de acceso esporádico, tampoco pagaría casi nada por los costos de
transacción, simplemente porque no realiza transacciones con mucha frecuencia en esta
carga de trabajo. Sin embargo, el nivel de acceso esporádico ofrece un precio de
almacenamiento de datos mucho más barato. La selección del nivel adecuado para su
caso de uso le permite reducir considerablemente los costos.
Del mismo modo, si coloca en el nivel de acceso esporádico una carga de trabajo a la
que accede con mucha frecuencia, incurrirá en muchos más costos por las
transacciones, pero pagará menos por el almacenamiento de datos. Esto puede derivar
en una situación en la que el aumento de los costos por los precios de las transacciones
sobrepasan el ahorro obtenido por el precio más reducido del almacenamiento de
datos, de tal forma que pagará más dinero en el nivel de acceso esporádico en
comparación con el de transacción optimizada. Para algunos niveles de uso, es posible
que el nivel de acceso frecuente sea el nivel más rentable y el nivel de acceso
esporádico sea más caro que el optimizado para transacciones.
El nivel de la carga de trabajo y de la actividad determinarán el nivel más rentable del

recurso compartido de archivos estándar. En la práctica, la mejor manera de elegir el
nivel más rentable es examinar el consumo de recursos real del recurso compartido
(datos almacenados, transacciones de escritura, etc.). En el caso de los recursos
compartidos de archivos estándar, se recomienda comenzar en el nivel optimizado para
transacciones durante la migración inicial a Azure Files y, luego, seleccionar el nivel
correcto en función del uso una vez completada la migración. El uso de transacciones
durante la migración no suele indicar el uso normal de las transacciones.
¿Qué son las transacciones?

Al montar un recurso compartido de archivos de Azure en un equipo mediante SMB, el
recurso compartido de archivos de Azure se expone en el equipo como si fuera
almacenamiento local. Esto significa que las aplicaciones, los scripts y otros programas
que tenga en el equipo pueden acceder a los archivos y las carpetas del recurso
compartido de archivos de Azure sin necesidad de saber que están almacenados en
Azure.
Al leer o escribir en un archivo, la aplicación que se usa hace una serie de llamadas API a
la API del sistema de archivos proporcionada por el sistema operativo. Luego, el sistema
operativo interpreta estas llamadas en transacciones de protocolo SMB, que se envían a
través de la conexión a Azure Files para completar. Una tarea que el usuario final percibe
como una sola operación, por ejemplo, leer un archivo de principio a fin, se puede
traducir en varias transacciones SMB atendidas por Azure Files.
Como principio, el modelo de facturación de pago por uso que usan los recursos
compartidos de archivos estándar factura en función del uso. Las transacciones SMB y
FileREST hechas por las aplicaciones, scripts y otros programas usados por los usuarios
representan el uso del recurso compartido de archivos y se muestran como parte de la
factura. El mismo concepto se aplica a los servicios en la nube de valor añadido que
puede agregar a su recurso compartido, como Azure File Sync o Azure Backup. Las
transacciones se agrupan en cinco categorías diferentes que tienen precios diferentes
en función de su impacto en el recurso compartido de archivos de Azure. Estas
categorías son: escritura, enumeración, lectura, otros y eliminación.
En la tabla siguiente se muestra la categorización de cada transacción:
Cubo de transacciones Operaciones de Operaciones de datos

administración
Transacciones de escritura CreateShare CopyFile

SetFileServiceProperties Create
SetShareMetadata CreateDirectory
SetShareProperties CreateFile
SetShareAcl PutRange
SnapshotShare PutRangeFromURL
RestoreShare SetDirectoryMetadata
SetFileMetadata
SetFileProperties
SetInfo
Write
PutFilePermission
Flush
SetDirectoryProperties
Transacciones de lista ListShares ListFileRanges

ListFiles
ListHandles
Cubo de transacciones Operaciones de Operaciones de datos
administración
Transacciones de lectura GetFileServiceProperties FilePreflightRequest

GetShareAcl GetDirectoryMetadata
GetShareMetadata GetDirectoryProperties
GetShareProperties GetFile
GetShareStats GetFileCopyInformation
GetFileMetadata
GetFileProperties
QueryDirectory
QueryInfo
Read
GetFilePermission
Otros/Transacciones de AcquireShareLease AbortCopyFile

protocolo BreakShareLease Cancel
ReleaseShareLease ChangeNotify
RenewShareLease Close
ChangeShareLease Echo
Ioctl
Lock
Logoff
Negotiate
OplockBreak
SessionSetup
TreeConnect
TreeDisconnect
CloseHandles
AcquireFileLease
BreakFileLease
ChangeFileLease
ReleaseFileLease
Transacciones de eliminación DeleteShare ClearRange

DeleteDirectory
DeleteFile
７ Nota
NFS 4.1 solo está disponible para los recursos compartidos de archivos premium,
que usan el modelo de facturación aprovisionado. Las transacciones no afectan a la
facturación de los recursos compartidos de archivos prémium.
Cambio entre niveles estándar
Aunque puede cambiar un recurso compartido de archivos estándar entre los tres
niveles de recursos compartidos de archivos estándar, el procedimiento recomendado
para optimizar los costos después de la migración inicial es la elección del nivel óptimo
más rentable en el que estar y permanecer allí a menos que cambie el patrón de acceso.
Esto se debe a que el cambio del nivel de un recurso compartido de archivos estándar
da como resultado costos adicionales de la siguiente manera:
Transacciones: si un recurso compartido se pasa de un nivel de acceso frecuente a

un nivel esporádico, incurrirá en la carga de transacciones de escritura del nivel
más esporádico en cada archivo del recurso compartido. Por contra, si un recurso
compartido se pasa de un nivel de acceso esporádico a un nivel frecuente, incurrirá
en la carga de transacciones de lectura del nivel más esporádico en cada archivo
del recurso compartido.
Recuperación de datos: si va a mover del nivel acceso esporádico al frecuente u

optimizado para transacciones, incurrirá en un cargo por recuperación de datos
según el tamaño de los datos movidos. Solo el nivel de acceso esporádico tiene un
cargo por recuperación de datos.
En la tabla siguiente se muestra el desglose de costos de los niveles que se van a mover:
Nivel Optimizado para Frecuente (destino) Esporádico (destino)

transacciones
(destino)
Optimizado para -- 1 transacción de 1 transacción de

transacciones escritura escritura
(origen) frecuente por esporádica por
archivo. archivo.
Frecuente 1 transacción de -- 1 transacción de

(origen) lectura frecuente escritura
por archivo. esporádica por
archivo.
Esporádico 1 transacción de 1 transacción de --

(origen) lectura lectura
esporádica por esporádica por
archivo. archivo.
Recuperación de Recuperación de
datos por GiB datos por GiB
total usado. total usado.
Aunque no hay ningún límite formal sobre la frecuencia con la que se puede cambiar el
nivel del recurso compartido de archivos, el recurso compartido tardará en hacer la
transición en función de la cantidad de datos del recurso compartido. No se puede
cambiar el nivel del recurso compartido mientras el recurso compartido de archivos
hace la transición entre niveles. Cambiar el nivel del recurso compartido de archivos no
afecta al acceso normal al recurso compartido de archivos.
Aunque no hay ningún mecanismo directo para moverse entre recursos compartidos de
archivos premium y estándar, porque están contenidos en diferentes tipos de cuenta de
almacenamiento, puede usar una herramienta de copia como Robocopy para moverse
entre recursos compartidos de archivos premium y estándar.
Elección de un nivel
Independientemente de cómo migre los datos existentes a Azure Files, se recomienda
crear inicialmente el recurso compartido de archivos en el nivel optimizado para
transacciones debido al gran número de transacciones en las que se incurre durante la
migración. Luego de completada la migración y de haber trabajado durante unos días o
semanas con un uso normal, puede conectar los recuentos de transacciones a la
calculadora de precios para averiguar qué nivel es más adecuado para la carga de
trabajo.
Dado que los recursos compartidos de archivos estándar solo muestran la información
de transacciones en el nivel de cuenta de almacenamiento, el uso de métricas de
almacenamiento para calcular qué nivel es más barato en el nivel de recurso compartido
de archivos es una ciencia imperfecta. Si es posible, se recomienda implementar solo un
recurso compartido de archivos en cada cuenta de almacenamiento para garantizar una
visibilidad completa de la facturación.
Para ver las transacciones anteriores:
1. Vaya a la cuenta de almacenamiento y seleccione Métricas en la barra de

navegación izquierda.
2. Seleccione Ámbito como nombre de la cuenta de almacenamiento, Espacio de
nombres de métricas como "Archivo", Métrica como "Transacciones" y
Agregación como "Suma".
3. Haga clic en Aplicar división.
4. Seleccione Valores como "Nombre de API". Seleccione los valores deseados en
Límite y Orden.
5. Seleccione el período de tiempo deseado.
７ Nota
Asegúrese de ver las transacciones durante un período de tiempo para obtener una
mejor idea del número medio de transacciones. Asegúrese de que el período de
tiempo elegido no se superponga con el aprovisionamiento inicial. Multiplique el
número medio de transacciones durante este período de tiempo para obtener las
transacciones estimadas durante todo un mes.
Tamaño aprovisionado o cuota, tamaño lógico

y tamaño físico
Azure Files realiza un seguimiento de tres cantidades distintas con respecto a la
capacidad del recurso compartido:
Tamaño o cuota aprovisionados: con los recursos compartidos de archivos

premium y estándar, se especifica el tamaño máximo al que puede crecer el
recurso compartido de archivos. En los recursos compartidos de archivos premium,
este valor se llama tamaño aprovisionado y la cantidad que se aprovisiona es lo
que paga, independientemente de la cantidad que realmente use. En los recursos
compartidos de archivos estándar, este valor se llama cuota y no afecta
directamente a la factura. El tamaño aprovisionado es un campo obligatorio para
los recursos compartidos de archivos prémium. En el caso de los recursos
compartidos de archivos estándar, si el tamaño aprovisionado no se especifica
directamente, el recurso compartido tendrá como valor predeterminado el valor
máximo admitido por la cuenta de almacenamiento. Serán 5 TiB o 100 TiB, en
función del tipo y la configuración de la cuenta de almacenamiento.
Tamaño lógico: El tamaño lógico de un recurso compartido de archivos o un

archivo está relacionado con el tamaño que tiene sin tener en cuenta cómo se
almacena realmente, donde se pueden aplicar optimizaciones adicionales. Una
manera de pensar en esto es que el tamaño lógico del archivo es cuántos KiB, MiB
o GiB se transferirán mediante la conexión si los copia en otra ubicación. En los
recursos compartidos de archivos premium y estándar, el tamaño lógico total del
recurso compartido de archivos es lo que se usa para el cumplimiento del tamaño
o la cuota aprovisionados. En los recursos compartidos de archivos estándar, el
tamaño lógico es la cantidad utilizada para la facturación del uso de datos en
reposo. El tamaño lógico se conoce como "tamaño" en el cuadro de diálogo de
propiedades de Windows para un archivo o carpeta y como "longitud del
contenido" para las métricas de Azure Files.
Tamaño físico: el tamaño físico del archivo está relacionado con el tamaño del
archivo como codificado en el disco. Esto puede alinearse con el tamaño lógico del
archivo, o puede ser menor, en función de cómo haya escrito el archivo el sistema
operativo. Un motivo común para que el tamaño lógico y el tamaño físico sean
diferentes se encuentra en el uso de archivos dispersos. El tamaño físico de los
archivos del recurso compartido se usa para la facturación de instantáneas, aunque
los intervalos asignados se compartan entre instantáneas si no cambian
(almacenamiento diferencial). Para más información sobre cómo se facturan las
instantáneas en Azure Files, consulte Instantáneas.
Instantáneas
Azure Files admite instantáneas, que son similares a las instantáneas de volumen (VSS)
en el servidor de archivos Windows. Las instantáneas siempre son diferenciales del
recurso compartido activo y entre sí, lo que significa que siempre paga solo por lo que
es diferente en cada instantánea. Para más información sobre las instantáneas de
recursos compartidos, consulte Información general de las instantáneas de recurso
compartido de Azure Files.
Las instantáneas no cuentan para los límites de tamaño del recurso compartido de
archivos, aunque está limitado a un número específico de instantáneas. Para ver los
límites actuales de instantáneas, consulte Objetivos de escala de recursos compartidos
Las instantáneas siempre se facturan en función del uso diferencial del almacenamiento
de cada instantánea; sin embargo, esto tiene un aspecto ligeramente diferente entre los
recursos compartidos de archivos premium y los recursos compartidos de archivos
estándar:
En los recursos compartidos de archivos premium, las instantáneas se facturan con

su propio medidor de instantáneas, que tiene un precio reducido sobre el precio
del almacenamiento aprovisionado. Esto significa que verá un elemento de línea
independiente en la factura, que representa las instantáneas de recursos
compartidos de archivos prémium para cada cuenta de almacenamiento de tipo
FileStorage en la factura.
En los recursos compartidos de archivos estándar, las instantáneas se facturan

como parte del medidor normal del almacenamiento usado, aunque también se le
factura por el costo diferencial de la instantánea. Esto significa que no verá un
elemento de línea independiente en la factura, que representa las instantáneas
para cada cuenta de almacenamiento estándar que contenga recursos
compartidos de archivos de Azure. Esto también significa que el uso diferencial de
instantáneas se tiene en cuenta para las reservas adquiridas para recursos
compartidos de archivos estándar.
Los servicios de valor añadido para Azure Files pueden usar instantáneas como parte de
su propuesta de valor. Consulte Servicios de valor añadido para más información sobre
cómo se usan las instantáneas.
Servicios de valor añadido

Al igual que las soluciones de almacenamiento locales que ofrecen características o
integraciones de productos propios y de terceros para añadir valor a los recursos
compartidos de archivos hospedados, Azure Files ofrece puntos de integración para
productos propios y de terceros para su integración con los recursos compartidos de
archivos propiedad del cliente. Aunque estas soluciones pueden proporcionar un valor
adicional considerable para Azure Files, debe tener en cuenta los costos extra que
agregan estos servicios al costo total de una solución de Azure Files.
Los costos se dividen en tres grupos:
Costos de licencias del servicio de valor añadido. Estos pueden tener la forma de
un costo fijo por cliente, usuario final (a veces llamado "costo principal"), recurso
compartido de archivos o cuenta de almacenamiento de Azure. También pueden
basarse en unidades de uso del almacenamiento, como un costo fijo para cada
fragmento de datos de 500 GiB en el recurso compartido de archivos.
Costos de transacciones del servicio de valor añadido. Algunos servicios de valor

añadido tienen su propio concepto de transacciones, distinto de lo que Azure Files
ve como una transacción. Estas transacciones se mostrarán en la factura en los
cargos del servicio de valor añadido; sin embargo, están directamente relacionados
con cómo se usa el servicio de valor añadido con el recurso compartido de
archivos.
Costos de Azure Files por usar un servicio de valor añadido. Azure Files no cobra
directamente a los clientes los costos por agregar servicios de valor añadido, pero
como parte de agregar valor al recurso compartido de archivos de Azure, el
servicio de valor añadido podría aumentar los costos que ve en el recurso
compartido de archivos de Azure. Esto es fácil de ver con los recursos compartidos
de archivos estándar, ya que los recursos compartidos de archivos estándar tienen
un modelo de pago por uso con cargos por transacciones. Si el servicio de valor
añadido realiza transacciones en el recurso compartido de archivos en su nombre,
se mostrarán en la factura de transacciones de Azure Files aunque no haya hecho
directamente esas transacciones usted mismo. Esto también se aplica a los
recursos compartidos de archivos premium, aunque puede ser menos notable. Las
transacciones adicionales en los recursos compartidos de archivos prémium de los
servicios de valor añadido cuentan para las cifras de IOPS aprovisionadas, lo que
significa que los servicios de valor añadido pueden requerir el aprovisionamiento
de más almacenamiento para tener suficientes IOPS o rendimiento disponibles
para la carga de trabajo.
Al calcular el costo total de propiedad del recurso compartido de archivos, debe tener
en cuenta los costos de Azure Files y de todos los servicios de valor añadido que le
gustaría usar con Azure Files.
Hay varios servicios de valor añadido propios y de terceros. En este documento, se trata
un subconjunto de los servicios propios comunes que usan los clientes con los recursos
compartidos de archivos de Azure. Para obtener información sobre los servicios que no
aparecen aquí, consulte la página de precios de ese servicio.
Azure File Sync

Azure File Sync es un servicio de valor añadido para Azure Files que sincroniza uno o
varios recursos compartidos de archivos locales Windows con un recurso compartido de
archivos de Azure. Dado que el recurso compartido de archivos de Azure en la nube
tiene una copia completa de los datos en un recurso compartido de archivos
sincronizado que está disponible en el entorno local, puede transformar el servidor de
archivos Windows local en una memoria caché del recurso compartido de archivos de
Azure para reducir la superficie local. Para más información, consulte ¿Qué es Azure File
Sync?
Al considerar el costo total de propiedad de una solución implementada con Azure File
Sync, debe tener en cuenta los siguientes aspectos de costos:
Costos operativos y de capital de los servidores de archivos Windows con uno o

varios puntos de conexión de servidor. Azure File Sync como solución de
replicación es independiente de dónde están los servidores de archivos Windows
que se sincronizan con Azure Files, podrían hospedarse en el entorno local, en una
máquina virtual de Azure o, incluso, en otra nube. A menos que utilice Azure File
Sync con un servidor de archivos Windows hospedado en una máquina virtual de
Azure, los costos de capital (es decir, los costos iniciales de hardware de la
solución) y los costos operativos (es decir, el costo de personal y de electricidad,
electricidad, etc.) no formarán parte de la factura de Azure, pero seguirán siendo
una parte del costo total de propiedad. Debe tener en cuenta la cantidad de datos
que necesita almacenar en caché en el entorno local, el número de CPU y la
cantidad de memoria que necesitan los servidores de archivos Windows para
hospedar cargas de trabajo de Azure File Sync (para más información, consulte los
recursos recomendados del sistema) y otros costos específicos de la organización
que pueda tener.
Costo de licencias por servidor de los servidores registrados con Azure File Sync.
Si desea utilizar Azure File Sync con un servidor de archivos Windows específico,
primero debe registrarlo con el recurso de Azure de Azure File Sync, el servicio de
sincronización de almacenamiento. Cada servidor que registra después del primer
servidor tiene una tarifa plana mensual. Si bien esta tarifa es muy pequeña, es un
componente de la factura que se debe tener en cuenta. Para ver el precio actual de
la tarifa de registro de los servidores de la región deseada, consulte la sección de
File Sync en la página de precios de Azure Files .
Costos de Azure Files. Como Azure File Sync es una solución de sincronización
para Azure Files, hará que consuma recursos de Azure Files. Algunos de estos
recursos, como el consumo de almacenamiento, son relativamente obvios,
mientras que otros, como el uso de transacciones y instantáneas, pueden no serlo.
Para la mayoría de los clientes, recomendamos utilizar recursos compartidos de
archivos estándar con Azure File Sync, aunque Azure File Sync es totalmente
compatible con los recursos compartidos de archivos premium si se desea.
Uso del almacenamiento. Azure File Sync replicará los cambios que haya hecho
en la ruta de acceso del servidor de archivos Windows que especificó en el
punto de conexión de servidor al recurso compartido de archivos de Azure, lo
que hace que se consuma almacenamiento. En los recursos compartidos de
archivos estándar, esto significa que agregar archivos o aumentar el tamaño de
los existentes en los puntos de conexión de servidor hará que aumenten los
costos de almacenamiento, ya que se replicarán los cambios. En el caso de los
recursos compartidos de archivos premium, los cambios consumirán espacio
aprovisionado. Es su responsabilidad aumentar periódicamente el
aprovisionamiento según sea necesario para tener en cuenta el crecimiento del
recurso compartido de archivos.
Uso de instantáneas. Azure File Sync toma instantáneas en el nivel de recurso

compartido y de archivo como parte del uso normal. El uso de instantáneas
siempre es diferencial, pero puede contribuir considerablemente a la factura
total de Azure Files.
Transacciones de renovación. A medida que los archivos cambian en los puntos

de conexión del servidor, los cambios se cargan en el recurso compartido en la
nube, lo que genera transacciones. Cuando se habilita la nube por niveles, se
generan transacciones adicionales para administrar los archivos en niveles,
incluida la E/S que se está produciendo en los archivos en niveles, además de
los costos de salida. La cantidad y el tipo de transacciones son difíciles de
predecir debido a la tasa de renovación y la eficacia de la memoria caché, pero
puede usar los patrones de transacción anteriores para calcular los costos
futuros si cree que el uso futuro será similar al actual.
Transacciones de enumeración en la nube. Azure File Sync enumera el recurso

compartido de archivos de Azure en la nube una vez al día para detectar los
cambios que se realizaron directamente en el recurso compartido para que
puedan sincronizarse con los puntos de conexión del servidor. Este examen
genera transacciones que se facturan a la cuenta de almacenamiento a una tasa
de una transacción ListFiles por directorio al día. Puede poner este número
en la calculadora de precios para calcular el costo del examen.
 Sugerencia
Si no está seguro de cuántas carpetas tiene, consulte la herramienta TreeSize

de JAM Software GmbH.
Para optimizar los costos de Azure Files con Azure File Sync, debe tener en cuenta el
nivel del recurso compartido de archivos. Para más información sobre cómo elegir el
nivel de cada recurso compartido de archivos, consulte Elección de un nivel.
Si va a migrar a Azure File Sync desde StorSimple, consulte Comparación de los costos
de StorSimple con Azure File Sync.
Azure Backup
Azure Backup proporciona una solución de copia de seguridad sin servidor para Azure
Files que se integra a la perfección con los recursos compartidos de archivos, así como
con otros servicios de valor añadido, como Azure File Sync. Azure Backup para Azure
Files es una solución de copia de seguridad basada en instantáneas que ofrece un
mecanismo de programación para hacer instantáneas automáticamente según una
programación definida por el administrador. También brinda una interfaz fácil de usar
para restaurar archivos o carpetas eliminados o todo el recurso compartido a un
momento dado. Para más información sobre Azure Backup para Azure Files, consulte
Acerca de la copia de seguridad de recursos compartidos de archivos de Azure.
Al considerar los costos de usar Azure Backup para hacer copias de seguridad de los
recursos compartidos de archivos de Azure, tenga en cuenta lo siguiente:
Costo de licencias de instancias protegidas para los datos de los recursos

compartidos de archivos de Azure. Azure Backup cobra un costo de licencia de
instancia protegida por cada cuenta de almacenamiento que contiene recursos
compartidos de archivos de Azure de los que se ha hecho una copia de seguridad.
Una instancia protegida se define como 250 GiB de almacenamiento de recursos
compartidos de archivos de Azure. Las cuentas de almacenamiento que contienen
menos de 250 GiB de almacenamiento de recursos compartidos de archivos de
Azure están sujetas a un costo fraccionario de instancia protegida. Para más
información, consulte Precios de Azure Backup . Tenga en cuenta que tiene que
seleccionar Azure Files en la lista de servicios que Azure Backup puede proteger.
Costos de Azure Files. Azure Backup aumenta los costos de Azure Files de las
siguientes maneras:
Costos diferenciales de las instantáneas de recursos compartidos de archivos

de Azure. Azure Backup automatiza la toma de instantáneas de recursos
compartidos de archivos de Azure según una programación definida por el
administrador. Las instantáneas siempre son diferenciales; sin embargo, el costo
adicional agregado al total de la factura depende del período de tiempo que se
conservan las instantáneas y de la cantidad de renovación en el recurso
compartido de archivos durante ese tiempo. Esto determina cuánto difiere la
instantánea del recurso compartido de archivos activo y, por tanto, la cantidad
de datos adicionales que almacena Azure Files.
Costos de transacción de las operaciones de restauración. Las operaciones de

restauración desde la instantánea al recurso compartido activo provocarán
transacciones. En el caso de los recursos compartidos de archivos estándar, esto
significa que las lecturas de instantáneas y las escrituras de las restauraciones se
facturarán como transacciones normales del recurso compartido de archivos. En
el caso de los recursos compartidos de archivos premium, estas operaciones se
tienen en cuenta para las IOPS aprovisionadas para el recurso compartido de
archivos.
Microsoft Defender para Storage

Microsoft Defender proporciona compatibilidad con Azure Files como parte de su
producto Microsoft Defender para Storage. Microsoft Defender para Storage detecta
intentos inusuales y potencialmente perjudiciales de acceder a los recursos compartido
de archivos de Azure mediante SMB o FileREST o de vulnerarlos. Microsoft Defender
para Storage está habilitado en el nivel de suscripción para todos los recursos
compartidos de archivos de las cuentas de almacenamiento de esa suscripción.
Microsoft Defender para Storage no admite funcionalidades antivirus para recursos

El costo principal de Microsoft Defender para Storage es un conjunto adicional de
costos de transacciones que el producto cobra sobre las transacciones que se realizan
en el recurso compartido de archivos de Azure. Aunque estos costos se basan en las
transacciones en las que se incurre en Azure Files, no forman parte de la facturación de
Azure Files, sino que forman parte de los precios de Microsoft Defender. Microsoft
Defender para Storage cobra una tasa de transacciones incluso en los recursos
compartidos de archivos premium, en los que Azure Files incluye las transacciones como
parte del aprovisionamiento de IOPS. La tarifa de transacciones actual se puede
encontrar en la página de precios de Microsoft Defender for Cloud en la fila de la
tabla de Microsoft Defender para Storage.
Los recursos compartidos de archivos con gran cantidad de transacciones incurrirán en

costos significativos al usar Microsoft Defender para Storage. En función de estos
costos, es posible que desee no participar en Microsoft Defender para Storage para
cuentas de almacenamiento específicas. Para más información, consulte Exclusión de
una cuenta de almacenamiento de las protecciones de Microsoft Defender para Storage.
Consulte también
Página de precios de Azure Files
Planeamiento de una implementación de Azure Files y Planeamiento de una
implementación de Azure File Sync
Creación de un recurso compartido de archivos e Implementación de Azure File
Sync
Reemplace o amplíe los servidores de
archivos de Windows por Azure Files y
Azure File Sync
Artículo • 22/03/2023
En este artículo se explica cómo puede usar Azure Files y Azure File Sync para
reemplazar o ampliar los servidores de archivos de Windows locales para reducir el
costo total de propiedad (TCO), aumentar la flexibilidad y simplificar la protección de
datos y el control de acceso. Azure Files tiene sus orígenes en el rol de servidor de
archivos de Windows, lo que lo convierte en una excelente opción al migrar servidores
de archivos de Windows a la nube.
La mayoría de los clientes toman uno de los dos enfoques de implementación:
Implementación solo en la nube: Migre servidores de archivos locales a un

recurso compartido de archivos de Azure SMB totalmente administrado (o varios
recursos compartidos de archivos).
Implementación híbrida: Use Azure File Sync para sincronizar los servidores de
archivos de Windows existentes con un recurso compartido de archivos de Azure
SMB. Opcionalmente, use la nube por niveles para escalar los datos de archivos en
la nube mientras se activan servidores locales en cachés locales para archivos
activos.
Se aplica a
Reducción del TCO con recursos compartidos

de archivos totalmente administrados
Hay más que el TCO del recurso compartido de archivos que el precio por GiB de
almacenamiento. Al centralizar los recursos compartidos de archivos en Azure, puede
reducir el TCO de muchas maneras:
Para lograr un mejor uso del almacenamiento, no tenga que aprovisionar por
encima de la capacidad del recurso compartido de archivos. Con Azure Files,
puede cambiar rápidamente el tamaño del recurso compartido sin tiempo de
inactividad.
Elimine el trabajo asociado a la adquisición, configuración y mantenimiento de

hardware. Con Azure Files, se incluyen la resistencia de almacenamiento, la
redundancia y el mantenimiento, y no hay revisiones ni actualizaciones para
administrar.
Los clientes que dependen de tecnologías de replicación de recursos compartidos

completos, como DFS-R, pueden reducir los costos centralizando una copia
completa en un recurso compartido de archivos de Azure y usando Azure File Sync
para almacenar en caché los archivos activos localmente.
Las instantáneas diferenciales e integración con Azure Backup ofrecen protección

de datos económica.
Elija entre varios niveles de almacenamiento, desde SSD de baja latencia premium
hasta almacenamiento esporádico rentable, lo que le permite elegir el nivel que
mejor se adapte a la carga de trabajo.
Azure Files descuentos en reservas permiten ahorrar hasta un 36 % en el

almacenamiento confirmado previamente.
Para más información sobre cómo se facturan los recursos compartidos de archivos de
Azure y cómo puede reducir el TCO, consulte Descripción de la facturación de Azure
Files.
Amplia compatibilidad con servidores de

archivos de Windows
La mayoría de las funcionalidades principales del sistema de archivos y SMB en el rol de
servidor de archivos de Windows también existen en Azure Files, como:
Listas de control de acceso (ACL de Windows)

Integración de Active Directory
Cifrado de SMB
Conmutación por error transparente
Bloqueos de archivos
SMB multicanal
Actualmente, Azure Files no admite un conjunto limitado de características compatibles
con SMB y NTFS.
Implementación flexible y acceso híbrido

Azure Files se ha creado para el acceso híbrido y ofrece opciones de implementación
flexibles, incluida la migración sin tiempo de inactividad desde servidores de archivos de
Windows. Puede conectarse a un recurso compartido de archivos de Azure desde una
variedad de clientes o desde máquinas virtuales (VM) o contenedores. Puede conectarse
desde cualquier lugar a través del tráfico cifrado de SMB 3.x, ya sea a través de Internet
o a través de VPN/ExpressRoute. Si desea mantener el rendimiento local, puede usar
Azure File Sync para almacenar en caché los archivos activos o una copia completa del
recurso compartido de archivos de Azure.
Mover datos de servidores de archivos de Windows a Azure Files es fácil y puede

hacerlo en segundo plano sin interrumpir el acceso del usuario. Simplemente instale
Azure File Sync en el servidor de archivos, conéctese a un recurso compartido de
archivos de Azure e inicie la sincronización.
Al migrar a Azure Files, ninguno de los vínculos de ruta de acceso de archivo debe
interrumpirse. Puede usar espacios de nombres DFS y redirigir a los usuarios a Azure
Files. Si va a extender un servidor de archivos de Windows existente a Azure mediante
Azure File Sync, los usuarios seguirán accediendo a sus archivos mediante las mismas
rutas de acceso de archivo.

Azure File Sync puede sincronizar y almacenar en caché el recurso compartido de

archivos de Azure en cualquier lugar donde pueda instalar Windows Server. Como se
muestra en el diagrama, puede crear cachés regionales de los servidores de archivos en
diferentes regiones de Azure. Puede almacenar en caché archivos locales, en los centros
de datos o en una máquina virtual en nubes de terceros. Más información en el tutorial
Extensión de servidores de archivos de Windows con Azure File Sync.
Protección de datos simplificada y control de

acceso
Con Azure Files se beneficia de la seguridad multicapa proporcionada por Microsoft en
centros de datos físicos, infraestructura y operaciones en Azure. Proporcionamos varias
opciones de redundancia de datos, como local, regional o global. Las instantáneas
diferenciales y la administración de instantáneas de Azure Backup simplificar la
protección de datos, mientras que Azure File Sync ofrece una variedad de opciones de
recuperación ante desastres. Incluso puede proteger a los usuarios de la eliminación
accidental de un archivo o recurso compartido a través de la eliminación temporal.
El control de acceso funciona igual que los servidores de archivos de Windows. Puede
usar la autenticación basada en identidades e integrar recursos compartidos de archivos
de Azure SMB con el entorno de Active Directory local o Azure AD, y controlar el acceso
de nivel de recurso compartido y de directorio/archivo, así como privilegios de
administrador.
Consulte también
Migración a Azure Files
Consideraciones de redes para Azure Files
Cifrado de Azure Storage para datos en
reposo
Artículo • 25/03/2023
Azure Storage usa el cifrado del servicio (SSE) para cifrar automáticamente los datos
cuando se guardan en la nube. El cifrado de Azure Storage protege los datos y le ayuda
a satisfacer los requisitos de cumplimiento normativo y seguridad de la organización.
Microsoft recomienda usar el cifrado del servicio para proteger los datos en la mayoría
de los escenarios. Sin embargo, las bibliotecas cliente de Azure Storage para Blob
Storage y Queue Storage también proporcionan cifrado de cliente para los clientes que
necesitan cifrar los datos en el cliente. Para obtener más información, consulte la sección
sobre el cifrado de cliente para blobs y colas.
Acerca del cifrado del servicio de Azure Storage

Los datos de Azure Storage se cifran y descifran de forma transparente mediante el
cifrado AES de 256 bits, uno de los cifrados de bloques más sólidos que hay
disponibles, y son compatibles con FIPS 140-2. El cifrado de Azure Storage es similar al
cifrado de BitLocker en Windows.
El cifrado de Azure Storage está habilitado para todas las cuentas de almacenamiento,
incluidas las cuentas de almacenamiento clásicas y las de Resource Manager. El cifrado
de Azure Storage no se puede deshabilitar. Como los datos están protegidos de forma
predeterminada, no es necesario modificar el código o las aplicaciones para aprovechar
el cifrado de Azure Storage.
Los datos de una cuenta de almacenamiento se cifran independientemente de su nivel

de rendimiento (Estándar o Premium), del nivel de acceso (frecuente o esporádico) o del
modelo de implementación (Azure Resource Manager o clásico). Todos los blobs en
bloques nuevos y existentes, los blobs anexos y los blobs en páginas se cifran, incluidos
los blobs en el nivel de archivo. Todas las opciones de redundancia de Azure Storage
admiten el cifrado, y todos los datos de las regiones primaria y secundaria se cifran
cuando la replicación geográfica está habilitada. Se cifran todos los recursos de Azure
Storage, incluidos los blobs, los discos, los archivos, las colas y las tablas. También se
cifran todos los metadatos de objetos.
No hay ningún costo adicional para el cifrado de Azure Storage.

Para más información sobre de los módulos criptográficos subyacentes al cifrado de
Azure Storage, vea API de criptografía: última generación.
Para más información sobre el cifrado y la administración de claves de Azure Managed

Disks, consulte Cifrado del lado servidor de Azure Managed Disks.
Información sobre la administración de claves

de cifrado
Los datos de una cuenta de almacenamiento nueva se cifran con claves administradas
por Microsoft de manera predeterminada. Puede seguir confiando en las claves
administradas por Microsoft para el cifrado de los datos, o puede administrar el cifrado
con sus propias claves. Si opta por administrar el cifrado con sus propias claves, tiene
dos opciones. Puede usar cualquiera de los tipos de administración de claves, o ambos:
Puede especificar una clave administrada por el cliente que se usará para cifrar y
descifrar datos en Blob Storage y en Azure Files.1,2 Las claves administradas por el
cliente se deben almacenar en Azure Key Vault o en el modelo de seguridad de
hardware (HSM) administrado de Azure Key Vault. Para más información sobre las
claves administradas por el cliente, consulte Uso de claves administradas por el
cliente para el cifrado de Azure Storage.
Puede especificar una clave proporcionada por el cliente en las operaciones de Blob
Storage. Un cliente que realiza una solicitud de lectura o escritura en Blob Storage
puede incluir una clave de cifrado en la solicitud para tener un control detallado
sobre el cifrado y el descifrado de los datos de blob. Para más información sobre
las claves proporcionadas por el cliente, consulte Especificación de una clave de
cifrado en una solicitud a Blob Storage.
De forma predeterminada, una cuenta de almacenamiento está cifrada con una clave
cuyo ámbito es toda la cuenta de almacenamiento. Los ámbitos de cifrado permiten
administrar el cifrado con una clave cuyo ámbito es un contenedor o un blob individual.
Se pueden usar ámbitos de cifrado para crear límites seguros entre los datos que
residen en la misma cuenta de almacenamiento, pero que pertenecen a clientes
distintos. Los ámbitos de cifrado pueden usar claves administradas por Microsoft o
claves administradas por el cliente. Para obtener más información sobre los ámbitos de
cifrado, vea Ámbitos de cifrado para Blob Storage.
En la tabla siguiente se comparan las opciones de administración de claves para el

cifrado de Azure Storage.
Parámetro de Claves administradas Claves administradas Claves
administración de por Microsoft por el cliente proporcionadas
claves por el cliente
Operaciones de Azure Azure Azure

cifrado y descifrado
Servicios de Azure All Blob Storage, Azure Blob Storage

Storage admitidos Files1,2
Almacenamiento de Almacén de claves de Azure Key Vault o HSM Propio almacén de

claves Microsoft de Key Vault claves del cliente
Responsabilidad de Microsoft Customer Customer

la rotación de claves
Control de claves Microsoft Customer Customer
Ámbito de clave Cuenta (valor Cuenta (valor N/D

predeterminado), predeterminado),
contenedor o blob contenedor o blob
1
Para obtener información sobre cómo crear una cuenta que admita el uso de claves
administradas por el cliente con Queue Storage, consulte Creación de una cuenta que
admita las claves administradas por el cliente para colas.
2
Para obtener información sobre cómo crear una cuenta que admita el uso de claves
administradas por el cliente con Table Storage, consulte Creación de una cuenta que
admita las claves administradas por el cliente para tablas.
７ Nota
Las claves administradas por Microsoft se rotan correctamente según los requisitos
de cumplimiento. Si tiene requisitos específicos de rotación de claves, Microsoft
recomienda que se cambie a las claves administradas por el cliente para que pueda
administrar y auditar la rotación usted mismo.
Cifrado doble de los datos con cifrado de

infraestructura
Los clientes que necesitan niveles altos de seguridad de que sus datos están seguros
también pueden habilitar el cifrado AES de 256 bits en el nivel de infraestructura de
Azure Storage. Cuando se habilita el cifrado de la infraestructura, los datos de las
cuentas de almacenamiento se cifran dos veces, una vez en el nivel de servicio y otra en
el nivel de infraestructura, con dos algoritmos de cifrado y dos claves diferentes. El
doble cifrado de los datos de Azure Storage sirve de protección en caso de que uno de
los algoritmos de cifrado o las claves puedan estar en peligro. En este escenario, la capa
adicional de cifrado también protege los datos.
El cifrado en el nivel de servicio admite el uso tanto de claves administradas por

Microsoft como de claves administradas por el cliente con Azure Key Vault. El cifrado en
el nivel de infraestructura se basa en las claves administradas por Microsoft y siempre
usa una clave independiente.
Para más información sobre cómo crear una cuenta de almacenamiento que habilite el
cifrado de infraestructura, consulte Creación de una cuenta de almacenamiento con el
cifrado de infraestructura habilitado para poder realizar el cifrado doble de datos.
Cifrado de cliente para blobs y colas

Las bibliotecas cliente de Azure Blob Storage para .NET, Java y Python admiten el cifrado
de datos dentro de las aplicaciones cliente antes de cargarlos en Azure Storage y el
descifrado de datos mientras estos se descargan al cliente. Las bibliotecas cliente de
Queue Storage para .NET y Python también admiten el cifrado del lado cliente.
７ Nota
Considere la posibilidad de usar las características de cifrado del servicio

proporcionadas por Azure Storage para proteger los datos, en lugar del cifrado de
cliente.
Las bibliotecas cliente de Blob Storage y Queue Storage usan AES para cifrar los datos
del usuario. Hay dos versiones del cifrado de cliente disponibles en las bibliotecas
cliente:
La versión 2 usa el modo Galois/contador (GCM) con AES. Los SDK de Blob
Storage y Queue Storage admiten el cifrado del lado cliente con v2.
La versión 1 usa el modo Cipher Block Chaining (CBC) con AES. Los SDK de Blob
Storage, Queue Storage y Table Storage admiten el cifrado del lado cliente con v1.
２ Advertencia
El uso de la versión 1 del cifrado de cliente no se recomienda debido a una

vulnerabilidad de seguridad en la implementación de la biblioteca cliente del modo
CBC. Para más información sobre esta vulnerabilidad de seguridad, consulte
Actualización de Azure Storage del cifrado del lado cliente en el SDK para
abordar la vulnerabilidad de seguridad . Si actualmente usa la versión 1, se
recomienda actualizar la aplicación para que use la versión 2 del cifrado del lado de
cliente y migrar los datos.
El SDK de Azure Table Storage solo admite la versión 1 del cifrado de cliente. No se
recomienda usar el cifrado de cliente con Table Storage.
En la tabla siguiente se muestra qué bibliotecas cliente admiten qué versiones del
cifrado de cliente y se proporcionan instrucciones para migrar a la versión 2 del cifrado
de cliente.
Biblioteca de cliente Versión del Migración recomendada Instrucciones

cifrado de adicionales
cliente
compatible
Bibliotecas cliente de 2,0 Actualice el código para usar la Cifrado de

Blob Storage para .NET versión 2 del cifrado de cliente. cliente para
(versión 12.13.0 y 1.0 (se blobs
posteriores), Java conserva Descargue los datos cifrados para
(versión 12.18.0 y únicamente descifrarlos y, a continuación, vuelva
posteriores) y Python por a cifrarlos con la versión 2 del
(versión 12.13.0 y compatibilidad cifrado de cliente.
posteriores) con versiones
anteriores)
Biblioteca cliente de 1.0 (no se Actualice la aplicación para que use Cifrado de
Blob Storage para .NET recomienda) una versión del SDK de Blob cliente para
(versión 12.12.0 y Storage que admita la versión 2 del blobs
anteriores), Java (versión cifrado de cliente. Consulte la
12.17.0 y anteriores) y sección sobre la matriz de
Python (versión 12.12.0 compatibilidad del SDK para el
y anteriores) cifrado de cliente para obtener
detalles.
Actualice el código para usar la

versión 2 del cifrado de cliente.
Descargue los datos cifrados para

descifrarlos y, a continuación, vuelva
a cifrarlos con la versión 2 del
cifrado de cliente.
Biblioteca de cliente Versión del Migración recomendada Instrucciones
cifrado de adicionales
cliente
compatible
Biblioteca cliente de 2,0 Actualice el código para usar la Cifrado de

Queue Storage para versión 2 del cifrado de cliente. cliente para
.NET (versión 12.11.0 y 1.0 (se colas
posteriores) y Python conserva
(versión 12.4 y únicamente
posteriores) por
compatibilidad
con versiones
anteriores)
Biblioteca cliente de 1.0 (no se Actualice la aplicación para usar una Cifrado de
Queue Storage para recomienda) versión de la versión del SDK de cliente para
.NET (versión 12.10.0 y Queue Storage que admita la colas
anteriores) y Python versión 2 del cifrado de cliente.
(versión 12.3.0 y Consulte la sección sobre la matriz
anteriores) de compatibilidad del SDK para el
cifrado de cliente
Actualice el código para usar la

versión 2 del cifrado de cliente.
Biblioteca cliente de 1.0 (no se No disponible. N/D

Table Storage para .NET, recomienda)
Java y Python
Pasos siguientes
¿Qué es Azure Key Vault?
Claves administradas por el cliente para el cifrado de Azure Storage
Ámbitos de cifrado para Blob Storage
Especificación de una clave de cifrado en una solicitud a Blob Storage
Claves administradas por el cliente para
el cifrado de Azure Storage
Artículo • 11/05/2023
Puede usar su propia clave de cifrado para proteger los datos de la cuenta de
almacenamiento. Cuando se especifica una clave administrada por el cliente, esa clave
se usa para proteger y controlar el acceso a la clave que cifra los datos. Las claves
administradas por el cliente ofrecen más flexibilidad para administrar controles de
acceso.
Debe usar uno de los siguientes almacenes de claves de Azure para almacenar las claves
administradas por el cliente:
Azure Key Vault

Módulo de seguridad de hardware (HSM) administrado por Azure Key Vault
Puede crear sus propias claves y almacenarlas en un almacén de claves o HSM

administrado, o bien puede usar las API de Azure Key Vault para generarlas. La cuenta
de almacenamiento y el almacén de claves o HSM administrado pueden estar en
diferentes inquilinos, regiones y suscripciones de Azure Active Directory (Azure AD).
７ Nota
Azure Key Vault y HSM administrado por Azure Key Vault admiten las mismas API e
interfaces de administración para la configuración de claves administradas por el
cliente. Cualquier acción que se admita para Azure Key Vault también se admite
para HSM administrado por Azure Key Vault.
Acerca de las claves administradas por el

cliente
En el diagrama siguiente se muestra cómo Azure Storage usa Azure AD y un almacén de
claves o HSM administrado para hacer solicitudes mediante la clave administrada por el
cliente:
En la lista siguiente se explican los pasos numerados del diagrama:
1. Un administrador de Azure Key Vault concede permisos para las claves de cifrado a
una identidad administrada. La identidad administrada puede ser una identidad
administrada asignada por el usuario que haya creado y administrado, o bien una
identidad administrada asignada por el sistema asociada a la cuenta de
almacenamiento.
2. Un administrador de Azure Storage configura el cifrado con una clave
administrada por el cliente para la cuenta de almacenamiento.
3. Azure Storage usa la identidad administrada a la que el administrador de Azure
Key Vault concedió permisos en el paso 1 para autenticar el acceso a Azure
Key Vault a través de Azure AD.
4. Azure Storage encapsula la clave de cifrado de la cuenta con la clave administrada
por el cliente en Azure Key Vault.
5. En operaciones de lectura y escritura, Azure Storage envía solicitudes a Azure Key
Vault para desencapsular la clave de cifrado de la cuenta con el fin de realizar
operaciones de cifrado y descifrado.
La identidad administrada asociada a la cuenta de almacenamiento debe tener estos

permisos como mínimo para acceder a una clave administrada por el cliente en
Azure Key Vault:
wrapkey
unwrapkey
get
Para obtener más información sobre los permisos de clave, consulte Tipos de claves,
algoritmos y operaciones.
Azure Policy proporciona una directiva integrada para requerir que las cuentas de
almacenamiento usen claves administradas por el cliente para cargas de trabajo de Blob
Storage y Azure Files. Para obtener más información, consulte la sección
Almacenamiento de las definiciones de directivas integradas de Azure Policy.
Claves administradas por el cliente para colas y
tablas
Los datos almacenados en Queue y Table Storage no se protegen automáticamente
mediante una clave administrada por el cliente cuando se habilitan las claves
administradas por el cliente para la cuenta de almacenamiento. Opcionalmente, puede
configurar estos servicios para que se incluyan en esta protección en el momento de
crear la cuenta de almacenamiento.
Para más información sobre cómo crear una cuenta de almacenamiento que admita el
uso de claves administradas por el cliente para colas y tablas, consulte Creación de una
cuenta que admita las claves administradas por el cliente para tablas y colas.
Los datos en Blob Storage y Azure Files siempre están protegidos por claves
administradas por el cliente cuando se han configurado las claves administradas por el
cliente para la cuenta de almacenamiento.
Habilitación de claves administradas por el

cliente para una cuenta de almacenamiento
Al configurar claves administrada por el cliente para una cuenta de almacenamiento,
Azure Storage encapsula la clave de cifrado de la cuenta con la clave administrada por el
cliente en el almacén de claves o HSM administrado asociado. La protección de la clave
de cifrado raíz cambiará, pero los datos de la cuenta de Azure Storage seguirán cifrados
en todo momento. No se requiere ninguna acción adicional por su parte para
asegurarse de que los datos permanezcan cifrados. La protección de las claves
administradas por el cliente surte efecto de manera inmediata.
Puede cambiar entre las claves administradas por el cliente y las claves administradas
por Microsoft en cualquier momento. Para obtener más información sobre las claves
administradas por Microsoft, vea Información sobre la administración de claves de
cifrado.
Requisitos del almacén de claves

El almacén de claves o HSM administrado que almacena la clave debe tener habilitada la
eliminación temporal y la protección de purga. El cifrado de almacenamiento de Azure
admite claves RSA y RSA-HSM de los tamaños 2048, 3072 y 4096. Para obtener más
información sobre las claves, consulte Acerca de las claves.
El uso de un almacén de claves o HSM administrado tiene costos asociados. Para más
información, vea Precios de Key Vault .
Claves administradas por el cliente con un almacén de

claves en el mismo inquilino
Puede configurar claves administradas por el cliente con el almacén de claves y la
cuenta de almacenamiento en el mismo inquilino o en distintos inquilinos de Azure AD.
Para aprender a configurar el cifrado de Azure Storage con claves administradas por el
cliente cuando el almacén de claves y la cuenta de almacenamiento están en los mismos
inquilinos, consulte uno de los siguientes artículos:
Configuración de claves administradas por el cliente en un almacén de claves de

Azure para una nueva cuenta de almacenamiento
Azure para una cuenta de almacenamiento existente
Al habilitar las claves administradas por el cliente con un almacén de claves en el mismo
inquilino, debe especificar una identidad administrada que se usará para autorizar el
acceso al almacén de claves que contiene la clave. La identidad administrada puede ser
una identidad administrada asignada por el usuario o asignada por el sistema:
Si configura claves administradas por el cliente al crear una cuenta de

almacenamiento, debe usar una identidad administrada asignada por el usuario.
Si configura claves administradas por el cliente en una cuenta de almacenamiento
existente, puede usar una identidad administrada asignada por el usuario o
asignada por el sistema.
Para más información sobre las identidades administradas asignadas por el sistema en
comparación con las asignadas por el usuario, consulte Identidades administradas para
recursos de Azure. Para más información sobre cómo crear y administrar una identidad
administrada asignada por el usuario, consulte Administración de identidades
administradas asignadas por el usuario.
Claves administradas por el cliente con un almacén de

claves en un inquilino diferente
Para aprender a configurar el cifrado de Azure Storage con claves administradas por el
cliente cuando el almacén de claves y la cuenta de almacenamiento están en distintos
inquilinos de Azure AD, consulte uno de los siguientes artículos:
Configuración de claves administradas por el cliente entre inquilinos para una
nueva cuenta de almacenamiento
cuenta de almacenamiento existente
Claves administradas por el cliente con un HSM

administrado
Puede configurar claves administradas por el cliente con un HSM administrado de Azure
Key Vault para una cuenta nueva o existente. Además, puede configurar claves
administradas por el cliente con un HSM administrado que esté en el mismo inquilino
que la cuenta de almacenamiento o en otro inquilino. El proceso para configurar claves
administradas por el cliente en un HSM administrado es el mismo que para configurar
claves administradas por el cliente en un almacén de claves, pero los permisos son un
poco diferentes. Para más información, consulte Configuración del cifrado con claves
administradas por el cliente almacenadas en HSM administrado por Azure Key Vault.
Actualización de la versión de la clave

Seguir los procedimientos recomendados criptográficos significa rotar la clave que
protege la cuenta de almacenamiento según una programación normal; por lo general,
al menos, cada dos años. Azure Storage nunca modifica la clave en el almacén de claves,
pero puede configurar una directiva de rotación de claves para rotar la clave según sus
requisitos de cumplimiento. Para más información, consulte Configurar la rotación
automática de claves en Azure Key Vault.
Una vez rotada la clave en el almacén de claves, la configuración de claves

administradas por el cliente para la cuenta de almacenamiento debe actualizarse para
usar la nueva versión de clave. Las claves administradas por el cliente admiten la
actualización automática y manual de la versión de clave para la clave que protege la
cuenta. Puede decidir qué enfoque desea usar al configurar claves administradas por el
cliente o al actualizar la configuración.
Al modificar la clave o la versión de clave, la protección de la clave de cifrado raíz

cambiará, pero los datos de la cuenta de Azure Storage seguirán cifrados en todo
momento. No se requiere ninguna acción adicional por su parte para asegurarse de que
los datos están protegidos. La rotación de la versión de la clave no afecta al
rendimiento. No hay tiempo de inactividad asociado a la rotación de la versión de la
clave.
） Importante
Para rotar una clave, cree una nueva versión de la clave en el almacén de claves o
HSM administrado, según los requisitos de cumplimiento. Azure Storage no
controla la rotación de claves, por lo que deberá administrar la rotación de la clave
en el almacén de claves.
Cuando rotas la clave que se usa para las claves administradas por el cliente, esa
acción no se registra actualmente en los registros de Azure Monitor para Azure
Storage.
Actualización automática de la versión de clave

para actualizar automáticamente una clave administrada por el cliente a una nueva
versión disponible, omita la versión de la clave al habilitar el cifrado con las claves
administradas por el cliente para la cuenta de almacenamiento. Si se omite la versión de
la clave, Azure Storage comprueba el almacén de claves o HSM administrado
diariamente para obtener una nueva versión de una clave administrada por el cliente. Si
hay disponible una nueva versión de la clave, Azure Storage usa automáticamente la
versión más reciente.
Azure Storage comprueba solo una vez al día el almacén de claves para obtener una
nueva versión de la clave. Al girar una clave, asegúrese de esperar 24 horas antes de
deshabilitar la versión anterior.
Si la cuenta de almacenamiento se configuró anteriormente para la actualización

manual de la versión de la clave y desea cambiarla para que se actualice
automáticamente, es posible que tenga que cambiar explícitamente la versión de la
clave a una cadena vacía. Para más información sobre cómo hacerlo, consulte
Configuración de claves administradas por el cliente en un almacén de claves de Azure
para una nueva cuenta de almacenamiento.
Actualización manual de la versión de la clave

para usar una versión determinada de una clave para el cifrado de Azure Storage,
especifique la versión de la clave al habilitar el cifrado con las claves administradas por
el cliente para la cuenta de almacenamiento. Si especifica la versión de la clave, Azure
Storage usará esa versión para el cifrado hasta que actualice manualmente la versión de
la clave.
Cuando se especifica la versión de la clave de manera explícita, debe actualizar
manualmente la cuenta de almacenamiento para usar el nuevo URI de la versión de la
clave cuando se crea una nueva versión. Para obtener más información sobre cómo
actualizar la cuenta de almacenamiento para usar una nueva versión de la clave,
consulte Configuración del cifrado con claves administradas por el cliente almacenadas
en Azure Key Vault o Configuración del cifrado con claves administradas por el cliente
almacenadas en HSM administrado de Azure Key Vault.
Revocar el acceso a una cuenta de

almacenamiento que usa claves administradas
por el cliente
Para revocar el acceso a una cuenta de almacenamiento que usa claves administradas
por el cliente, deshabilite la clave en el almacén de claves. Para obtener información
sobre cómo deshabilitar la clave, consulte Revocar el acceso a una cuenta de
almacenamiento que usa claves administradas por el cliente.
Después de deshabilitar la clave, los clientes no pueden llamar a las operaciones que
leen o escriben en un recurso o en sus metadatos. Los intentos de llamar a estas
operaciones producirán un error con el código de error 403 (prohibido) para todos los
usuarios.
Para volver a llamar a estas operaciones, restaure el acceso a la clave administrada por el
cliente.
Todas las operaciones de datos que no aparecen en las siguientes secciones pueden
continuar después de que se hayan revocado las claves administradas por el cliente o se
haya deshabilitado o eliminado una clave.
Para revocar el acceso a las claves administradas por el cliente, use PowerShell o la CLI
de Azure.
Operaciones de Blob Storage que producen un error

después de revocar una clave
List Blobs, cuando se llama con el parámetro include=metadata en el URI de
solicitud
Get Blob
Get Blob Properties
[Obtener metadatos de blob] (/rest/api/storageservices/get-blob-metadata)
Set Blob Metadata
Snapshot Blob, cuando se llama con el encabezado de solicitud x-ms-meta-name
Copy Blob
Copy Blob From URL
Set Blob Tier
Put Block
Put Block From URL
Append Block
Append Block From URL
Put Blob
Put Page
Put Page From URL
Incremental Copy Blob (Copia incremental del blob)
Operaciones de Azure Files que producen un error

después de revocar una clave
Crear permiso
Obtener permiso
Enumerar directorios y archivos
Crear directorio
Obtener propiedades del directorio
Establecer propiedades del directorio
Obtener metadatos de directorio
Establecer metadatos de directorio
Crear archivo
Get File
Obtener propiedades del archivo
Establecer propiedades del archivo
Put Range
Colocar rango desde dirección URL
Obtener metadatos del archivo
Set File Metadata
Copiar archivo
Cambiar nombre de archivo
Claves administradas por el cliente para discos

administrados por Azure
Las claves administradas por el cliente también están disponibles para administrar el
cifrado de discos administrados por Azure. Las claves administradas por el cliente se
comportan de forma diferente en los discos administrados que en los recursos de Azure
Storage. Para más información, consulte Cifrado del lado servidor de Azure Managed
Disks para Windows o Cifrado del lado servidor de Azure Managed Disks para Linux.
Pasos siguientes
Cifrado de Azure Storage para datos en reposo
Configuración del cifrado con claves administradas por el cliente almacenadas en
Azure Key Vault
HSM administrado de Azure Key Vault.
Ofertas de cumplimiento de Azure
Storage
Artículo • 30/04/2023
Para ayudarle a satisfacer sus propias obligaciones de cumplimiento en sectores y

mercados regulados de todo el mundo, Azure mantiene el cumplimiento más amplio
del sector en cuanto a amplitud (número total de ofertas) y profundidad (número de
servicios orientados al cliente en el ámbito de la evaluación). Para la disponibilidad de
los servicios, consulte Productos disponibles por región .
Ámbito de auditoría de Azure Storage

Microsoft conserva firmas de auditoría independientes y de terceros para realizar
auditorías de los servicios en la nube de Microsoft. Las ofertas de cumplimiento se
agrupan en cuatro segmentos: aplicables globalmente, gobierno estadounidense,
específicas de un sector y específicas de un país o región. Los certificados de
cumplimiento de Azure y los informes de auditoría indican claramente qué servicios en
la nube están en el ámbito de las auditorías de terceros independientes. Las distintas
auditorías pueden tener diferentes servicios en la nube de ámbito de auditoría en
entornos de nube de Azure y Azure Government.
Azure Storage se incluye en muchas auditorías de cumplimiento de Azure, como CSA

STAR, ISO, SOC, PCI DSS, HITRUST, FedRAMP, DoD, etc. Las garantías de cumplimiento
resultantes son aplicables a:
Blobs (incluyendo Azure Data Lake Storage Gen2)

Archivos
Colas
Tablas
Discos
Almacenamiento de acceso esporádico
Premium Storage
Para obtener la información más reciente sobre el ámbito de auditoría de cumplimiento

de Azure Storage, consulte Servicios en la nube en el ámbito de auditoría.
Pasos siguientes
Para más información sobre el cumplimiento de Azure, consulte la siguiente
información.
Cumplimiento de Azure
Azure y otras ofertas de cumplimiento de servicios de Microsoft
Preguntas más frecuentes (P+F) sobre
Azure Files
Artículo • 28/11/2023
Azure Files le ofrece recursos compartidos de archivos en la nube totalmente

administrados, a los que se puede obtener acceso mediante el protocolo Bloque de
mensajes del servidor (SMB) estándar y el protocolo Network File System (NFS) . Los
recursos compartidos de archivos de Azure se pueden montar simultáneamente en
implementaciones de Windows, Linux y macOS en la nube o locales. También puede
almacenar en caché recursos compartidos de archivos de Azure en máquinas con
Windows Server mediante Azure File Sync para tener un acceso rápido cerca de donde
se usan los datos.
Azure File Sync

¿Puedo tener servidores unidos a un dominio y no unidos a un dominio en el
mismo grupo de sincronización?
Sí. Un grupo de sincronización puede contener puntos de conexión de servidor
que tienen pertenencias diferentes de Active Directory, incluso aunque no estén
unidos a dominio. Aunque técnicamente la configuración funciona, no se
recomienda como configuración normal, ya que las listas de control de acceso
(ACL) que se definen para los archivos y carpetas de un servidor no podrán
aplicarse a otros servidores del grupo de sincronización. Para mejores resultados,
se recomienda realizar la sincronización entre servidores en el mismo bosque de
Active Directory, entre servidores en bosques distintos de Active Directory con
relaciones de confianza establecidas o entre servidores que no están en un
dominio. Se recomienda no usar una combinación de estas configuraciones.
Si creé un archivo directamente en el recurso compartido de archivos de Azure

mediante SMB o el portal, ¿cuánto tiempo tarda el archivo en sincronizarse con
los servidores del grupo de sincronización?
Los cambios realizados en el recurso compartido de archivos de Azure mediante

Azure Portal o SMB no se detectan y replican de forma inmediata como cambios
en el punto de conexión del servidor. Azure Files aún no dispone de registros en
diario o notificaciones, por lo que no hay manera de iniciar automáticamente una
sesión de sincronización cuando se cambian los archivos. En Windows Server,
Azure File Sync usa el registro en diario de USN de Windows para iniciar
automáticamente una sesión de sincronización cuando cambian los archivos.
Para detectar cambios en el recurso compartido de archivos de Azure, Azure File
Sync tiene un trabajo programado que se denomina trabajo de detección de
cambios. Un trabajo de detección de cambios enumera todos los archivos del
recurso compartido de archivos y, a continuación, los compara con la versión de
sincronización correspondiente. Cuando el trabajo de detección de cambios
determina qué archivos han cambiado, Azure File Sync inicia una sesión de
sincronización. El trabajo de detección de cambios se inicia cada 24 horas. Dado
que el trabajo de detección de cambios enumera todos los archivos del recurso
compartido de archivos de Azure, la detección de cambios tarda más en los
espacios de nombres más largos que los espacios de nombres más cortos. En el
caso de los espacios de nombres largos, es posible que sea necesario determinar
más de una vez cada 24 horas qué archivos han cambiado.
Para sincronizar inmediatamente los archivos que se modifican en el recurso

compartido de archivos de Azure, se puede usar el cmdlet Invoke-
AzStorageSyncChangeDetection de PowerShell para iniciar de forma manual la
detección de cambios en el recurso compartido. Este cmdlet está pensado para
escenarios en los que algún tipo de proceso automatizado está realizando cambios
en el recurso compartido de archivos de Azure o en los que es el administrador el
que efectúa los cambios (por ejemplo, al mover archivos y directorios al recurso
compartido). En el caso de los cambios del usuario final, se recomienda instalar el
agente de Azure File Sync en una máquina virtual de IaaS y hacer que los usuarios
finales accedan al recurso compartido de archivos a través de ella. De este modo,
todos los cambios se sincronizarán rápidamente con otros agentes sin necesidad
de usar el cmdlet Invoke-AzStorageSyncChangeDetection. Para más información,
consulte la documentación sobre Invoke-AzStorageSyncChangeDetection.
Estamos considerando agregar la detección de cambios para un recurso

compartido de archivos de Azure similar al USN para volúmenes en Windows
Server. Ayúdenos a priorizar el futuro desarrollo de esta característica votándola en
Comentarios de la comunidad de Azure .
Si se cambia el mismo archivo en dos servidores aproximadamente al mismo

tiempo, ¿qué sucede?
Los conflictos de archivos se crean cuando el archivo del recurso compartido de
archivos de Azure no coincide con el archivo en la ubicación del punto de
conexión del servidor (el tamaño o la hora de la última modificación es diferente).
Los siguientes escenarios pueden provocar conflictos de archivos:

Se crea o modifica un archivo en un punto de conexión (por ejemplo, el
Servidor A). Si el mismo archivo se modifica en un punto de conexión diferente
antes de que el cambio en el servidor A se sincronice con ese punto de
conexión, se crea un archivo de conflicto.
El archivo existía en el recurso compartido de archivos de Azure y en la
ubicación del punto de conexión del servidor antes de la creación del punto de
conexión de servidor. Si el tamaño del archivo o la hora de la última
modificación es diferente entre el archivo del servidor y el recurso compartido
de archivos de Azure cuando se crea el punto de conexión del servidor, se crea
un archivo de conflicto.
Se ha vuelto a crear la base de datos de sincronización debido a daños o a que
se alcanzaron los límites de conocimiento. Una vez que se vuelve a crear la base
de datos, la sincronización entra en un modo denominado conciliación. Si el
tamaño del archivo o la hora de la última modificación es diferente entre el
archivo del servidor y el recurso compartido de archivos de Azure cuando se
produce la conciliación, se crea un archivo de conflicto.
Azure File Sync usa una estrategia simple de resolución de conflictos: conservamos
los cambios realizados en los archivos que se modifican en dos puntos de
conexión al mismo tiempo. El cambio de escritura más reciente mantiene el
nombre de archivo original. El archivo antiguo (según lo establecido por
LastWriteTime) tiene el nombre del punto de conexión y el número de conflicto
anexado al nombre de archivo. En el caso de los puntos de conexión de servidor, el
nombre del punto de conexión es el nombre del servidor. Para los puntos de
conexión de nube, el nombre del punto de conexión es Cloud. El nombre sigue
esta taxonomía:
<FileNameWithoutExtension>-<endpointName>[-#].<ext>
Por ejemplo, el primer conflicto de CompanyReport.docx se convertiría en

CompanyReport-CentralServer.docx si CentralServer es donde se ha producido la
operación de escritura anterior. El segundo conflicto se denominará
CompanyReport-CentralServer-1.docx. Azure File Sync admite 100 archivos de
conflicto por archivo. Una vez alcanzado el número máximo de archivos de
conflicto, el archivo no se sincronizará hasta que el número de archivos de
conflicto sea inferior a 100.
Tengo deshabilitada la nube por niveles, ¿por qué hay archivos por niveles en la
ubicación del punto de conexión de servidor?
Existen dos razones por las que pueden existir archivos por niveles en la ubicación
del punto de conexión de servidor:
Al agregar un nuevo punto de conexión de servidor a un grupo de

sincronización existente, si elige la opción de recuperar primero el espacio de
nombres o la opción de recuperar solo el espacio de nombres para el modo de
descarga inicial, los archivos se mostrarán por niveles hasta que se descarguen
localmente. Para evitar esta situación, seleccione la opción de evitar archivos
por niveles para el modo de descarga inicial. Para recuperar archivos
manualmente, use el cmdlet Invoke-StorageSyncFileRecall.
Si se ha habilitado la nube por niveles en el punto de conexión de servidor y

luego se ha deshabilitado, los archivos permanecen por niveles hasta que se
accede a ellos.
¿Por qué no se muestran miniaturas ni vistas previas de los archivos

almacenados por niveles en el Explorador de archivos de Windows?
En el caso de los archivos con niveles, las vistas previas y las miniaturas no estarán
visibles en el punto de conexión del servidor. Este comportamiento es el esperado,
ya que la característica de caché de vistas en miniatura de Windows omite
intencionadamente la lectura de archivos con el atributo sin conexión. Con Niveles
de la nube habilitado, la lectura de archivos con niveles provocaría su descarga
(recuperación).
Este comportamiento no es específico de Azure File Sync, el Explorador de

Windows muestra una "X gris" para los archivos que tienen establecido el atributo
sin conexión. Verá el icono X al acceder a los archivos a través de SMB. Para
obtener una explicación detallada de este comportamiento, consulte ¿Por qué no
se obtienen miniaturas de archivos marcados como sin conexión?
Si tiene preguntas sobre cómo administrar archivos almacenados en niveles,

consulte Administración de archivos en niveles.
¿Por qué los archivos en capas se encuentran fuera del espacio de nombres del
punto de conexión de servidor?
Antes de la versión 3 del agente de Azure File Sync, Azure File Sync bloqueaba el
movimiento de archivos en capas fuera del punto de conexión del servidor, pero
en el mismo volumen que el punto de conexión del servidor. Las operaciones de
copia, los movimientos de archivos sin niveles y los movimientos de archivos por
niveles a otros volúmenes no resultaban afectados. La razón de este
comportamiento era la presunción implícita que tienen el Explorador de archivos y
otras API de Windows de que las operaciones de movimiento en el mismo
volumen son operaciones de cambio de nombre (casi) instantáneas. Esto significa
que los movimientos que haga el Explorador de archivos u otros métodos de
movimiento (como la línea de comandos o PowerShell) parecen no responder
mientras Azure File Sync recupera los datos de la nube. A partir de la versión
3.0.12.0 del agente de Azure File Sync, Azure File Sync le permitirá mover un
archivo con capas fuera del punto de conexión del servidor. Evitamos los efectos
negativos que se mencionaron anteriormente permitiendo que el archivo con
capas exista como un archivo con capas fuera del punto de conexión del servidor
y, a continuación, recuperando el archivo en segundo plano. Esto significa que los
movimientos en el mismo volumen son instantáneos y nosotros nos ocupamos por
completo de recuperar el archivo en el disco una vez que el movimiento se ha
completado.
Tengo un problema con Azure File Sync en mi servidor (sincronización, niveles

en la nube, etc.). ¿Debería quitar y volver a crear el punto de conexión del
servidor?
No: eliminar un punto de conexión de servidor no es como reiniciar un servidor.

Eliminar y volver a crear el punto de conexión del servidor casi nunca es una
solución adecuada para solucionar problemas de sincronización, niveles de nube u
otros aspectos de Azure File Sync. Quitar un punto de conexión de servidor es una
operación destructiva. Puede producirse una pérdida de datos en caso de que
existan archivos en capas fuera del espacio de nombres del punto de conexión de
servidor. Para más información, consulte ¿Por qué los archivos en capas se
encuentran fuera del espacio de nombres del punto de conexión de servidor? para
más información. También pueden producirse archivos inaccesibles para los
archivos en capas que existen en el espacio de nombres del punto de conexión de
servidor. Estos problemas no se resolverán al volver a crear el punto de conexión
en el servidor. Puede haber archivos en capas en el espacio de nombres del punto
de conexión de un servidor aunque nunca se hayan habilitado los niveles en la
nube. Por eso se recomienda no eliminar el punto de conexión del servidor a
menos que desee dejar de usar Azure File Sync con esta carpeta en concreto o un
ingeniero de Microsoft le haya solicitado expresamente que lo haga así. Para más
información sobre la eliminación de puntos de conexión del servidor, consulte
Eliminación de un punto de conexión de servidor.
¿Puedo mover el servicio de sincronización de almacenamiento o la cuenta de

almacenamiento a otro grupo de recursos, suscripción o inquilino de Microsoft
Entra?
Sí, puede mover el servicio de sincronización de almacenamiento y/o la cuenta de
almacenamiento a un grupo de recursos, suscripción o inquilino de Microsoft Entra
diferente. Después de mover el servicio de sincronización de almacenamiento o la
cuenta de almacenamiento, debe otorgar acceso a la aplicación
Microsoft.StorageSync a la cuenta de almacenamiento. Siga estos pasos:
1. Inicie sesión en el Azure Portal y seleccione Control de acceso (IAM) en el

panel de navegación izquierdo.
2. Seleccione la pestaña Asignaciones de roles de la lista de los usuarios y
aplicaciones (entidades de seguridad) que tienen acceso a su cuenta de
almacenamiento.
3. Confirme que Microsoft.StorageSync o Hybrid File Sync Service (nombre

anterior de la aplicación) figuran en la lista con el rol Lector y acceso a los
datos.
Si Microsoft.StorageSync o Hybrid File Sync Service no aparecen en la lista,

siga los siguientes pasos:
Seleccione Agregar.
En el campo Rol, seleccione Lector y acceso a los datos.
En el campo Seleccionar, escriba Microsoft.StorageSync, seleccione el rol
y, a continuación, seleccione Guardar.
７ Nota
Al crear el punto de conexión en la nube, el servicio de sincronización de

almacenamiento y la cuenta de almacenamiento deben estar en el
mismo inquilino de Microsoft Entra. Una vez creado el punto de
conexión en la nube, el servicio de sincronización de almacenamiento y
la cuenta de almacenamiento se pueden mover a diferentes inquilinos
de Microsoft Entra.
¿Mantiene Azure File Sync las listas ACL de NTFS a nivel de directorio/archivo
junto con los datos almacenados en Azure Files?
A partir del 24 de febrero de 2020, tanto las listas de control de acceso nuevas
como las existentes que Azure File Sync organiza en capas se conservarán en
formato NTFS y las modificaciones de ACL realizadas directamente en el recurso
compartido de archivos de Azure se sincronizarán con todos los servidores del
grupo de sincronización. Los cambios en las listas de control de acceso realizados
en recursos compartidos de archivos de Azure se sincronizarán a través de Azure
File Sync. Al copiar datos en Azure Files, asegúrese de usar una herramienta de
copia que admita la "fidelidad" necesaria para copiar los atributos, las marcas de
tiempo y las ACL en un recurso compartido de archivos de Azure, ya sea a través
de SMB o REST. Al usar las herramientas de copia de Azure, como AzCopy, es
importante usar la versión más reciente. Eche un vistazo a la tabla de herramientas
de copia de archivos para obtener información general sobre las herramientas de
copia de Azure, lo que le permitirá asegurarse de que pueda copiar todos los
metadatos importantes de un archivo.
Si ha habilitado Azure Backup en los recursos compartidos de archivos
administrados de Azure File Sync, las listas de control de acceso de los archivos se
pueden seguir restaurando como parte del flujo de trabajo de la restauración de la
copia de seguridad. Esto puede realizarse tanto en todo el recurso compartido o
en cada uno de los archivos o directorios.
Si usa instantáneas como parte de la solución de copia de seguridad

autoadministrada para los recursos compartidos de archivos administrados por
Azure File Sync, es posible que las listas de control de acceso no se restauren
correctamente en las ACL con formato NTFS si las instantáneas se tomaron antes
del 24 de febrero de 2020. En ese caso, póngase en contacto con el soporte
técnico de Azure.
¿Azure File Sync sincroniza el LastWriteTime de los directorios? ¿Por qué no se

actualiza la marca de tiempo de fecha de modificación de un directorio cuando
se modifican los archivos que contiene?
No, Azure File Sync no sincroniza el valor de LastWriteTime de los directorios.
Además, Azure Files no actualiza la marca de tiempo de fecha de modificación
(LastWriteTime) de los directorios cuando se cambian los archivos del directorio.
Este es el comportamiento esperado.
Seguridad, autenticación y control de acceso

¿Cómo se pueden auditar tanto el acceso a los archivos como los cambios que
se realicen en ellos en Azure Files?
Hay dos opciones que proporcionan la funcionalidad de auditoría a Azure Files:

Si los usuarios acceden directamente al recurso compartido de archivos de
Azure, puede usar los registros de Azure Storage para realizar un seguimiento
de los cambios en los archivos y del acceso de los usuarios con el fin de
solucionar problemas. Las solicitudes se registran en función de la mejor opción.
Si los usuarios acceden al recurso compartido de archivos de Azure a través de
un servidor de Windows Server con el agente de Azure File Sync instalado, use
una directiva de auditoría o un producto de terceros para realizar el
seguimiento de los cambios en los archivos y el acceso de los usuarios en el
servidor de Windows Server.
¿Admite Azure Files el uso de Access-Based Enumeración (ABE) para controlar la

visibilidad de los archivos y las carpetas en los recursos compartidos de archivos
de Azure SMB?
El uso de ABE con Azure Files no se admite actualmente, pero puede usar DFS-N
con recursos compartidos de archivos de Azure SMB.
Habilitación basada en identidad

¿Admite los servicios de dominio de Microsoft Entra el acceso SMB mediante
credenciales de Microsoft Entra desde dispositivos unidos o registrados con
Microsoft Entra ID?
No, este escenario no se admite.
¿Puedo usar el nombre canónico (CNAME) para montar un recurso compartido

de archivos de Azure mientras se usa la autenticación basada en identidades?
Sí, este escenario ahora se admite tanto en los entornos de bosque único como en
los de varios bosques para recursos compartidos de archivos de Azure SMB. Sin
embargo, Azure Files solo admite la configuración de CNAME mediante el nombre
de la cuenta de almacenamiento como prefijo de dominio. Si no quiere usar el
nombre de la cuenta de almacenamiento como prefijo, considere la posibilidad de
usar espacios de nombres DFS.
¿Puedo acceder a los recursos compartidos de archivos de Azure con

credenciales de Microsoft Entra desde una máquina virtual con una suscripción
diferente?
Si la suscripción bajo la cual se implementa el recurso compartido de archivos está

asociada con el mismo inquilino de Microsoft Entra que la implementación de
servicios de dominio de Microsoft Entra a la cual la máquina virtual está unida al
dominio, puede acceder a los recursos compartidos de archivos de Azure usando
las mismas credenciales de Microsoft Entra. La limitación no se impone en la
suscripción, sino en el inquilino de Microsoft Entra asociado.
¿Puedo habilitar los servicios de dominio de Microsoft Entra o la autenticación

AD DS local para los recursos compartidos de archivos de Azure mediante un
inquilino de Microsoft Entra diferente del inquilino principal del recurso
compartido de archivos de Azure?
No. Azure Files solo admite servicios de dominio de Microsoft Entra o la

integración de AD DS local con un inquilino de Microsoft Entra que resida en la
misma suscripción que el recurso compartido de archivos. Una suscripción solo se
puede asociar a un inquilino de Microsoft Entra. Al usar AD DS local para la
autenticación, la credencial de AD DS debe sincronizarse con Microsoft Entra ID al
que está asociada la cuenta de almacenamiento.
¿La autenticación con AD DS local para recursos compartidos de archivos de
Azure admite la integración en un entorno de AD DS mediante varios bosques?
La autenticación con AD DS local para Azure Files solo se integra con el bosque del
servicio de dominio en el que está registrada la cuenta de almacenamiento. Para
admitir la autenticación desde otro bosque, la confianza de bosque del entorno
debe estar configurada correctamente. Para obtener instrucciones detalladas,
consulte Uso de Azure Files con varios bosques de Active Directory.
７ Nota
En una configuración de varios bosques, no use el Explorador de archivos

para configurar los permisos de ACL o NTFS de Windows en el nivel de raíz,
directorio o archivo. En su lugar, use icacls.
¿Hay alguna diferencia entre la creación de una cuenta de equipo y una cuenta
de inicio de sesión de servicio para representar mi cuenta de almacenamiento en
AD?
La creación de una cuenta de equipo (valor predeterminado) o de una cuenta de

inicio de sesión de servicio no representa ninguna diferencia en el modo en que la
autenticación funciona con Azure Files. Puede elegir cómo representar una cuenta
de almacenamiento como una identidad en el entorno de AD. El valor
predeterminado de DomainAccountType establecido en el cmdlet Join-
AzStorageAccountForAuth es la cuenta de la máquina. Sin embargo, el tiempo de
expiración de la contraseña configurado en el entorno de AD puede ser diferente

para las cuentas de inicio de sesión de servicio y de equipo, por lo que se debe
tener en cuenta para la Actualización de la contraseña de la identidad de cuenta
de almacenamiento en AD.
¿Cómo quitar las credenciales almacenadas en caché con la clave de cuenta de

almacenamiento y eliminar las conexiones SMB existentes antes de inicializar
una nueva conexión con credenciales de Microsoft Entra ID o AD?
Siga el proceso de dos pasos siguiente para quitar las credenciales guardadas
asociadas a la clave de cuenta de almacenamiento y quitar la conexión SMB:
1. Ejecute el siguiente comando desde un símbolo del sistema de Windows para

quitar la credencial. Si no encuentra uno, significa que no ha conservado la
credencial y puede omitir este paso.
cmdkey /delete:Domain:target=storage-account-name.file.core.windows.net
2. Elimine la conexión existente con el recurso compartido de archivos. Puede
especificar la ruta de acceso de montaje como la letra de unidad montada o
la ruta de acceso storage-account-name.file.core.windows.net .
net use <drive-letter/share-path> /delete
¿Es posible ver el userPrincipalName (UPN) de un propietario de archivo o

directorio en el Explorador de archivos en lugar del identificador de seguridad
(SID)?
El Explorador de archivos llama a una API RPC directamente al servidor (Azure

Files) para trasladar el SID a un UPN. Azure Files no admite esta API, por tanto, en
el Explorador de archivos, se muestra el SID de un propietario de archivos o
directorios en lugar del UPN de los archivos y directorios hospedados en Azure
Files. Sin embargo, puede usar el siguiente comando de PowerShell para ver todos
los elementos de un directorio y su propietario, incluido el UPN:
PowerShell
Get-ChildItem <Path> | Get-ACL | Select Path, Owner
Network File System (NFS v4.1)

¿Cuándo se deben usar recursos compartidos de archivos NFS de Azure?
Consulte Recursos compartidos NFS.
¿Cómo hago una copia de seguridad de los datos almacenados en recursos

compartidos NFS?
La realización de copias de seguridad de los datos en recursos compartidos NFS se

puede organizar mediante herramientas conocidas, como rsync, o productos de
uno de nuestros asociados para la copia de seguridad. Varios asociados para la
copia de seguridad, entre los que se incluyen Commvault , Veeam y Veritas ,
han ampliado sus soluciones para que funcionen con SMB 3.x y NFS 4.1 para Azure
Files.
¿Puedo migrar datos existentes a un recurso compartido NFS?
Dentro de una región, puede usar herramientas estándar como scp, rsync o SSHFS
para mover los datos. Dado que se puede acceder a recursos compartidos de
archivos NFS de Azure desde varias instancias de proceso al mismo tiempo, se
pueden mejorar las velocidades de copia con cargas paralelas. Si desea traer datos
de fuera de una región, use una VPN o Expressroute para el montaje en el sistema
de archivos desde el centro de datos local.
¿Puede ejecutar IBM MQ (incluidas las instancias múltiples) en recursos

compartidos de archivos NFS de Azure?
Los recursos compartidos de archivos de Azure Files NFS v4.1 cumplen los tres
requisitos que establece IBM MQ:
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=multiplatforms-
requirements-shared-file-systems
Integridad de escritura de datos
Acceso exclusivo garantizado a los archivos
Liberación de bloqueos en caso de error
Los siguientes casos de prueba se ejecutan correctamente:
1. https://www.ibm.com/docs/en/ibm-mq/9.2?topic=multiplatforms-
verifying-shared-file-system-behavior
2. https://www.ibm.com/docs/en/ibm-mq/9.2?topic=multiplatforms-
running-amqsfhac-test-message-integrity
Creación de instantáneas de recurso compartido

¿Tienen mis instantáneas de recurso compartido redundancia geográfica?
Las instantáneas de recurso compartido tienen la misma redundancia que el
recurso compartido de archivos de Azure para el que se han tomado. Si ha
seleccionado el almacenamiento con redundancia geográfica para la cuenta, la
instantánea de recurso compartido también se almacena de manera redundante
en la región emparejada.
Limpiar instantáneas de recurso compartido

¿Puedo eliminar mi recurso compartido pero no las instantáneas de recurso
compartido?
Si tiene instantáneas de recurso compartido activas en el recurso, no puede
eliminar el recurso compartido. Puede usar una API para eliminar instantáneas de
recurso compartido junto con el recurso compartido. También puede eliminar las
instantáneas de recurso compartido y el recurso compartido en Azure Portal.
Precios y facturación
¿Qué son las transacciones en Azure Files y cómo se facturan? Las transacciones
de protocolo se producen cada vez que un usuario, aplicación, script o servicio
interactúa con recursos compartidos de archivos de Azure (escritura, lectura,
enumeración, eliminación de archivos, etc.). Conviene recordar que, algunas
acciones que puede percibir como una sola operación, podrían implicar en
realidad varias transacciones. En el caso de los recursos compartidos de archivos
Estándar de Azure facturados en un modelo de pago por uso, los distintos tipos de
transacciones tienen precios diferentes en función de su impacto en el recurso
compartido de archivos. Las transacciones no afectan a la facturación de recursos
compartidos de archivos Premium, que se facturan mediante un modelo
aprovisionado. Para más información, consulte Descripción de la facturación.
¿Cuánto cuestan las instantáneas de recurso compartido?

Las instantáneas de recurso compartido son de naturaleza incremental. La
instantánea de recurso compartido de base es el mismo recurso compartido. Todas
las instantáneas de recurso compartido siguientes son incrementales y solo
almacenan la diferencia de la instantánea de recurso compartido anterior. Se le
facturará únicamente por el contenido cambiado. Si tiene un recurso compartido
con 100 GB de datos, pero solo se han cambiado 5 GB desde la última instantánea
de recurso compartido, esa instantánea de recurso compartido consumirá solo
5 GB adicionales y se le facturarán, por tanto, 105 GB. Para obtener más
información sobre los cargos de salida estándar y de transacciones, vea la página
de precios .
Interoperabilidad con otros servicios

¿Puedo usar mi recurso compartido de archivos de Azure como un testigo del
recurso compartido de archivos para el clúster de conmutación por error de
Windows Server?
Esta configuración no se admite actualmente para Azure Files. Para obtener más
información acerca de cómo configurar esto usando Azure Blob Storage, consulte
Implementar un testigo en la nube para un clúster de conmutación por error.
Consulte también
Solución de problemas de Azure File Sync
Novedades de Azure Files
Artículo • 13/10/2023
Azure Files se actualiza periódicamente para ofrecer nuevas características y mejoras. En

este artículo se proporciona información detallada sobre las novedades de Azure Files y
Azure File Sync.
Novedades de 2023
4.º trimestre de 2023 (octubre, noviembre, diciembre)
Azure Files ahora admite todos los caracteres Unicode válidos

La compatibilidad con caracteres expandidos permitirá a los usuarios crear recursos
compartidos de archivos SMB con nombres de archivo y directorio a la par que el
sistema de archivos NTFS para todos los caracteres Unicode válidos. También habilita
herramientas como AzCopy y Storage Mover para migrar todos los archivos a Azure
Files mediante el protocolo REST. La compatibilidad con caracteres expandidos ya está
disponible en todas las regiones de Azure. Para más información, lea el anuncio .
3.er trimestre de 2023 ( julio, agosto, septiembre)
La compatibilidad de Azure Active Directory con la API de REST de

Azure Files con autenticación de OAuth está disponible con
caracter general
Esta característica permite el acceso de lectura y escritura a nivel de recurso compartido
a recursos compartidos de archivos de Azure SMB para usuarios, grupos e identidades
administradas al acceder a los datos del recurso compartido de archivos a través de la
API de REST. Las aplicaciones nativas y modernas en la nube que usen las API de REST
pueden usar la autorización y autenticación basada en identidades para acceder a los
recursos compartidos de archivos. Para obtener más información, lea esta entrada de
blog .
2.º trimestre de 2023 (abril, mayo, junio)

La mejora de la escalabilidad de Azure Files para Azure Virtual
Desktop y otras cargas de trabajo que controla el directorio raíz
abierto está disponible de forma generalizada
Azure Files ha aumentado el límite de identificadores de directorio raíz por recurso
compartido de 2000 a 10 000 para recursos compartidos de archivos estándar y
premium. Esta mejora beneficia a las aplicaciones que mantienen un identificador
abierto en el directorio raíz. Por ejemplo, Azure Virtual Desktop con contenedores de
perfiles de FSLogix ahora admite 10 000 usuarios activos por recurso compartido (cinco
veces más).
Nota: el número de usuarios activos admitidos por recurso compartido depende de las
aplicaciones que acceden al recurso compartido. Si las aplicaciones no abren un
identificador en el directorio raíz, Azure Files puede admitir más de 10 000 usuarios
activos por recurso compartido.
El límite de identificadores de directorio raíz se ha aumentado en todas las regiones y se

aplica a todos los recursos compartidos de archivos existentes y nuevos. Para obtener
más información sobre los objetivos de escalabilidad de Azure Files, consulte Objetivos
de escalabilidad y rendimiento de Azure Files.
El almacenamiento con redundancia geográfica para recursos

compartidos grandes está en versión preliminar pública
La versión preliminar de redundancia geográfica de Azure Files para recursos

compartidos de archivos grandes mejora significativamente la capacidad y el
rendimiento de los recursos compartidos de archivos SMB estándar al usar las opciones
de almacenamiento con redundancia geográfica (GRS) y almacenamiento con
redundancia de zona geográfica (GZRS). La versión preliminar solo está disponible para
recursos compartidos de archivos de Azure SMB estándar. Para obtener más
información, consulte Redundancia geográfica de Azure Files para la versión preliminar
de recursos compartidos de archivos grandes.
El nuevo Acuerdo de Nivel de Servicio del 99,99 % para Azure Files

nivel Premium está disponible con carácter general
Azure Files ahora ofrece un Acuerdo de Nivel de Servicio del 99,99 % por recurso
compartido de archivos para todos los recursos compartidos de Azure Files Premium,
independientemente del protocolo (SMB, NFS y REST) o tipo de redundancia. Esto
significa que puede beneficiarse de este Acuerdo de Nivel de Servicio inmediatamente,
sin cambios de configuración ni costes adicionales. Si la disponibilidad cae por debajo
del tiempo de actividad garantizado del 99,99 por ciento, podrá optar a créditos de
servicio.
La compatibilidad de Azure Active Directory con la API de REST de

Azure Files con autenticación de OAuth está en versión preliminar
pública
Esta versión preliminar permite el acceso de lectura y escritura a nivel de recurso

compartido a recursos compartidos de archivos de Azure SMB para usuarios, grupos e
identidades administradas al acceder a los datos del recurso compartido de archivos a
través de la API de REST. Las aplicaciones nativas y modernas en la nube que usen las
API de REST pueden usar la autorización y autenticación basada en identidades para
acceder a los recursos compartidos de archivos. Para obtener más información, lea esta
entrada de blog .
La autenticación Kerberos AD para clientes Linux (SMB) está

disponible con carácter general
Los clientes de Azure Files ahora pueden usar la autenticación Kerberos basada en
identidad para clientes Linux sobre SMB usando Servicios de dominio de Active
Directory (AD DS) locales o Servicios de dominio de Active Directory de Azure (Azure AD
DS). Para más información, consulte Habilitar la autenticación de Active Directory sobre
SMB para clientes Linux que acceden a Azure Files.
1.er trimestre de 2023 (enero, febrero, marzo)
Nconnect para recursos compartidos de Azure NFS está disponible

con carácter general
Nconnect es una opción de montaje de Linux del lado cliente que aumenta el
rendimiento a escala, ya que permite usar más conexiones TCP entre el cliente Linux y el
servicio Azure Premium Files para NFSv4.1. Con nconnect, puede aumentar el
rendimiento a escala mediante menos máquinas cliente para reducir el costo total de
propiedad. Para más información, consulte Mejora del rendimiento del recurso
compartido de archivos NFS de Azure.
Disponibilidad mejorada del servicio Azure File Sync
Azure File Sync ahora es un servicio con redundancia de zona, lo que significa que una
interrupción en una zona tendrá un impacto limitado al tiempo que mejora la resistencia
del servicio para minimizar el impacto del cliente. Para aprovechar completamente esta
mejora, configure las cuentas de almacenamiento para que usen la replicación de
almacenamiento con redundancia de zona (ZRS) o de almacenamiento con redundancia
de zona geográfica (GZRS). Para más información sobre las distintas opciones de
redundancia de las cuentas de almacenamiento, consulte: Redundancia de Azure Files.
Nota: Azure File Sync tiene redundancia de zona en todas las regiones que admiten
zonas, excepto US Gov Virginia.
Novedades de la versión 2022
4.º trimestre de 2022 (octubre, noviembre, diciembre)
La autenticación Kerberos de Azure Active Directory (Azure AD)

para identidades híbridas en Azure Files tiene disponibilidad
general
Esta característica se basa en la compatibilidad con contenedores de perfiles de FSLogix
publicada en diciembre de 2022 y la amplía para admitir más casos de uso (solo SMB).
Las identidades híbridas, que son identidades de usuario creadas en Active Directory
Domain Services (AD DS) y sincronizadas con Azure AD, pueden montar recursos
compartidos de archivos de Azure y acceder a ellos sin necesidad de línea de visión a un
controlador de dominio de Active Directory. Aunque la compatibilidad inicial se limita a
las identidades híbridas, es un hito importante a medida que simplificamos la
autenticación basada en identidades para los clientes de Azure Files. Leer la entrada de
blog .
2.º trimestre de 2022 (abril, mayo, junio)
Compatibilidad de SUSE Linux con la replicación del sistema de

SAP HANA (HSR) y Pacemaker
Los clientes de Azure ahora pueden implementar un sistema SAP HANA de alta
disponibilidad en una configuración de escalabilidad horizontal con HSR y Pacemaker
en máquinas virtuales (VM) de Azure SUSE Linux Enterprise Server mediante recursos
compartidos de archivos de Azure NFS para un sistema de archivos compartido.
1.er trimestre de 2022 (enero, febrero, marzo)

Mejoras de TCO de Azure File Sync
Para ofrecer sincronización y división en niveles, Azure File Sync realiza dos tipos de
transacciones en nombre del cliente:
Transacciones de renovación, incluidos archivos modificados (sincronización) y

archivos recuperados (por niveles).
Transacciones de la enumeración de cambios en la nube, realizadas para detectar
los cambios realizados directamente en el recurso compartido de archivos de
Azure. Históricamente, este era un componente importante de la factura de Azure
Files de un cliente de Azure File Sync.
Para mejorar el TCO, hemos reducido notablemente el número de transacciones

necesarias para examinar completamente un recurso compartido de archivos de Azure.
Antes de este cambio, la mayoría de los clientes estaban mejor en el nivel de acceso
frecuente. Ahora la mayoría de los clientes están mejor en el nivel de acceso esporádico.
Novedades de la versión 2021
4.º trimestre de 2021 (octubre, noviembre y diciembre)
Aumento de IOPS para recursos compartidos de archivos Premium
Los recursos compartidos de archivos Premium de Azure ahora tienen IOPS de línea
base incluidas adicionales y un número de IOPS de ráfaga mínima más alto. La IOPS de
línea base incluida con un recurso compartido aprovisionado se incrementó de 400 a
3000, lo que significa que se garantizan 3100 IOPS de línea base para un recurso
compartido de 100 GiB (el tamaño de recurso compartido mínimo). Además, el suelo
para IOPS de ráfaga se incrementó de 4000 a 10 000, lo que significa que cada recurso
compartido de archivos Premium podrá ampliarse hasta al menos 10 000 IOPS.
Cambios en la fórmula:
Elemento Valor anterior Valor nuevo
Fórmula de IOPS de MIN(400 + 1 * ProvisionedGiB, MIN(3000 + 1 * ProvisionedGiB,

línea de base 100000) 100000)
Límite de aumento MIN(MAX(4000, 3 * MIN(MAX(10000, 3 *

ProvisionedGiB), 100000) ProvisionedGiB), 100000)
Para más información, consulte:

Modelo aprovisionado para los recursos compartidos de archivos Premium
La compatibilidad con el protocolo NFSv4.1 está disponible con

carácter general
Los recursos compartidos de archivos Premium de Azure ahora admiten los protocolos
SMB o NFSv4.1 NFSv4.1 está disponible en todas las regiones donde Azure Files admite
el nivel Premium, tanto para almacenamiento con redundancia local como para
almacenamiento con redundancia de zona. Los recursos compartidos de archivos de
Azure creados con el protocolo NFSv4.1 habilitado son recursos compartidos de
archivos distribuidos totalmente compatibles con POSIX que admiten una amplia
variedad de cargas de trabajo basadas en contenedores y Linux. Algunas cargas de
trabajo de ejemplo incluyen: capa de aplicaciones SAP de alta disponibilidad, mensajería
empresarial, directorios principales de usuario, aplicaciones personalizadas de línea de
negocio, copias de seguridad de bases de datos, replicación de bases de datos y Azure
Pipelines.
Recursos compartidos de archivos NFS en Azure Files

Alta disponibilidad de SAP NetWeaver en máquinas virtuales de Azure utilizando
NFS en Azure Files
Rendimiento simétrico para recursos compartidos de archivos

Premium
Los recursos compartidos de archivos Premium de Azure ahora admiten el

aprovisionamiento de rendimiento simétrico, lo que permite que el rendimiento
aprovisionado para un recurso compartido de archivos de Azure se utilice para la
entrada al 100 %, la salida al 100 % o alguna combinación de entrada y salida. El
rendimiento simétrico proporciona la flexibilidad para aprovechar al máximo el
rendimiento disponible y alinea los recursos compartidos de archivos Premium con los
recursos compartidos de archivos Estándar.
Cambios en la fórmula:
Rendimiento Entrada: 40 + CEILING(0.04 * 100 + CEILING(0.04 * ProvisionedGiB) +

(MiB/s) ProvisionedGiB) CEILING(0.06 * ProvisionedGiB)
Salida: 60 + CEILING(0.06 *
ProvisionedGiB)
Modelo aprovisionado para los recursos compartidos de archivos Premium

3\.er trimestre de 2021 ( julio, agosto, septiembre)
SMB multicanal está disponible con carácter general

SMB multicanal permite a los clientes SMB establecer varias conexiones paralelas a un
recurso compartido de archivos de Azure. Esto permite a los clientes SMB aprovechar al
máximo todo el ancho de banda de red disponible y los hace resistentes a los errores de
red, lo que reduce el costo total de propiedad y habilita 2-3x para lecturas y 3-4x para
escrituras a través de un solo cliente. SMB multicanal está disponible para recursos
compartidos de archivos Premium (recursos compartidos de archivos implementados en
el tipo de cuenta de almacenamiento FileStorage) y está deshabilitado de forma
predeterminada.
Rendimiento de SMB multicanal en Azure Files

Información general sobre SMB multicanal en la documentación de
Windows Server
Configuración de seguridad de SMB 3.1.1 y SMB
SMB 3.1.1 es la versión más reciente del protocolo SMB, publicada con Windows 10, que
contiene actualizaciones importantes de seguridad y rendimiento. Azure Files SMB 3.1.1
se suministra con dos modos de cifrado adicionales, AES-128-GCM y AES-256-GCM,
además de AES-128-CCM, que ya se admite. Para maximizar el rendimiento, AES-128-
GCM se negocia como la opción de cifrado de canal SMB predeterminada; AES-128-
CCM solo se negociará en clientes anteriores que no admitan AES-128-GCM.
Según los requisitos normativos y de cumplimiento de la organización, se puede

negociar AES-256-GCM en lugar de AES-128-GCM, ya sea restringiendo las opciones de
cifrado del canal SMB permitidas en los clientes SMB, en Azure Files o en ambos. Se
agregó compatibilidad con AES-256-GCM en Windows Server 2022 y Windows 10,
versión 21H1.
Además de SMB 3.1.1, Azure Files expone la configuración de seguridad que cambia el
comportamiento del protocolo SMB. Con esta versión, puede configurar las versiones de
protocolo SMB permitidas, las opciones de cifrado del canal SMB, los métodos de
autenticación y las opciones de cifrado de vales de Kerberos. De manera
predeterminada, Azure Files habilita las opciones más compatibles, pero estas opciones
se pueden cambiar en cualquier momento.
Configuración de seguridad de SMB

Información de la versión SMB de Windows y Linux
Introducción a las características de SMB en la documentación de Windows Server
2\.º trimestre de 2021 (abril, mayo, junio)
Reservas de almacenamiento premium, de acceso frecuente y de

acceso esporádico
Azure Files admite reservas de almacenamiento (también denominadas instancias
reservadas). Las reservas de Azure Files le permiten conseguir un descuento en el
almacenamiento mediante la confirmación previa del uso del almacenamiento.
Azure Files admite reservas en los niveles premium, de acceso frecuente y de acceso
esporádico. Las reservas se venden en unidades de 10 TiB o 100 TiB, por periodos de un
año o tres años.
Descripción de la facturación de Azure Files

Optimización de costos para Azure Files con las reservas
Mejora de la experiencia del portal para la unión de dominios a

Active Directory
Se ha mejorado la experiencia de unirse a un dominio de una cuenta de

almacenamiento de Azure para ayudar a guiar a los administradores de recursos
compartidos de archivos de Azure por primera vez a través del proceso. Al seleccionar
Active Directory en File share settings (Configuración de recursos compartidos de
archivos) en la sección File shares (Recursos compartidos de archivos) de Azure Portal,
se le guiará por los pasos necesarios para la unión a un dominio.
Introducción a las opciones de autenticación basadas en la identidad de

Azure Files para el acceso con SMB
1\.er trimestre de 2021 (enero, febrero, marzo)
Administración de Azure Files disponible ahora a través del plano

de control
Las API de administración de los recursos de Azure Files, el servicio de archivos y los
recursos compartidos de archivos están disponibles ahora a través del plano de control
(proveedor de recursos Microsoft.Storage ). Esto permite crear recursos compartidos de
archivos de Azure con una plantilla de Azure Resource Manager o Bicep, para que sean
totalmente administrables cuando el plano de datos (es decir, la API de FileREST) no
está accesible (como cuando el punto de conexión público de la cuenta de
almacenamiento está deshabilitado) y para admitir la semántica de control de acceso
basado en roles (RBAC) completa.
Se recomienda administrar Azure Files a través del plano de control en la mayoría de los
casos. Para admitir la administración del servicio de archivos y los recursos compartidos
de archivos a través del plano de control, Azure Portal, el módulo PowerShell de
Azure Storage y la CLI de Azure se han actualizado para admitir la mayoría de las
acciones de administración a través del plano de control.
Para conservar el comportamiento de los scripts existentes, el módulo PowerShell de

Azure Storage y la CLI de Azure mantienen los comandos existentes que utilizan el plano
de datos para administrar el servicio de archivos y los recursos compartidos de archivos,
además de agregar nuevos comandos para usar el plano de control. Las solicitudes del
portal solo pasan por el proveedor de recursos del plano de control. Los comandos de
PowerShell y la CLI se denominan de la siguiente manera:
Az.Storage PowerShell:
Los cmdlets de recurso compartido de archivos del plano de control llevan el
prefijo Rm , por ejemplo: New-AzRmStorageShare , Get-AzRmStorageShare , Update-
AzRmStorageShare y Remove-AzRmStorageShare .
Los cmdlets de recurso compartido de archivos de plano de datos tradicionales

no tienen prefijo, por ejemplo: New-AzStorageShare , Get-AzStorageShare , Set-
AzStorageShareQuota y Remove-AzStorageShare .
Los cmdlets para administrar el servicio de archivos solo están disponibles a

través del plano de control y no tienen ningún prefijo especial, por ejemplo,
Get-AzStorageFileServiceProperty y Update-AzStorageFileServiceProperty .
CLI de Azure Storage:

Los comandos del recurso compartido de archivos del plano de control están
disponibles en el grupo de comandos az storage share-rm , por ejemplo: az
storage share-rm create , az storage share-rm update , etc.
Los comandos del recurso compartido de archivos tradicional están disponibles

en el grupo de comandos az storage share , por ejemplo: az storage share
create , az storage share update , etc.
Los comandos para administrar el servicio de archivos solo están disponibles a

través del plano de control y no están disponibles a través del grupo de
comandos az storage account file-service-properties , por ejemplo: az
storage account file-service-properties show y az storage account file-
service-properties update .
Para obtener más información sobre la API de administración de Azure Files, consulte:
Información general de la API de REST de Azure Files

API del plano de control (proveedor de recursos Microsoft.Storage ) para recursos
de Azure Files:
FileService
FileShare
Azure PowerShell y CLI de Azure
Consulte también
Creación de un recurso compartido de
archivos SMB de Azure
Artículo • 21/10/2023
Para crear un recurso compartido de archivos de Azure, debe responder a tres

preguntas sobre cómo lo usará:
¿Cuáles son los requisitos de rendimiento para el recurso compartido de

archivos de Azure?
Azure Files ofrece recursos compartidos de archivos estándar, que se hospedan en
hardware basado en disco duro (HDD), y recursos compartidos de archivos
prémium, que se hospedan en hardware basado en disco de estado sólido (SSD).
¿Cuáles son los requisitos de redundancia para el recurso compartido de

archivos de Azure?
Los recursos compartidos de archivos estándar ofrecen almacenamiento con
redundancia local (LRS), redundancia de zona (ZRS), redundancia geográfica (GRS)
o redundancia de zona geográfica (GZRS). Sin embargo, la característica de
recursos compartido de archivos de gran tamaño solo se admite en los recursos
compartidos de archivos con redundancia local y redundancia de zona. Los
recursos compartidos de archivos prémium no admiten ninguna forma de
redundancia geográfica.
Los recursos compartidos de archivos prémium están disponibles con redundancia

local y redundancia de zona en un subconjunto de regiones. Para averiguar si los
recursos compartidos de archivos prémium están disponibles en su región,
consulte los productos disponibles por región . Para más información, consulte
Redundancia de Azure Files.
¿Qué tamaño de recurso compartido de archivos necesita?

En las cuentas de almacenamiento con redundancia local y de zona, los recursos
compartidos de archivos de Azure pueden abarcar hasta 100 TiB. Sin embargo, en
las cuentas de almacenamiento con redundancia geográfica y de zona geográfica,
los recursos compartidos de archivos de Azure solo pueden abarcar hasta 5 TiB, a
menos que se registre en el almacenamiento con redundancia geográfica para
recursos compartidos de archivos grandes (versión preliminar).
Para más información sobre estas tres opciones, consulte Planeamiento de una
implementación de Azure Files.
Se aplica a
Requisitos previos
En este artículo, se da por supuesto que ya ha creado una suscripción a Azure. Si
todavía no tiene una suscripción, cree una cuenta gratuita antes de empezar.
Si planea usar Azure PowerShell, instale la versión más reciente.
Si planea usar la CLI de Azure, instale la versión más reciente.

implementar varios recursos compartidos de archivos.
Azure admite varios tipos de cuentas de almacenamiento para los distintos escenarios
de almacenamiento que pueden tener los clientes, pero hay dos tipos principales de
cuentas de almacenamiento para Azure Files. El tipo de cuenta de almacenamiento que
debe crear depende de si desea crear un recurso compartido de archivos estándar o un
recurso compartido de archivos prémium:

como contenedores de blobs, colas o tablas. Los recursos compartidos de archivos
se pueden implementar en los niveles de transacción optimizada (valor
predeterminado), acceso frecuente o acceso esporádico.

(contenedores de blobs, colas, tablas, etc.) en una cuenta FileStorage.
Portal
Para crear una cuenta de almacenamiento mediante Azure Portal, seleccione +

Crear un recurso en el panel. En la ventana de búsqueda de Azure Marketplace que
aparece, busque cuenta de almacenamiento y seleccione el resultado de la
búsqueda resultante. Esta operación le dirigirá a una página de información general
de las cuentas de almacenamiento. Seleccione Crear para continuar con el Asistente
para crear cuentas de almacenamiento.
Aspectos básicos
La primera sección que se debe rellenar para crear una cuenta de almacenamiento
se denomina Datos básicos. Contiene todos los campos obligatorios para crear una
cuenta de almacenamiento. Para crear una cuenta de almacenamiento de GPv2,
asegúrese de que el botón de radio Rendimiento está establecido en Estándar y
que la lista desplegable Tipo de cuenta tiene seleccionada la opción StorageV2
(general purpose v2) StorageV2 (uso general V2).
Para crear una cuenta de almacenamiento de FileStorage, asegúrese de que el
botón de radio Rendimiento esté configurado en Prémium y Fileshares esté
seleccionado en la lista desplegable Tipo de cuenta prémium.
Los demás campos de datos básicos son independientes de la elección de la cuenta

de almacenamiento:
Nombre de la cuenta de almacenamiento: nombre del recurso de la cuenta

de almacenamiento que se va a crear. Este nombre debe ser único
globalmente. El nombre de la cuenta de almacenamiento se usará como el
nombre del servidor al montar un recurso compartido de archivos de Azure a
través de SMB. Los nombres de cuenta de almacenamiento deben tener una
longitud de entre 3 y 24 caracteres. Solo pueden contener números y letras
minúsculas.
Ubicación: región de la cuenta de almacenamiento donde se va a realizar la
implementación. Puede ser la región asociada al grupo de recursos o
cualquier otra región disponible.
Replication (Replicación): aunque se trata de replicación etiquetada, este
campo significa redundancia en realidad; este es el nivel de redundancia
deseado: redundancia local (LRS), redundancia de zona (ZRS), redundancia
geográfica (GRS) y redundancia de zona geográfica (GZRS). Esta lista
desplegable también contiene redundancia geográfica con acceso de lectura
(RA-GRS) y redundancia de zona geográfica con acceso de lectura (RA-GZRS),
que no se aplican a los recursos compartidos de archivos de Azure. Los
recursos compartidos de archivos creados en una cuenta de almacenamiento
con estas opciones seleccionadas tendrán redundancia geográfica o
redundancia de zona geográfica, respectivamente.
Redes
La sección Redes le permite configurar las opciones de redes. Esta configuración es

opcional para la creación de la cuenta de almacenamiento y se puede configurar
más adelante si lo desea. Para obtener más información sobre estas opciones, vea
Consideraciones de redes para Azure Files.
Protección de datos
La sección de protección de datos le permite configurar la directiva de eliminación
temporal para recursos compartidos de archivos de Azure en su cuenta de
almacenamiento. Otras opciones relacionadas con la eliminación temporal de blobs
y contenedores, la restauración a un momento dado de contenedores, el control de
versiones y la fuente de cambios solo se aplican a Azure Blob Storage.
Avanzadas
La sección Opciones avanzadas contiene varias opciones de configuración
importantes para los recursos compartidos de archivos de Azure:
Se requiere transferencia segura: este campo indica si la cuenta de

almacenamiento requiere cifrado en tránsito para la comunicación con la
cuenta de almacenamiento. Si requiere compatibilidad con SMB 2.1, debe
deshabilitarlo.
Recursos compartidos de archivos grandes: este campo habilita la cuenta de

almacenamiento para los recursos compartidos de archivos de hasta 100 TiB.
Al habilitar esta característica, se limita la cuenta de almacenamiento a las
opciones de almacenamiento con redundancia local y redundancia de zona
solamente. Una vez habilitada una cuenta de almacenamiento de GPv2 para
los recursos compartidos de archivos grandes, no se puede deshabilitar la
funcionalidad de recurso compartido de archivos grandes. Las cuentas de
almacenamiento de FileStorage (cuentas de almacenamiento para recursos
compartidos de archivos prémium) no tienen esta opción, ya que todos los
recursos compartidos de archivos prémium se pueden escalar hasta 100 TiB.
Los demás valores de configuración que están disponibles en la pestaña Opciones

avanzadas (espacio de nombres jerárquico para Azure Data Lake Storage Gen 2,
nivel de blob predeterminado, NFSv3 para Blob Storage, etc.) no se aplican a Azure
Files.
） Importante
La selección del nivel de acceso del blob no afecta al nivel del recurso
Etiquetas
Las etiquetas son pares nombre-valor que permiten categorizar los recursos y ver
una facturación consolidada mediante la aplicación de la misma etiqueta en varios
recursos y grupos de recursos. Son opcionales y se pueden aplicar después de la
creación de la cuenta de almacenamiento.
Revisar y crear
El paso final para crear la cuenta de almacenamiento es seleccionar el botón Crear
en la pestaña Revisar y crear. Este botón no estará disponible a menos que se
hayan rellenado todos los campos obligatorios para una cuenta de
almacenamiento.
Habilitación de recursos compartidos de archivos de gran

tamaño en una cuenta existente
Antes de crear un recurso compartido de archivos de Azure en una cuenta de
almacenamiento existente, es posible que quiera habilitar los recursos compartidos de
archivos de gran tamaño (de hasta 100 TiB) en la cuenta de almacenamiento si todavía
no lo ha hecho. Las cuentas de almacenamiento estándar que usan LRS o ZRS se
pueden actualizar para admitir recursos compartidos de archivos grandes sin provocar
tiempo de inactividad para los recursos compartidos de archivos existentes en la cuenta
de almacenamiento. Si tiene una cuenta GRS, GZRS, RA-GRS o RA-GZRS, deberá
convertirla en una cuenta LRS antes de continuar o registrarse para la versión preliminar
de redundancia geográfica de Azure Files para recursos compartidos de archivos
grandes.
Portal
1. Abra Azure Portal y navegue hasta la cuenta de almacenamiento donde
quiere habilitar los recursos compartidos de archivos grandes.
2. Seleccione Configuración en la sección Configuración.
3. Vaya a la configuración Recursos compartidos de archivos grandes en la
parte inferior de la página. Si se establece en Deshabilitado, cambie la
configuración a Habilitado.
4. Seleccione Guardar.

Una vez que haya creado una cuenta de almacenamiento, puede crear un recurso
compartido de archivos. Este proceso es prácticamente el mismo, independientemente
de si usa un recurso compartido de archivos prémium o un recurso compartido de
archivos estándar. Debe tener en cuenta las siguientes diferencias:
Los recursos compartidos de archivos estándar pueden implementarse en uno de los

niveles estándar: optimizado para transacciones (valor predeterminado), acceso
frecuente o acceso esporádico. Se trata de un nivel de recurso compartido de archivos
que no se ve afectado por el nivel de acceso de blob de la cuenta de almacenamiento
(esta propiedad solo se relaciona con Azure Blob Storage, no está relacionada con
Azure Files). Puede cambiar el nivel del recurso compartido en cualquier momento una
vez implementado. Los recursos compartidos de archivos prémium no se pueden
convertir directamente a ningún nivel estándar.
） Importante
Los recursos compartidos de archivos se pueden mover entre niveles dentro de los
tipos de cuenta de almacenamiento GPv2 (transacción optimizada, nivel de acceso
frecuente y nivel de acceso esporádico). Los movimientos de recursos compartidos
entre niveles incurren en transacciones: el traslado de un nivel de acceso frecuente
a un nivel de acceso esporádico incurrirá en el cargo de transacción de escritura del
nivel de acceso esporádico, mientras que si dicho traslado se realiza de un nivel
esporádico a un nivel frecuente, todos los archivos incurrirán en el cargo de
transacción de lectura del nivel de acceso esporádico.
Portal
Siga estas instrucciones para crear un nuevo recurso compartido de archivos de
Azure mediante Azure Portal.
1. Si acaba de crear la cuenta de almacenamiento, puede navegar a esta desde la

pantalla de implementación. Para ello, seleccione Ir al recurso. Una vez en la
cuenta de almacenamiento, seleccione Recurso compartido de archivos en la
tabla de contenido de la cuenta de almacenamiento.
2. En la lista de recursos compartidos de archivos, debería ver los recursos

compartidos de archivos creados previamente en esta cuenta de
almacenamiento; se muestra una tabla vacía si aún no se han creado recursos
compartidos de archivos. Seleccione + Recurso compartido de archivos para
crear un recurso compartido de archivos.
3. La hoja Nuevo recurso compartido de archivos debería aparecer en la pantalla.

Complete los campos de la pestaña Básico de la hoja de nuevo recurso
compartido de archivos para crear un recurso de este tipo:
Nombre: nombre del recurso compartido de archivos que se va a crear.
Nivel: nivel seleccionado para un recurso compartido de archivos

estándar. Este campo solo está disponible en un tipo de cuenta de
almacenamiento de uso general (GPv2). Puede elegir los niveles
optimizado para transacciones, acceso frecuente o acceso esporádico. El
nivel del recurso compartido de archivos se puede cambiar en cualquier
momento. Se recomienda elegir el nivel de acceso más frecuente posible
durante una migración para minimizar los gastos de transacciones y, a
continuación, cambiar a un nivel inferior si lo desea una vez completada
la migración.
Capacidad aprovisionada: solo para recursos compartidos de archivos

prémium; la capacidad aprovisionada es la cantidad que se le facturará,
independientemente del uso real. Este campo solo está disponible en un
tipo de cuenta de almacenamiento FileStorage. Los valores de IOPS y
rendimiento disponibles en un recurso compartido de archivos prémium
se basan en la capacidad aprovisionada, por lo que puede aprovisionar
más capacidad para obtener más rendimiento. El recurso compartido de
archivos prémium mínimo es de 100 GiB. Para obtener más información
sobre cómo planear un recurso compartido de archivos prémium,
consulte el tema sobre el aprovisionamiento de recursos compartidos de
archivos prémium.
4. Seleccione la pestaña Copia de seguridad. De forma predeterminada, la copia
de seguridad se habilita al crear un recurso compartido de archivos de Azure
mediante Azure Portal. Si quiere deshabilitar la copia de seguridad para el
recurso compartido de archivos, desactive la casilla Habilitar copia de
seguridad. Si quiere habilitar la copia de seguridad, puede dejar los valores
predeterminados o bien crear un almacén de Recovery Services en la misma
región y suscripción de la cuenta de almacenamiento. Para crear una directiva
de copia de seguridad, seleccioneCrear una nueva directiva.
5. Seleccione Revisar y crear y, después, Crear para crear el recurso compartido

７ Nota
El nombre del recurso compartido de archivos debe estar formado por letras
minúsculas, números y guiones únicos, y debe comenzar y terminar con un número
o una letra en minúscula. El nombre no puede contener dos guiones consecutivos.
Para obtener detalles completos sobre cómo asignar un nombre a los recursos
compartidos y los archivos, consulte Asignación de nombres y referencia a
recursos compartidos, directorios, archivos y metadatos.
Cambio del nivel de un recurso compartido de archivos

de Azure
Los recursos compartidos de archivos que se implementan en una cuenta de
almacenamiento de uso general v2 (GPv2) pueden pertenecer a los niveles optimizado
para transacciones, de acceso frecuente o de acceso esporádico. Puede cambiar el nivel
del recurso compartido de archivos de Azure en cualquier momento, en función de los
costos de las transacciones, tal como se ha descrito anteriormente.
Portal
En la página de la cuenta de almacenamiento principal, seleccione Recursos

compartidos de archivos y seleccione el icono con la etiqueta Recursos
compartidos de archivos (también puede navegar a Recursos compartidos de
archivos a través de la tabla de contenido de la cuenta de almacenamiento).
En la lista de tabla de recursos compartidos de archivos, seleccione el recurso para
el que desea cambiar el nivel. En la página información general del recurso
compartido de archivos, seleccione Cambiar nivel en el menú.
En el cuadro de diálogo resultante, seleccione el nivel deseado: optimizado para

transacciones, acceso frecuente o acceso esporádico.
Expansión de recursos compartidos de archivos existentes
Si habilita recursos compartidos de archivos grandes en una cuenta de almacenamiento
existente, tendrá que expandir los recursos compartidos de archivos existentes de esa
cuenta de almacenamiento para aprovechar el aumento de la capacidad y la escala.
Portal
1. En la cuenta de almacenamiento, seleccione Recurso compartido de archivos.

2. Haga clic con el botón derecho en el recurso compartido de archivos y
seleccione Cuota.
3. Escriba el nuevo tamaño que quiera y, luego, seleccione Aceptar.
Eliminación de un recurso compartido de

archivos
Para eliminar un recurso compartido de archivos de Azure, puede usar Azure Portal,
Azure PowerShell o la CLI de Azure. Los recursos compartidos de archivos SMB de Azure
se pueden recuperar dentro del período de retención de la eliminación temporal.
Portal
1. Abra Azure Portal y vaya a la cuenta de almacenamiento que contiene el

recurso compartido de archivos que quiere eliminar.
2. Abra la cuenta de almacenamiento y seleccione Recursos compartidos de
archivos.
3. Seleccione el recurso compartido de archivos que quiere eliminar.
4. Seleccione Eliminar recurso compartido.
5. Active la casilla que confirma que acepta la eliminación del recurso
compartido de archivos y todo su contenido.
6. Seleccione Eliminar.

Pasos siguientes
Planeamiento de una implementación de Azure Files o Planeamiento de una
implementación de Azure File Sync.
Consideraciones de redes para Azure Files.
Monte un recurso compartido de archivos SMB en Windows, macOS o Linux.
compartido de archivos NFS de Azure y
montaje del mismo en una máquina
virtual Linux mediante Azure Portal
Artículo • 10/10/2023

servidor) o el protocolo NFS (Network File System) estándar del sector. Los protocolos
NFS y SMB se admiten en máquinas virtuales (VM) de Azure que ejecutan Linux. En este
tutorial se muestra cómo crear un recurso compartido de archivos de Azure mediante el
protocolo NFS y conectarlo a una máquina virtual Linux.
En este tutorial, aprenderá lo siguiente:

＂ Implementación de una máquina virtual Linux
＂ Creación de un recurso compartido de archivos NFS
＂ Montaje del recurso compartido de archivos en la máquina virtual
Se aplica a
Introducción
Creación de una cuenta de almacenamiento FileStorage

Para poder trabajar con un recurso compartido de archivos NFS 4.1 de Azure, es
necesario que cree una cuenta de almacenamiento de Azure con el nivel de rendimiento
prémium. Actualmente, los recursos compartidos de NFS 4.1 solo están disponibles
como recursos compartidos de archivos prémium.
1. En el menú de Azure Portal, seleccione Todos los servicios. En la lista de recursos,

escriba Cuentas de almacenamiento. Cuando comience a escribir, la lista se filtrará
en función de la entrada. Seleccione Cuentas de almacenamiento.
2. En la ventana Cuentas de almacenamiento que aparece, elija + Crear.
3. En la pestaña Aspectos básicos, seleccione la suscripción en la que se va a crear la
4. En el campo Grupo de recursos, seleccione Crear nuevo para crear un grupo de
recursos nuevo para usar en este tutorial.
5. Escriba un nombre para la cuenta de almacenamiento. El nombre que elija debe
ser único en Azure. El nombre también debe tener una longitud de entre 3 y 24
caracteres, y solo puede contener números y letras minúsculas.
predeterminada. Azure admite recursos compartidos de archivos NFS en las
mismas regiones que admiten el almacenamiento de archivos prémium.
7. Seleccione el nivel de rendimiento Premium para almacenar los datos en unidades
de estado sólido (SSD). En Tipo de cuenta Premium, seleccione Recursos
8. Mantenga la opción de replicación establecida en su valor predeterminado de
Almacenamiento con redundancia local (LRS).
10. Cuando aparezca la notificación Validación superada, seleccione Crear. Debería
ver una notificación informándole de que la implementación está en curso.
En la imagen siguiente se muestra la configuración de la pestaña Aspectos básicos de

una nueva cuenta de almacenamiento:

Implementación de una máquina virtual de

Azure que ejecuta Linux
A continuación, cree una máquina virtual de Azure que ejecute Linux para representar el
servidor en el entorno local. Al crear la máquina virtual, se creará automáticamente una
red virtual. El protocolo NFS solo se puede usar desde una máquina dentro de una red
virtual.
1. Seleccione Inicio y, a continuación, Máquinas virtuales en Servicios de Azure.
2. Seleccione + Crear y, después, + Máquina virtual de Azure.
3. En la pestaña Aspectos básicos, en Detalles del proyecto, asegúrese de que la

suscripción y el grupo de recursos correctos están seleccionados. En Detalles de
instancia, escriba myVM en Nombre de máquina virtual y seleccione la misma
región que la cuenta de almacenamiento. Elija la distribución de Linux para la
imagen. Deje los demás valores predeterminados. El tamaño y los precios
predeterminados solo se muestran como ejemplo. La disponibilidad y los precios
del tamaño dependen de su región y suscripción.

4. En Cuenta de administrador , seleccione Clave pública SSH. Deje el resto de

valores predeterminados.
5. En Reglas de puerto de entrada > Puertos de entrada públicos, elija Permitir los
puertos seleccionados y luego seleccione SSH (22) y HTTP (80) en la lista
desplegable.

） Importante
Solo se recomienda establecer puertos SSH abiertos a Internet para realizar

pruebas. Si quiere cambiar esta configuración más adelante, vuelva a la
pestaña Aspectos básicos.
6. Seleccione el botón Revisar y crear de la parte inferior de la página.
7. En la página Crear una máquina virtual verá los detalles de la máquina virtual que
va a crear. Anote el nombre de la red virtual. Cuando esté preparado, seleccione
Crear.
8. Cuando se abra la ventana Generar nuevo par de claves, seleccione Descargar la

clave privada y crear el recurso. El archivo de clave se descargará como
myVM_key.pem. Asegúrese de saber dónde se descargó el archivo .pem, ya que
necesitará la ruta de acceso al archivo para conectarse a la máquina virtual.
Verá un mensaje que indica que la implementación está en curso. Espere unos minutos
a que se complete la implementación.

NFS de Azure
Ahora está listo para crear un recurso compartido de archivos NFS y proporcionar
seguridad de nivel de red para el tráfico NFS.
Adición de un recurso compartido de archivos a la cuenta

de almacenamiento
3. Seleccione Almacenamiento de datos y Recursos compartidos de archivos en el

panel de la cuenta de almacenamiento.
5. Asigne al nuevo recurso compartido de archivos el nombre qsfileshare y escriba

"100" para la Capacidad mínima aprovisionada o aprovisione más capacidad
(hasta 102 400 GiB) para obtener más rendimiento. Seleccione el protocolo NFS,
deje seleccionada la opción Sin restringir raíz y seleccione Crear.

Configurar un punto de conexión privado o un punto de

conexión de servicio
A continuación, configure un punto de conexión privado para la cuenta de
almacenamiento. Esto proporciona a la cuenta de almacenamiento una dirección IP
privada desde el espacio de direcciones de la red virtual. Se aplican las tasas de
procesamiento de datos estándar para los puntos de conexión privados. Si no
necesita una dirección IP estática, puede usar un punto de conexión de servicio en su
lugar. No se realiza ningún cargo adicional por el uso de puntos de conexión de servicio.
1. Seleccione el recurso compartido de archivos qsfileshare. Debería ver un cuadro de

diálogo que indica Conectar a este recurso compartido de NFS desde Linux. En
Configuración de red, seleccione Opciones de revisión.
2. A continuación, seleccione Configurar un punto de conexión privado.
3. Seleccione + Punto de conexión privado.

4. Deje Suscripción y Grupo de recursos como están. En Instancia, proporcione un
nombre y seleccione una región para el nuevo punto de conexión privado. El
punto de conexión privado debe estar en la misma región que la red virtual, por lo
que debe usar la misma región que especificó al crear la máquina virtual. Cuando
haya completado todos los campos, seleccione Siguiente: Recurso.
5. Confirme que la Suscripción, el Tipo de recurso y el Recurso son correctos y

seleccione Archivo en la lista desplegable Subrecurso de destino. A continuación,
seleccione Siguiente: Red virtual.

6. En Redes, seleccione la red virtual asociada a la máquina virtual y deje la subred
predeterminada. En la sección Configuración de IP privada, seleccione Asignar
dirección IP de forma dinámica. Seleccione Next: DNS (Siguiente: DNS).
7. En Integrar con la zona DNS privada, seleccione Sí. Asegúrese de que están
seleccionados la suscripción y el grupo de recursos correctos y, después,
seleccione Siguiente: Etiquetas.
8. Opcionalmente, puede aplicar etiquetas para clasificar los recursos, como aplicar el
9. Azure intentará validar el punto de conexión privado. Una vez completada la

validación, seleccione Crear. Verá una notificación informándole de que la
implementación está en curso. Transcurridos unos minutos, debería ver una
notificación indicando que la implementación se ha completado.

Azure Files no admite actualmente el cifrado en tránsito con el protocolo NFS y se basa
en la seguridad de nivel de red. Por lo tanto, deberá deshabilitar la transferencia segura.

almacenamiento.
4. Seleccione el recurso compartido de archivos NFS que ha creado. En

Configuración de transferencia segura, seleccione Cambiar configuración.

5. Cambie la opción Se requiere transferencia segura a Deshabilitado y seleccione
Guardar. El cambio puede tardar hasta 30 segundos en surtir efecto.

Cree una conexión SSH con la máquina virtual.
1. Seleccione Inicio y, a continuación, Máquinas virtuales.
2. Seleccione la máquina virtual Linux que ha creado para este tutorial y asegúrese de
que su estado es En ejecución. Tome nota de la dirección IP pública de la máquina
virtual y cópiela en el portapapeles.
3. Si está en una máquina Mac o Linux, abra un símbolo del sistema de Bash. Si está
en una máquina Windows, abra un símbolo del sistema de PowerShell.
4. Cuando se le solicite, abra una conexión SSH a la máquina virtual. Reemplace la

dirección IP por la de la máquina virtual y reemplace la ruta de acceso al archivo
.pem por la ruta de acceso a la ubicación en la que se descargó el archivo de clave.
Consola
ssh -i .\Downloads\myVM_key.pem azureuser@20.25.14.85
Si recibe una advertencia de que no se puede establecer la autenticidad del host, escriba
sí para continuar con la conexión a la máquina virtual. Deje abierta la conexión SSH para
el paso siguiente.
 Sugerencia
Ahora la clave SSH que creó se puede usar la próxima vez que cree una máquina
virtual en Azure. Solo tiene que seleccionar la opción Usar la clave existente
almacenada en Azure en Origen de clave pública SSH la próxima vez que cree una
máquina virtual. Ya dispone de la clave privada en el equipo, por lo que no tendrá
que descargar nada.
Montaje de recurso compartido de archivos

NFS
Ahora que ha creado un recurso compartido de NFS, para usarlo debe montarlo en el
cliente Linux.

almacenamiento y seleccione el recurso compartido de archivos NFS que ha
creado.
4. Debería consultar Conexión a este recurso compartido de archivos NFS desde

Linux junto con comandos de ejemplo para usar NFS en la distribución de Linux y
un script de montaje que contenga las opciones de montaje necesarias. Para ver
otras opciones de montaje recomendadas, consulte Montaje del recurso
compartido de archivos de Azure NFS en Linux.
） Importante
El script de montaje proporcionado montará el recurso compartido NFS solo
hasta que se reinicie la máquina Linux. Para montar automáticamente el
recurso compartido cada vez que se reinicia la máquina, consulte Montaje de
un recurso compartido NFS mediante /etc/fstab.
5. Seleccione su distribución de Linux.
6. Mediante la conexión SSH que ha creado con la máquina virtual, escriba los
comandos de ejemplo para usar NFS y montar el recurso compartido de archivos.
Ahora ha montado el recurso compartido de archivos NFS y está listo para almacenar
archivos.

2. Seleccione el grupo de recursos que ha creado para este tutorial.
Pasos siguientes
Obtenga más información sobre el uso de recursos compartidos de archivos NFS
de Azure
.
Uso de Espacios de nombres DFS con
Azure Files
Artículo • 24/05/2023
Espacios de nombres del Sistema de archivos distribuido, normalmente conocido como

Espacios de nombres DFS o DFS-N, es un rol de servidor de Windows Server muy
utilizado para simplificar la implementación y el mantenimiento de los recursos
compartidos de archivos SMB en la producción. Espacios de nombres DFS es una
tecnología de virtualización de espacios de nombres de almacenamiento, lo que
significa que le permite proporcionar una capa de direccionamiento indirecto entre la
ruta de acceso UNC de los recursos compartidos de archivos y los recursos compartidos
de archivos en sí. Los espacios de nombres DFS funcionan con recursos compartidos de
archivos SMB y se hospedan con independencia de estos: se pueden usar con recursos
compartidos de SMB hospedados en un servidor de archivos de Windows local con o
sin Azure File Sync, recursos compartidos de archivos de Azure directamente, recursos
compartidos de archivos SMB hospedados en Azure NetApp Files u otras ofertas de
terceros, e incluso con recursos compartidos de archivos hospedados en otras nubes.
Básicamente, Espacios de nombres DFS proporciona una asignación entre una ruta de
acceso UNC descriptiva, como \\contoso\shares\ProjectX , y la ruta de acceso UNC
subyacente del recurso compartido SMB, como \\Server01-Prod\ProjectX o
\\storageaccount.file.core.windows.net\projectx . Cuando el usuario final quiere
navegar al recurso compartido de archivos, escribe la ruta de acceso UNC descriptiva,

pero el cliente SMB accede a la ruta de acceso SMB subyacente de la asignación.
También puede ampliar este concepto básico para que asuma un nombre de servidor de
archivos existente, como \\MyServer\ProjectX . Puede usar esta funcionalidad para
conseguir lo siguiente:
Proporcionar un nombre a prueba de migraciones para un conjunto lógico de

datos. En este ejemplo, tiene una asignación como \\contoso\shares\Engineering
que se asigna a \\OldServer\Engineering . Cuando complete la migración a
Azure Files, puede cambiar la asignación para que la ruta de acceso UNC
descriptiva apunte a \\storageaccount.file.core.windows.net\engineering .
Cuando un usuario final acceda a la ruta de acceso UNC descriptiva, se le redirigirá
sin problemas a la ruta de acceso del recurso compartido de archivos de Azure.
Establecer un nombre común para un conjunto lógico de datos que se distribuye a

varios servidores en distintos sitios físicos, por ejemplo, a través de Azure File Sync.
En este ejemplo, un nombre como \\contoso\shares\FileSyncExample se asigna a
varias rutas de acceso UNC, como \\FileSyncServer1\ExampleShare ,
\\FileSyncServer2\DifferentShareName y \\FileSyncServer3\ExampleShare . Cuando
el usuario accede a la UNC descriptiva, se le proporciona una lista de rutas de
acceso UNC posibles y este elige la más cercana en función de las definiciones de
sitio de Windows Server Active Directory (AD).
Ampliar un conjunto lógico de datos más allá de los umbrales de tamaño, E/S u
otras escalas. Esto es habitual cuando se trabaja con directorios de usuario, en los
que cada usuario obtiene su carpeta propia en un recurso compartido, o con los
recursos compartidos temporales, donde los usuarios obtienen un espacio
arbitrario para administrar las necesidades de datos temporales. Con Espacios de
nombres DFS, se unen varias carpetas en un espacio de nombres cohesionado. Por
ejemplo, \\contoso\shares\UserShares\user1 se asigna a
\\storageaccount.file.core.windows.net\user1 ,
\\contoso\shares\UserShares\user2 se asigna a
\\storageaccount.file.core.windows.net\user2 y así sucesivamente.
Puede ver un ejemplo de cómo usar Espacios de nombres DFS con su implementación
de Azure Files en el vídeo de introducción siguiente.
７ Nota
Vaya al minuto 10:10 del vídeo para ver cómo configurar Espacios de nombres DFS.
Si ya tiene un espacio de nombres DFS, no es necesario realizar ningún paso especial

para usarlo con Azure Files y File Sync. Si accede al recurso compartido de archivos de
Azure desde el entorno local, se aplican las consideraciones habituales para las redes.
Consulte Consideraciones de redes para Azure Files para obtener más información.
Se aplica a
Tipos de espacios de nombres

Espacios de nombres DFS proporciona dos tipos de espacio de nombres principales:
Espacio de nombres basado en dominio: un espacio de nombres hospedado

como parte del dominio de Windows Server AD. Los espacios de nombres
hospedados como parte de AD tendrán una ruta de acceso UNC que contiene el
nombre del dominio, por ejemplo, \\contoso.com\shares\myshare si el dominio es
contoso.com . Los espacios de nombres basados en dominio admiten límites de
escalado más altos y redundancia integrada a través de AD. Asimismo, no pueden

ser un recurso en clúster de conmutación por error.
Espacio de nombres independiente: un espacio de nombres hospedado en un
servidor individual, no como parte de Windows Server AD. El nombre de los
espacios de nombres independientes se basarán en el nombre del servidor
independiente, como \\MyStandaloneServer\shares\myshare , donde el servidor
independiente se llama MyStandaloneServer . Los espacios de nombres
independientes admiten destinos de escala inferiores a los espacios de nombres
basados en dominio, pero pueden hospedarse como un recurso en clúster de
Requisitos
Para usar Espacios de nombres DFS con Azure Files y File Sync, debe tener los recursos
siguientes:
Un dominio de Active Directory. Se puede hospedar en cualquier lugar que quiera,

como en el entorno local, en una máquina virtual (VM) de Azure o incluso en otra
nube.
Una instancia de Windows Server que puede hospedar el espacio de nombres. Un
patrón de implementación común para los espacios de nombres DFS consiste en
usar el controlador de dominio de Active Directory para hospedarlos, si bien los
espacios de nombres pueden configurarse desde cualquier servidor que tenga el
rol de servidor Espacios de nombres DFS instalado. Espacios de nombres DFS está
disponible en todas las versiones compatibles de Windows Server.
Un recurso compartido de archivos SMB hospedado en un entorno unido a un
dominio, como un recurso compartido de archivos de Azure hospedado en una
cuenta de almacenamiento unida a un dominio o un recurso compartido de
archivos hospedado en un servidor de archivos de Windows unido a un dominio
con Azure File Sync. Para obtener más información sobre cómo unir a un dominio
la cuenta de almacenamiento, consulte el artículo sobre la autenticación basada en
la identidad. Los servidores de archivos de Windows se unen a un dominio de la
misma manera, independientemente de que use Azure File Sync o no.
Los recursos compartidos de archivos SMB que quiere usar con Espacios de
nombres DFS deben ser accesibles desde las redes locales. Esto es un problema
sobre todo para los recursos compartidos de archivos de Azure; sin embargo,
técnicamente, se aplica a cualquier recurso compartido de archivos hospedado en
Azure o en cualquier otra nube. Para obtener más información sobre las redes,
consulte el documento sobre consideraciones de redes para el acceso directo.
Instalación del rol de servidor Espacios de

nombres DFS
Si ya está usando Espacios de nombres DFS o quiere configurar este rol en el
controlador de dominio, puede omitir estos pasos sin riesgo alguno.
Portal
Para instalar el rol de servidor Espacios de nombres DFS, abra el Administrador del
servidor en el servidor. Seleccione Administrar y, a continuación, elija Agregar roles
y características. El asistente que aparece le guía a través del proceso de instalación
de los componentes de Windows necesarios para ejecutar y administrar los
espacios de nombres DFS.
En la sección Tipo de instalación del asistente para instalación, seleccione el botón

de radio Instalación basada en características o en roles y elija Siguiente. En la
sección Selección del servidor, seleccione los servidores en los que quiera instalar
el rol de servidor Espacios de nombres DFS y elija Siguiente.
En la sección Roles de servidor, seleccione el rol Espacios de nombres DFS en la
lista de roles. Puede encontrarla en Servicios de archivos y
almacenamiento>Servicios de iSCSI y archivo. Al seleccionar el rol de servidor
Espacios de nombres DFS, también puede agregar cualquier característica o rol de
servidor compatible necesario que aún no tenga instalados.
Después de haber seleccionado el rol Espacios de nombres DFS, puede seleccionar

Siguiente en todas las pantallas posteriores y elegir Instalar tan pronto como se
habilite el botón en el asistente. Una vez completada la instalación, puede
configurar el espacio de nombres.
Uso de los nombres de servidor existentes con

la consolidación raíz
Un uso importante de los espacios de nombres DFS es asumir un nombre de servidor
existente para refactorizar el diseño físico de los recursos compartidos de archivos. Por
ejemplo, puede que quiera consolidar los recursos compartidos de archivos de varios
servidores de archivos antiguos en un único servidor de archivos durante una migración
de modernización. Normalmente, la familiaridad del usuario final y la vinculación de
documentos limitan la capacidad de consolidar los recursos compartidos de archivos de
distintos servidores de archivos en un solo host, pero la característica de consolidación
raíz de Espacios de nombres DFS permite establecer un único servidor para varios
nombres de servidor y enrutar al nombre de recurso compartido adecuado.
Si bien resulta útil para diversos escenarios de migración de centros de datos, la

consolidación raíz es especialmente útil para adoptar recursos compartidos de archivos
Azure nativos de nube debido a lo siguiente:
Los recursos compartidos de archivos de Azure no permiten mantener los nombres

de servidores locales existentes.
El acceso a los recursos compartidos de archivos de Azure debe realizarse a través
del nombre de dominio completo (FQDN) de la cuenta de almacenamiento. Por
ejemplo, el acceso a un recurso compartido de archivos de Azure llamado share
en la cuenta de almacenamiento storageaccount siempre se realiza a través de la
ruta de acceso UNC \\storageaccount.file.core.windows.net\share . Esto puede
resultar confuso para los usuarios finales que esperan un nombre corto
( \\MyServer\share , por ejemplo) o un nombre que sea un subdominio del nombre
de dominio de la organización (por ejemplo, \\MyServer.contoso.com\share ).
La consolidación raíz solo se puede usar con los espacios de nombres independientes. Si
ya tiene un espacio de nombres basado en dominio para los recursos compartidos de
archivos, no es necesario crear un espacio de nombres consolidado raíz.
Habilitación de la consolidación raíz

Para habilitar la consolidación raíz, establezca las claves del Registro siguientes desde
una sesión de PowerShell con privilegios elevados (o mediante la comunicación remota
de PowerShell).
PowerShell
New-Item `
-Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs" `
-Type Registry `
-ErrorAction SilentlyContinue
New-Item `
-Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters" `
-Type Registry `
New-Item `
-Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated"
`
-Type Registry `
Set-ItemProperty `
-Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated"
`
-Name "ServerConsolidationRetry" `
-Value 1
Creación de entradas DNS para los nombres de

servidores de archivos existentes
Para que los espacios de nombres DFS respondan a nombres de servidores de archivos
existentes, cree registros de alias (CNAME) para los servidores de archivos existentes
que apunten al nombre del servidor de Espacios de nombres DFS. El procedimiento
exacto para actualizar los registros DNS puede depender de los servidores que use la
organización y de si en esta se utilizan herramientas personalizadas para automatizar la
administración de DNS. Los pasos siguientes se muestran para el servidor DNS que se
incluye con Windows Server y que Windows AD usa de forma automática.
Portal
En un servidor DNS de Windows, abra la consola de administración de DNS. Para

encontrarla, seleccione el botón Inicio y escriba DNS. Vaya a la zona de búsqueda
directa del dominio. Por ejemplo, si el dominio es contoso.com , la zona de
búsqueda directa puede encontrarse en Zonas de búsqueda directa> contoso.com
en la consola de administración. La jerarquía exacta que se muestre en este cuadro
de diálogo dependerá de la configuración de DNS para la red.
Haga clic con el botón derecho en la zona de búsqueda directa y seleccione Nuevo
alias (CNAME) . En el cuadro de diálogo que aparece, escriba el nombre corto del
servidor de archivos que va a reemplazar (el nombre de dominio completo se
rellenará de forma automática en el cuadro de texto con la etiqueta Nombre de
dominio completo). En el cuadro de texto con la etiqueta Nombre de dominio
completo (FQDN) para el host de destino, escriba el nombre del servidor DFS-N
que ha configurado. Si quiere, puede usar el botón Examinar para ayudarle a
seleccionar el servidor. Seleccione Aceptar a fin de crear el registro CNAME para el
servidor.
Creación de un espacio de nombres
La unidad básica de administración de Espacios de nombres DFS es el espacio de
nombres. La raíz del espacio de nombres, o el nombre, es el punto inicial de este, de
forma que en la ruta de acceso UNC \\contoso.com\Public\ , la raíz de espacio de
nombres es Public .
Si usa los espacios de nombres DFS para asumir un nombre de servidor existente con
consolidación raíz, el nombre del espacio de nombres debe ser el nombre del servidor
que quiere asumir, con el carácter # antepuesto. Por ejemplo, si quiere asumir un
servidor existente llamado MyServer , debe crear un espacio de nombres DFS-N
denominado #MyServer . La sección de PowerShell siguiente se encarga de anteponer # ,
pero si realiza las tareas de creación mediante la consola de Administración de DFS,
deberá anteponer según corresponda.
Portal
Para crear un espacio de nombres, abra la consola de Administración de DFS. Para

encontrarla, seleccione el botón Inicio y escriba Administración de DFS. La consola
de administración que aparece tiene dos secciones: Espacios de nombres y
Replicación, que hacen referencia a los espacios de nombres DFS y a la replicación
DFS (DFS-R), respectivamente. Azure File Sync proporciona un mecanismo moderno
de replicación y sincronización que se puede usar en lugar de DFS-R si también se
quiere replicar.
Seleccione la sección Espacios de nombres y el botón Nuevo espacio de nombres

(también puede hacer clic con el botón derecho en la sección Espacios de
nombres). El Asistente para crear nuevo espacio de nombres que aparece le guiará
a través del proceso de creación de un espacio de nombres.
La primera sección del asistente requiere que elija el servidor de espacio de

nombres DFS para hospedar el espacio de nombres. Varios servidores pueden
hospedar un espacio de nombres, pero tendrá que configurar Espacios de nombres
DFS con un servidor cada vez. Escriba el nombre del servidor de espacio de
nombres DFS que quiera usar y seleccione Siguiente. En la sección Nombre y
configuración de espacio de nombres, escriba el nombre que quiera usar para el
espacio de nombres y seleccione Siguiente.
La sección Tipo de espacio de nombres permite elegir entre un Espacio de

nombres basado en dominio y un Espacio de nombres independiente. Si piensa
usar Espacios de nombres DFS para conservar un nombre de dispositivo NAS o
servidor de archivos existente, debe seleccionar la opción de espacio de nombres
independiente. Para cualquier otro escenario, debe seleccionar un espacio de
nombres basado en dominio. Consulte los tipos de espacio de nombres anteriores
para obtener más información sobre cómo elegir entre ellos.
Seleccione el tipo de espacio de nombres que quiera usar para el entorno y elija
Siguiente. A continuación, el asistente resumirá el espacio de nombres que se va a
crear. Seleccione Crear para crear el espacio de nombres y Cerrar una vez que se
complete el cuadro de diálogo.
Configuración de carpetas y de destinos de

carpeta
Para que un espacio de nombres sea útil, debe tener carpetas y destinos de carpeta.
Cada carpeta puede tener uno o más destinos de carpeta, que son punteros a los
recursos compartidos de archivos SMB que hospedan ese contenido. Cuando los
usuarios examinan una carpeta con destinos de carpeta, el equipo cliente recibe una
referencia que lo redirige de forma transparente a uno de los destinos de carpeta.
También puede tener carpetas sin destinos de carpeta para agregar la estructura y la
jerarquía al espacio de nombres.
Considere que las carpetas de Espacios de nombres DFS son análogas a los recursos
Portal
En la consola de Administración de DFS, seleccione el espacio de nombres que
acaba de crear y elija Nueva carpeta. Aparece el cuadro de diálogo Nueva carpeta,
que le permite crear tanto la carpeta como sus destinos.
Proporcione el nombre de la carpeta en el cuadro de texto con la etiqueta Nombre.

Seleccione Agregar... a fin de agregar destinos de carpeta para esta carpeta. Se
muestra el cuadro de diálogo Agregar destino de carpeta, que proporciona un
cuadro de texto con la etiqueta Ruta de acceso de destino de carpeta, en el que
puede proporcionar la ruta de acceso UNC a la carpeta que quiera. Seleccione
Aceptar en el cuadro de diálogo Agregar destino de carpeta. Si está agregando
una ruta de acceso UNC a un recurso compartido de archivos de Azure, es posible
que reciba un mensaje que indica que no se puede contactar con el servidor
storageaccount.file.core.windows.net . Este es el comportamiento esperado;
seleccione Sí para continuar. Por último, seleccione Aceptar en el cuadro de diálogo

Nueva carpeta para crear la carpeta y los destinos de carpeta.
Ahora que ha creado un espacio de nombres, una carpeta y un destino de carpeta, debe
poder montar el recurso compartido de archivos en los espacios de nombres DFS. Si usa
un espacio de nombres basado en dominio, la ruta de acceso completa del recurso
compartido debe ser \\<domain-name>\<namespace>\<share> . Si usa un espacio de
nombres independiente, la ruta de acceso completa del recurso compartido debe ser \\
<DFS-server>\<namespace>\<share> . Si usa un espacio de nombres independiente con
consolidación raíz, puede acceder directamente a través del nombre del servidor
anterior, como \\<old-server>\<share> .
Enumeración basada en el acceso (ABE)

El uso de ABE para controlar la visibilidad de los archivos y carpetas en los recursos
compartidos de archivos de SMB de Azure no se admite actualmente. ABE es una
característica de DFS-N, por lo que es posible configurar la autenticación basada en
identidades y habilitar la característica ABE. Sin embargo, esto solo se aplica a los
destinos de carpetas DFS-N; no se aplica retroactivamente a los propios recursos
compartidos de archivos de destino. Esto se debe a que DFS-N funciona por referencia,
en lugar de como un proxy delante del destino de carpetas.
Por ejemplo, si el usuario escribe la ruta de acceso \\mydfsnserver\share , el cliente SMB

obtiene la referencia de \\mydfsnserver\share => \\server123\share y realiza el montaje
en este último.
Por este motivo, ABE solo funcionará en los casos en los que el servidor DFS-N hospede
la lista de nombres de usuario antes del redireccionamiento:
\\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1
\\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1
(Donde contosouser1 es una subcarpeta del recurso compartido users)
Si cada usuario es una subcarpeta después del redireccionamiento, ABE no funcionará:
\\DFSServer\SomePath\users --> \\SA.file.core.windows.net\users
Consulte también
Implementación de un recurso compartido de archivos de Azure: Planeamiento de
una implementación de Azure Files y Creación de un recurso compartido de
archivos de Azure.
Configuración del acceso a recursos compartidos de archivos: documentos sobre
autenticación basada en la identidad y consideraciones de red para el acceso
directo.
Espacios de nombres del Sistema de archivos distribuido de Windows Server
Creación de una FCI con un recurso
compartido de archivos Premium (SQL
Server en VM de Azure)
Artículo • 02/10/2023
Se aplica a: SQL Server en VM de Azure
 Sugerencia
Hay muchos métodos para implementar un grupo de disponibilidad. Simplifique

la implementación y elimine la necesidad de un nombre de red distribuida (DNN) o
un equilibrador de carga de Azure para el grupo de disponibilidad Always On
mediante la creación de las máquinas virtuales (VM) de SQL Server en varias
subredes dentro de la misma red virtual de Azure. Si ya ha creado el grupo de
disponibilidad en una sola subred, puede migrarlo a un entorno de varias
subredes.
En este artículo se explica cómo crear una instancia de clúster de conmutación por error
(FCI) con SQL Server en Azure Virtual Machines (VM) con un recurso compartido de
archivos Premium.
Los recursos compartidos de archivos Premium son recursos compartidos de archivos

de baja latencia constante con respaldo de SSD que son totalmente compatibles para su
uso con la instancia del clúster de conmutación por error en SQL Server 2012 y
versiones posteriores en Windows Server 2012 y versiones posteriores. Los recursos
compartidos de archivos Premium ofrecen mayor flexibilidad, lo que le permite cambiar
el tamaño y escalar el recurso compartido de archivos sin tiempo de inactividad.
Para obtener más información, consulte información general de FCI con SQL Server en
VM de Azure y procedimientos recomendados del clúster.
７ Nota
Ahora es posible migrar mediante lift and shift la solución de instancia de clúster
de conmutación por error a SQL Server en máquinas virtuales de Azure mediante
Azure Migrate. Consulte Migración de una instancia de clúster de conmutación
por error para más información.
Requisitos previos
Antes de completar las instrucciones de este artículo, ya debe tener:
Suscripción a Azure.
Una cuenta que tenga permisos para crear objetos en máquinas virtuales de Azure
y en Active Directory.
Dos o más máquinas virtuales de Azure para una FCI en un conjunto de
disponibilidad o en zonas de disponibilidad diferentes.
Un recurso compartido de archivos premium que se usará como unidad en clúster,
en función de la cuota de almacenamiento de la base de datos de los archivos de
datos.
La versión más reciente de PowerShell.
Montaje del recurso compartido de archivos

Premium
Para montar el recurso compartido de archivos Premium, realice estos pasos:
1. Inicie sesión en Azure Portal y vaya a la cuenta de almacenamiento.
2. Vaya a Recursos compartidos de archivos en Almacenamiento de datos y, luego,

seleccione el recurso compartido de archivos prémium que quiere usar para el
almacenamiento SQL.
3. Seleccione Conectar para mostrar la cadena de conexión del recurso compartido

de archivos.
4. En la lista desplegable, seleccione la letra de unidad que quiere usar, elija Clave de
cuenta de almacenamiento como método de autenticación y, luego, copie el
bloque de código en un editor de texto, como el Bloc de notas.
5. Aplique el protocolo de escritorio remoto (RDP) para conectarse a la VM con
SQL Server con la cuenta que la FCI de SQL Server usará para la cuenta de
servicio.
6. Abra una consola de comandos de PowerShell de administración.
7. Ejecute el comando que copió anteriormente en el editor de texto desde el portal

de recursos compartidos de archivos.
8. Vaya al recurso compartido mediante el Explorador de archivos o el cuadro de

diálogo Ejecutar (Windows + R en el teclado). Use la ruta de acceso a la red
\\storageaccountname.file.core.windows.net\filesharename . Por ejemplo:
\\sqlvmstorageaccount.file.core.windows.net\sqlpremiumfileshare
9. Cree al menos una carpeta en el recurso compartido de archivos recién conectado

para colocar los archivos de datos de SQL.
10. Repita estos pasos en cada VM con SQL Server que participará en el clúster.
） Importante
Considere la posibilidad de usar un recurso compartido de archivos independiente
para los archivos de copia de seguridad a fin de ahorrar la capacidad de
operaciones de entrada/salida por segundo (IOPS) y espacio de este recurso
compartido para usarla para el archivo de registro y de datos. Puede usar un
recurso compartido de archivos Premium o Estándar para los archivos de copia de
seguridad.
Creación de un clúster de conmutación por

error de Windows
Los pasos necesarios para crear un clúster de conmutación por error de Windows Server
varían en función de si se han implementado las máquinas virtuales con SQL Server en
una sola subred o en varias. Para crear el clúster, siga los pasos del tutorial de un
escenario de varias subredes o un escenario de una sola subred. Aunque estos tutoriales
son para crear un grupo de disponibilidad, los pasos para crear el clúster son los
mismos.
Configuración de un cuórum
El testigo en la nube es la solución de cuórum recomendada para este tipo de
configuración de clúster con SQL Server en máquinas virtuales de Azure.
Si tiene un número par de votos en el clúster, configure la solución de cuórum que

mejor se adapte a sus necesidades empresariales. Para más información, consulte
Cuórum con VM SQL Server.
Validar el clúster
Valide el clúster en una de las máquinas virtuales mediante la interfaz de usuario del
administrador de clústeres de conmutación por error o PowerShell.
Para validar el clúster con la interfaz de usuario, realice los pasos siguientes en una de
las máquinas virtuales:
1. En Administrador del servidor, seleccione Herramientas y, después, seleccione

Administrador de clústeres de conmutación por error.
2. En Administrador de clústeres de conmutación por error, seleccione Accióny, a

continuación, seleccione Validar configuración.
3. Seleccione Next (Siguiente).
4. En Seleccionar servidores o un clúster, escriba el nombre de ambas máquinas

virtuales.
5. En Opciones de pruebas, seleccione Ejecutar solo las pruebas que seleccione.
6. Seleccione Next (Siguiente).
7. En Selección de pruebas, seleccione todas las pruebas excepto Almacenamiento y

Espacios de almacenamiento directo como se muestra aquí:
8. Seleccione Siguiente.
9. En Confirmación, seleccione Siguiente. El Asistente para validar una configuración

ejecuta las pruebas de validación.
Para validar el clúster con PowerShell, ejecute el siguiente script en una sesión de
PowerShell de administrador de una de las máquinas virtuales:
PowerShell
Test-Cluster –Node ("<node1>","<node2>") –Include "Inventory", "Network",

"System Configuration"
Conmutación por error del clúster de prueba

Pruebe la conmutación por error del clúster. En Administrador de clústeres de
conmutación por error, haga clic con el botón derecho en el clúster y seleccione Más
acciones>Mover principales recursos de clúster>Seleccionar nodo y, después,
seleccione el otro nodo del clúster. Mueva el recurso de clúster principal a cada nodo
del clúster y, después, devuélvalo al nodo principal. Si puede mover correctamente el
clúster a cada nodo, está listo para instalar SQL Server.
Crear la FCI de SQL Server

Después de haber configurado el clúster de conmutación por error, puede crear la FCI
de SQL Server.
1. Conéctese a la primera máquina virtual con RDP.
2. En Administrador de clústeres de conmutación por error, asegúrese de que todos

los recursos principales de clúster estén en la primera máquina virtual. Si es
necesario, mueva todos los recursos a esta máquina virtual.
3. Si la versión del sistema operativo es Windows Server 2019 y el clúster de

Windows se creó con el nombre de red distribuida (DNN) predeterminado, se
produce un error en la instalación de instancia de clúster de conmutación por error
para SQL Server 2017 y versiones anteriores con el error The given key was not
present in the dictionary .
Durante la instalación, el programa de instalación de SQL Server consulta el

nombre de red virtual (VNN) existente y no reconoce el DNN del clúster de
Windows. El problema se ha corregido en el programa de configuración de SQL
Server 2019. En SQL Server 2017 y versiones anteriores, siga estos pasos para
evitar el error de instalación:
En el Administrador de clústeres de conmutación por error, conéctese al

clúster, haga clic con el botón derecho en Roles y seleccione Crear rol vacío.
Haga clic con el botón derecho en el rol vacío recién creado, seleccione
Agregar recurso y seleccione Punto de acceso cliente.
Escriba cualquier nombre y complete el asistente para crear el punto de
acceso cliente.
Una vez completada la instalación de instancia de clúster de conmutación por
error de SQL Server, se puede eliminar el rol que contiene el punto de acceso
cliente temporal.
4. Localice los medios de instalación. Si la máquina virtual usa una de las imágenes
de Azure Marketplace, los medios se encuentran en C:\SQLServer_<version
number>_Full .
5. Seleccione Setup (Configuración).
6. En el Centro de instalación de SQL Server, seleccione Instalación.
7. Seleccione Nueva instalación de clúster de conmutación por error de SQL Server

y, a continuación, siga las instrucciones del asistente para instalar la FCI de SQL
Server.
8. En la página Configuración de red de clúster, la IP que proporcione varía en

función de si las máquinas virtuales con SQL Server se implementaron en una sola
subred o en varias.
a. En el caso de un entorno de una sola subred, especifique la dirección IP que
planea agregar a Azure Load Balancer
b. En el caso de un entorno de varias subredes, especifique la dirección IP
secundaria en la subred de la primera máquina virtual con SQL Server que
designó anteriormente como la dirección IP del nombre de red de la instancia
de clúster de conmutación por error:
9. En Configuración del motor de base de datos, los directorios de datos deben
estar en el recurso compartido de archivos Premium. Escriba la ruta de acceso
completa del recurso compartido,con este formato:
\\storageaccountname.file.core.windows.net\filesharename\foldername . Aparece
una advertencia que le notifica que ha especificado un servidor de archivos como

directorio de datos. Se espera esta advertencia. Para evitar posibles errores,
asegúrese de que la cuenta de usuario que usó para tener acceso a la máquina
virtual mediante RDP cuando conservó el recurso compartido de archivos sea la
misma que usa el servicio SQL Server.
10. Después de completar los pasos del asistente, el programa de instalación instalará
una FCI de SQL Server en el primer nodo.
11. Tras completar correctamente la instalación de instancia de clúster de conmutación

por error en el primer nodo, conéctese al segundo nodo mediante RDP.
12. Abra el Centro de instalación de SQL Server y, a continuación, seleccione

Instalación.
13. Seleccione Agregar nodo a clúster de conmutación por error de SQL Server. Siga
las instrucciones del asistente para instalar SQL Server y agregar el nodo a la
instancia de clúster de conmutación por error.
14. En el caso de un escenario de varias subredes, en Configuración de red en clúster,

especifique la dirección IP secundaria en la subred de la segunda máquina virtual
con SQL Server que designó anteriormente como la dirección IP del nombre de
red de la instancia de clúster de conmutación por error
Después de seleccionar Siguiente en Configuración de red de clúster, el programa
de instalación muestra un cuadro de diálogo que indica que el programa de
instalación de SQL Server ha detectado varias subredes como en la imagen de
ejemplo. Seleccione Sí para confirmar la acción.
15. Después de completar las instrucciones del asistente, el programa de instalación

agrega el segundo nodo FCI de SQL Server.
16. Repita estos pasos en cualquier otro nodo que desee agregar a la instancia de
clúster de conmutación por error de SQL Server.
７ Nota
Las imágenes de la galería de Azure Marketplace vienen con SQL Server

Management Studio instalado. Si no ha usado una imagen de Marketplace,
descargue SQL Server Management Studio (SSMS).
Registro con una extensión Agente de IaaS de

SQL
Para administrar la VM con SQL Server desde el portal, regístrela con la extensión de
agente de IaaS de SQL. Solo la funcionalidad limitada está disponible en máquinas
virtuales SQL que tienen instancias de clúster de conmutación por error de SQL Server
(FCI).
Si la VM con SQL Server ya se registró con la extensión Agente de IaaS de SQL y se

habilitaron características que requieren el agente, deberá anular el registro de la VM
con SQL Server desde la extensión y registrarla de nuevo después de instalar la FCI.
Registre una VM con SQL Server con PowerShell ((-LicenseType puede ser PAYG o AHUB ):
PowerShell
# Get the existing compute VM

$vm = Get-AzVM -Name <vm_name> -ResourceGroupName <resource_group_name>
# Register SQL VM with SQL IaaS Agent extension

New-AzSqlVM -Name $vm.Name -ResourceGroupName $vm.ResourceGroupName -
Location $vm.Location `
-LicenseType <license_type>
Configuración de la conectividad
Si implementó las máquinas virtuales de SQL Server en varias subredes, omita este paso.
Si implementó las máquinas virtuales de SQL Server en una sola subred, debe configurar
un componente adicional para enrutar el tráfico a la instancia de clúster de conmutación
por error. Puede configurar un nombre de red virtual (VNN) con Azure Load Balancer o
un nombre de red distribuida para una instancia de clúster de conmutación por error.
Revise las diferencias entre los dos y, luego, implemente un nombre de red distribuida o
un nombre de red virtual y Azure Load Balancer para la instancia de clúster de
Limitaciones
No se admite el Coordinador de transacciones distribuidas de Microsoft (MSDTC)
en Windows Server 2016 y versiones anteriores.
FILESTREAM no se admite en los clústeres de conmutación por error con un
recurso compartido de archivos Premium. Para usar la secuencia de archivos,
implemente el clúster con Espacios de almacenamiento directo o discos
compartidos de Azure en su lugar.
Las FCI de SQL Server registradas con la extensión no admiten características que
requieran el agente, como la copia de seguridad automatizada, la aplicación de
revisiones y la administración avanzada del portal. Consulte la tabla de ventajas.
Las instantáneas de base de datos no se admiten actualmente en Azure Files
debido a las limitaciones de archivos dispersos.
Puesto que no se admiten instantáneas de base de datos, CHECKDB para bases de
datos de usuario vuelve a CHECKDB WITH TABLOCK. TABLOCK limita las
comprobaciones que se llevan a cabo; DBCC CHECKCATALOG no se ejecuta en la
base de datos y los datos de Service Broker no se validan.
No se admite DBCC CHECKDB en la base de datos master y msdb .
Las bases de datos que usan la característica OLTP en memoria no se admiten en
una instancia de clúster de conmutación por error implementada con un recurso
compartido de archivos prémium. Si su empresa requiere OLTP en memoria,
considere la posibilidad de implementar la instancia de clúster de conmutación por
error con discos compartidos de Azure o Espacios de almacenamiento directo.
Compatibilidad de extensión limitada

En este momento, las instancias de clúster de conmutación por error de SQL Server en
máquinas virtuales de Azure registradas con la extensión Agente de IaaS de SQL solo
admiten un número limitado de características. Consulte la tabla de ventajas.
Si la VM con SQL Server ya se registró con la extensión Agente de IaaS de SQL y se

habilitaron características que requieren el agente, debe anular el registro desde la
extensión; para ello, elimine el recurso de máquina virtual con SQL para las VM
correspondientes y, luego, vuelva a registrarlas con la extensión Agente de IaaS de SQL.
Cuando elimine el recurso Máquina virtual con SQL desde Azure Portal, desactive la
casilla de la máquina virtual correcta para evitar la eliminación de la máquina virtual.
Contenido relacionado
Creación de una FCI con discos compartidos de Azure (SQL Server en VM de
Azure)
Creación de una FCI con Espacios de almacenamiento directo (SQL Server en Azure
VM)
Clúster de conmutación por error de Windows Server con SQL Server en VM de
Azure
Instancias de clúster de conmutación por error con SQL Server en Azure Virtual
Machines
Información general de las instancias de clúster de conmutación por error
Procedimientos recomendados para la configuración de HADR (SQL Server en
Azure Virtual Machines)
Optimización de costos para Azure Files
con las reservas
Artículo • 01/06/2023
Puede ahorrar en los costos de almacenamiento de los recursos compartidos de

archivos de Azure con las reservas de Azure Files. Las reservas de Azure Files (que
también se denominan instancias reservadas) ofrece un descuento por capacidad para
los costos de almacenamiento cuando se establece un compromiso anual o trienal al
realizar la reserva. Las reservas proporcionan una cantidad fija de capacidad de
almacenamiento durante el plazo comprometido.
Las reservas de Azure Files pueden reducir considerablemente los costos de capacidad
por almacenar datos en los recursos compartidos de archivos de Azure. La cantidad que
ahorre dependerá de la duración de la reserva, de la capacidad total que elija reservar y
de la configuración de nivel y redundancia que haya elegido para los recursos
compartidos de archivos de Azure. Las reservas permiten un descuento en la facturación
y no afectan al estado de los recursos compartidos de Azure.
Para obtener información acerca de los precios de las reservas de Azure Files, consulte
Precios de Azure Files .
Se aplica a
Términos de la reserva de Azure Files

En las secciones siguientes se describen los términos de una reserva de Azure Files.
Unidades y términos de las reservas

Las reservas de Azure Files se pueden comprar en unidades de 10 TiB y 100 TiB al mes
durante un período de uno o tres años.
Ámbito de la reserva
Las reservas de Azure Files están disponibles en una sola suscripción, varias
suscripciones (ámbito compartido) y grupos de administración. Cuando el ámbito es
una suscripción única, el descuento de la reserva se aplica únicamente a la suscripción
seleccionada. Cuando el ámbito es varias suscripciones, el descuento de la reserva se
comparte entre esas suscripciones, dentro del contexto de facturación del cliente.
Cuando el ámbito es un grupo de administración, el descuento por reserva se aplica a
las suscripciones que forman parte del grupo de administración y del ámbito de
facturación. Las reservas se aplican al uso dentro del ámbito adquirido y no se pueden
limitar a una cuenta de almacenamiento, un contenedor o un objeto concretos de la
suscripción.
Una reserva de Azure Files solo cubre la cantidad de datos que se almacenan en una
suscripción o un grupo de recursos compartidos. Los cargos por transacción, ancho de
banda, transferencia de datos y almacenamiento de metadatos no se incluyen en la
reserva. En cuanto se compra una reserva, los cargos de capacidad que coincidan con
los atributos de la reserva se cobran según las tarifas de descuento, en lugar de las
tarifas de pago por uso. Para más información, consulte ¿Qué son las reservas de
Azure?.
Reservas e instantáneas
Si va a tomar instantáneas de recursos compartidos de archivos de Azure, hay
diferencias en el funcionamiento de las reservas de recursos compartidos de archivos
estándar con respecto a los Prémium. Si va a tomar instantáneas de recursos
compartidos estándar, las diferenciales de instantáneas se cuentan para la reserva y se
facturan como parte del medidor de almacenamiento usado normal. Sin embargo, si va
a tomar instantáneas de recursos compartidos de archivos Premium, se usa un medidor
independiente para facturar las instantáneas y estas no cuentan para la reserva. Para
más información, consulte Instantánea.
Niveles admitidos y opciones de redundancia

Las reservadas de Azure Files están disponibles para los recursos compartidos de
archivos Prémium, de acceso frecuente y de acceso esporádico. Las reservas no están
disponibles para los recursos compartidos de archivos de Azure en el nivel de
transacción optimizada. Todas las redundancias de almacenamiento admiten reservas.
Para más información sobre las opciones de redundancia, consulte Redundancia de
Azure Files.
Requisitos de seguridad para la compra
Para comprar una reserva:
Debe tener el rol Propietario al menos en una suscripción Enterprise o individual

con tarifas de pago por uso.
En el caso de las suscripciones Enterprise, la opción Agregar instancias reservadas
debe estar habilitada en el portal de EA. O bien, si esa opción está deshabilitada,
debe ser un administrador de EA en la suscripción.
En el caso del programa del Proveedor de soluciones en la nube (CSP), solo los
agentes de administración o de ventas pueden comprar reservas de Azure Files.
Determinación de la capacidad necesaria antes

de la compra
Cuando compra una reserva de Azure Files, debe elegir las opciones de región, nivel y
redundancia de la misma. La reserva solo es válida para los datos almacenados en esa
región, nivel y nivel de redundancia. Por ejemplo, supongamos que adquiere una
reserva de datos en la región Oeste de EE. UU. para el nivel de acceso frecuente
mediante el almacenamiento con redundancia de zona (ZRS). Esa reserva no se aplicará
a los datos en la región Este de EE. UU., a los datos del nivel de acceso esporádico ni a
los datos de almacenamiento con redundancia geográfica (GRS). Sin embargo, puede
adquirir otra reserva que cubra sus necesidades adicionales.
Las reservas están disponibles para bloques de 10 TiB o 100 TiB, con descuentos más
altos para los bloques de 100 TiB. Al adquirir una reserva en Azure Portal, Microsoft
puede realizarle recomendaciones basadas en el uso anterior para ayudarle a
determinar qué reserva debe comprar.
Compra de reservas de Azure Files

Las reservas de Azure Files se pueden realizar desde Azure Portal . Pague la reserva por
adelantado o de forma mensual. Para más información sobre los pagos mensuales,
consulte Compra de reservas de Azure con pagos por adelantado o mensuales.
Para ayudarle a identificar los términos de reserva adecuados para su escenario,

consulte el artículo sobre la aplicación de descuentos en las reservas de Azure Storage.
Para comprar una reserva siga estos pasos:
1. Vaya a la hoja Comprar reservas en Azure Portal.

2. Seleccione Azure Files para comprar una nueva reserva.
3. Rellene los campos obligatorios tal como se describe en la tabla siguiente:
Campo Descripción
Ámbito Indica el número de suscripciones que pueden usar la ventaja de

facturación asociada con la reserva. También controla cómo se aplica la
reserva a suscripciones concretas.
Si selecciona Compartido, el descuento de la reserva se aplica a la

capacidad de Azure Files en cualquier suscripción que se encuentre en el
contexto de facturación. El contexto de facturación se basa en cómo se
haya suscrito a Azure. Para los clientes Enterprise, el ámbito compartido es
la inscripción e incluye todas las suscripciones que esta contiene. Para los
clientes de pago por uso, el ámbito compartido incluye todas las
suscripciones con tarifas de pago por uso creadas por el administrador de
la cuenta.
Si selecciona Suscripción única, el descuento de la reserva se aplica a la

capacidad de Azure Files de la suscripción seleccionada.
Si selecciona Grupo de recursos único, el descuento de la reserva se aplica

a la capacidad de Azure Files de la suscripción seleccionada y al grupo de
recursos seleccionado que hay dentro de esa suscripción.
El ámbito de la reserva se puede cambiar después de haberla adquirido.
Suscripción La suscripción que se usa para pagar la reserva de Azure Files. El método de
pago en la suscripción seleccionada se usa al cargar los costos. La
suscripción debe ser uno de los tipos siguientes:
Contrato Enterprise (números de oferta: MS-AZR-0017P o MS-AZR-0148P):

En el caso de una suscripción Enterprise, los cargos se deducirán del saldo
de pago por adelantado de la inscripción de Azure (anteriormente llamado
compromiso monetario) o se cobrarán como parte del uso por encima del
límite.
Suscripción individual con tarifas de pago por uso (números de la oferta:

MS-AZR-0003P o MS-AZR-0023P): en una suscripción individual con tarifas
de pago por uso, los cargos se cobran en el método de pago de tarjeta de
crédito o factura de la suscripción.
Campo Descripción
Región La región en la que está en vigor la reserva.
Nivel El nivel en el que está en vigor la reserva. Entre las opciones se incluyen
Premium, Frecuente e Inactivo.
Redundancia La opción de redundancia de la reserva. Entre las opciones se incluyen LRS,

ZRS, GRS y GZRS. Para más información sobre las opciones de redundancia,
consulte Redundancia de Azure Files.
Frecuencia Indica la frecuencia con que se factura la cuenta para la reserva. Entre las
de opciones se incluyen Mensual o Por adelantado.
facturación
Tamaño Cantidad de capacidad que se va a reservar.
Término Un año o tres años.
4. Después de seleccionar los parámetros de la reserva, Azure Portal muestra el costo.

El portal también muestra el porcentaje de descuento en la facturación de pago
por uso.
5. En la hoja Compra de reservas, revise el costo total de la reserva. También puede

especificar un nombre para la reserva.
Después de comprar una reserva, esta se aplica automáticamente a todos los recursos
compartido de archivos de Azure que coincidan con los términos de la reserva. Si aún
no ha creado ningún recurso compartido de archivos de Azure, la reserva se aplicará
siempre que se cree un recurso que coincida con sus términos. En cualquier caso, el
período de la reserva comienza inmediatamente después de una compra correcta.
Intercambio o reembolso de una reserva

Las reservas se pueden cambiar o reembolsar, pero con ciertas limitaciones. que se
describen en las secciones siguientes.
Para cambiar o reembolsar una reserva, vaya a los detalles de la reserva en Azure Portal.
Seleccione Intercambiar o Reembolsar y siga las instrucciones para enviar una solicitud
de soporte técnico. Una vez procesada la solicitud, Microsoft le enviará un correo
electrónico para confirmar que se completó la solicitud.
Para más información sobre las directivas de reservas de Azure, consulte Autoservicio de
cambios y reembolsos de reservas de Azure.
Cambio de una reserva
El cambio de una reserva permite recibir un reembolso en el que se prorratea la parte
no utilizada de la reserva. Después, puede aplicar este reembolso al precio de compra
de una nueva reserva de Azure Files.
No hay límite en el número de intercambios que puede hacer. Además, los intercambios
no conllevan ninguna tarifa. El valor de la reserva nueva que compre debe ser igual o
mayor que el crédito prorrateado de la reserva original. Una reserva de Azure Files se
puede intercambiar solo para otra reserva de Azure Files y no para una reserva de
ningún otro servicio de Azure.
Reembolso de una reserva

Las reservas de Azure Files se pueden cancelar en cualquier momento. Si lo hace,
recibirá un reembolso prorrateado según el período restante de la reserva, menos una
cuota de un 12 % por finalización anticipada. El reembolso máximo por año es de
USD 50 000.
Al cancelar una reserva, esta finaliza inmediatamente y se devuelven los meses restantes
a Microsoft. El saldo prorrateado restante, menos la cuota, se reembolsará en la forma
de compra original.
Expiración de una reserva

Cuando una reserva expira, cualquier capacidad de Azure Files que use en ella se factura
según la tarifa de pago por uso. Las reservas no se renuevan automáticamente.
Recibirá una notificación por correo electrónico 30 días antes de la expiración de la

reserva y otra en la fecha de expiración. Para seguir aprovechando el ahorro de costos
que proporciona una reserva, debe renovarla a más tardar en la fecha de expiración.
¿Necesita ayuda? Ponerse en contacto con

nosotros
Si tiene alguna pregunta o necesita ayuda, cree una solicitud de soporte técnico .
Pasos siguientes
¿Qué es Azure Reservations?
Aplicación del descuento por reserva a Azure Storage
Administración del almacenamiento en
las nubes independientes mediante
PowerShell
Artículo • 11/05/2023
La mayoría de los usuarios utiliza la nube pública de Azure para una implementación
global. También hay algunas implementaciones independientes de Microsoft Azure por
motivos de soberanía, etc. Estas implementaciones independientes se conocen como
"entornos". La siguiente lista detalla las nubes independientes disponibles actualmente.
Azure Government Cloud (Nube de Azure Government)

Nube Azure China 21Vianet controlada por 21Vianet en China
Nube de Azure German
７ Nota
Se recomienda usar el módulo Azure Az de PowerShell para interactuar con Azure.

Consulte Instalación de Azure PowerShell para empezar. Para más información
sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure
PowerShell de AzureRM a Az.
Uso de una nube independiente

Para usar Azure Storage en una de las nubes independientes, conéctese a ella, en lugar
de a la nube pública de Azure. Para usar una de las nubes independientes en lugar de la
nube pública de Azure:
Especifique el entorno al que se va a conectar.

Puede determinar y usar las regiones disponibles.
Utilice el sufijo de punto de conexión correcto, que es diferente en el caso de la
nube pública de Azure.
Los ejemplos requieren la versión 0.7 o posterior del módulo Az de Azure PowerShell. En
una ventana de PowerShell, ejecute Get-Module -ListAvailable Az para buscar la
versión. Si no aparece ninguna o necesita una actualización, consulte Instalación del
módulo de Azure PowerShell.
Inicio de sesión en Azure
Ejecute el cmdlet Get-AzEnvironment para ver los entornos de Azure disponibles:
PowerShell
Get-AzEnvironment
Inicie sesión en la cuenta que tenga acceso a la nube a la que desea conectarse y
establezca el entorno. Este ejemplo le muestra cómo iniciar sesión en una cuenta que
utiliza la nube de administración pública de Azure.
PowerShell
Connect-AzAccount –Environment AzureUSGovernment
Para acceder a la nube de China, use el entorno AzureChinaCloud. Para acceder a la

nube de Alemania, use AzureGermanCloud.
En este momento, si necesita la lista de ubicaciones para crear una cuenta de

almacenamiento o algún otro recurso, puede consultar las ubicaciones disponibles de la
nube seleccionada mediante Get-AzLocation.
PowerShell
Get-AzLocation | select Location, DisplayName
La siguiente tabla muestra las ubicaciones devueltas para la nube de Alemania.
Location Display Name (Nombre para mostrar)
germanycentral Centro de Alemania
germanynortheast Nordeste de Alemania
Sufijo de punto de conexión

El sufijo de punto de conexión para cada uno de estos entornos es diferente del punto
de conexión de la nube pública de Azure. Por ejemplo, el sufijo de punto de conexión de
blobs para la nube pública de Azure es blob.core.windows.net. Para la nube de
administración pública, el sufijo de punto de conexión de blobs es
blob.core.usgovcloudapi.net.
Obtención del punto de conexión mediante Get-
AzEnvironment
Puede recuperar el sufijo del punto de conexión mediante Get-AzEnvironment. El punto
de conexión es la propiedad StorageEndpointSuffix del entorno.
En los fragmentos de código siguientes se muestra cómo recuperar el sufijo del punto
de conexión. Todos estos comandos devuelven algo parecido a "core.cloudapp.net" o
"core.cloudapi.de", etc. Adjunte este sufijo al servicio de almacenamiento para acceder a
ese servicio. Por ejemplo, "queue.core.cloudapi.de" accederá al servicio de cola en la
nube de Alemania.
Este fragmento de código recupera todos los entornos y el sufijo de punto de conexión
para cada uno de ellos.
PowerShell
Get-AzEnvironment | select Name, StorageEndpointSuffix
Este comando devuelve los siguientes resultados.
Nombre StorageEndpointSuffix
AzureChinaCloud core.chinacloudapi.cn
AzureCloud core.windows.net
AzureGermanCloud core.cloudapi.de
AzureUSGovernment core.usgovcloudapi.net
Para recuperar todas las propiedades del entorno especificado, llame a Get-
AzEnvironment y especifique el nombre de la nube. Este fragmento de código devuelve
una lista de propiedades. Busque StorageEndpointSuffix en la lista. El ejemplo siguiente
es para la nube de Alemania.
PowerShell
Get-AzEnvironment -Name AzureGermanCloud
Los resultados son similares a los valores siguientes:
Nombre de la propiedad Value
Nombre AzureGermanCloud
Nombre de la propiedad Value
EnableAdfsAuthentication False
ActiveDirectoryServiceEndpointResourceI http://management.core.cloudapi.de/
GalleryURL https://gallery.cloudapi.de/
ManagementPortalUrl https://portal.microsoftazure.de/
ServiceManagementUrl https://manage.core.cloudapi.de/
PublishSettingsFileUrl https://manage.microsoftazure.de/publishsettings/index
ResourceManagerUrl http://management.microsoftazure.de/
SqlDatabaseDnsSuffix .database.cloudapi.de
StorageEndpointSuffix core.cloudapi.de
... ...
Para recuperar solo la propiedad del sufijo de punto de conexión de almacenamiento,

recupere la nube específica y pida solo esa propiedad.
PowerShell
$environment = Get-AzEnvironment -Name AzureGermanCloud

Write-Host "Storage EndPoint Suffix = " $environment.StorageEndpointSuffix
Este comando devuelve la siguiente información:
Storage Endpoint Suffix = core.cloudapi.de
Obtención del punto de conexión desde una cuenta de

almacenamiento
También puede examinar las propiedades de una cuenta de almacenamiento para
recuperar los puntos de conexión:
PowerShell
# Get a reference to the storage account.

$resourceGroup = "myexistingresourcegroup"
$storageAccountName = "myexistingstorageaccount"
$storageAccount = Get-AzStorageAccount `
-ResourceGroupName $resourceGroup `
-Name $storageAccountName
# Output the endpoints.
Write-Host "blob endpoint = " $storageAccount.PrimaryEndPoints.Blob
Write-Host "file endpoint = " $storageAccount.PrimaryEndPoints.File
Write-Host "queue endpoint = " $storageAccount.PrimaryEndPoints.Queue
Write-Host "table endpoint = " $storageAccount.PrimaryEndPoints.Table
En el caso de una cuenta de almacenamiento en la nube de administración pública, este

comando devolverá la siguiente salida:
blob endpoint = http://myexistingstorageaccount.blob.core.usgovcloudapi.net/

file endpoint = http://myexistingstorageaccount.file.core.usgovcloudapi.net/
queue endpoint =
http://myexistingstorageaccount.queue.core.usgovcloudapi.net/
table endpoint =
http://myexistingstorageaccount.table.core.usgovcloudapi.net/
Después de configurar el entorno

Ahora puede usar PowerShell para administrar las cuentas de almacenamiento y acceder
a los datos de blobs, colas, archivos y tablas. Para más información, consulte Az.Storage.
Si ha creado un nuevo grupo de recursos y una cuenta de almacenamiento para este
ejercicio, puede quitar ambos recursos eliminando el grupo de recursos. Al eliminar un
grupo de recursos se eliminan todos los recursos contenidos en él.
PowerShell
Remove-AzResourceGroup -Name $resourceGroup
Pasos siguientes
Conservación de inicios de sesión de usuario entre sesiones de PowerShell
Almacenamiento de Azure Government
Guía para desarrolladores de Microsoft Azure Government
Notas para desarrolladores para las aplicaciones de Azure China 21Vianet
Documentación sobre Azure Alemania
Montaje de un recurso compartido de
archivos de Azure de SMB en Windows
Artículo • 03/09/2023
Azure Files es el sencillo sistema de archivos en la nube de Microsoft. Los recursos

compartidos de archivos de Azure se pueden usar sin problemas en Windows y
Windows Server. En este artículo se describen los aspectos que se deben tener en
cuenta al usar un recurso compartido de archivos de Azure con Windows y Windows
Server.
Para usar un recurso compartido de archivos de Azure por medio del punto de conexión
público fuera de la región de Azure en la que se hospeda, bien sea en el entorno local o
en otra región de Azure, el sistema operativo debe admitir SMB 3.x. Las versiones
anteriores de Windows que solo admiten SMB 2.1 no pueden montar recursos
compartidos de archivos de Azure por medio del punto de conexión público.
Versión de Windows Versión de SMB multicanal de Azure Files Cifrado máximo

SMB del canal SMB
Windows 11, versión SMB 3.1.1 Sí AES-256-GCM

22H2

22H2
Windows Server 2022 SMB 3.1.1 Sí AES-256-GCM

21H2
Windows 10, SMB 3.1.1 Sí AES-128-GCM

versión 21H2
Windows 10, SMB 3.1.1 Sí, con KB5003690 o posterior AES-128-GCM

versión 21H1
Windows Server, versión SMB 3.1.1 Sí, con KB5003690 o posterior AES-128-GCM
20H2
Windows 10, versión SMB 3.1.1 Sí, con KB5003690 o posterior AES-128-GCM
20H2
Windows Server, SMB 3.1.1 Sí, con KB5003690 o posterior AES-128-GCM

versión 2004
Versión de Windows Versión de SMB multicanal de Azure Files Cifrado máximo
SMB del canal SMB
Windows 10, SMB 3.1.1 Sí, con KB5003690 o posterior AES-128-GCM

versión 2004
Windows Server 2019 SMB 3.1.1 Sí, con KB5003703 o posterior AES-128-GCM
Windows 10, versión SMB 3.1.1 Sí, con KB5003703 o posterior AES-128-GCM
1809
Windows Server 2016 SMB 3.1.1 Sí, con KB5004238 o más AES-128-GCM
reciente, y una clave del Registro
aplicada
Windows 10, versión SMB 3.1.1 Sí, con KB5004238 o más AES-128-GCM
1607 reciente, y una clave del Registro
aplicada
Windows 10, SMB 3.1.1 Sí, con KB5004249 o más AES-128-GCM

versión 1507 reciente, y una clave del Registro
aplicada
Windows Server 2012 R2 SMB 3.0 No AES-128-CCM
Windows 8.1 SMB 3.0 No AES-128-CCM
Windows Server 2012 SMB 3.0 No AES-128-CCM
Windows Server 2008 SMB 2.1 No No compatible

R21
Windows 71 SMB 2.1 No No compatible
1
El soporte técnico habitual de Microsoft para Windows 7 y Windows Server 2008 R2 ha
finalizado. Es posible adquirir soporte técnico adicional para las actualizaciones de
seguridad solo a través del programa Actualización de seguridad extendida (ESU) . Se
recomienda encarecidamente migrar de estos sistemas operativos.
７ Nota
Siempre se recomienda disponer de la KB más reciente para su versión de

Windows.
Se aplica a
Requisitos previos
Asegúrese de que el puerto 445 está abierto: el protocolo SMB requiere que esté
abierto el puerto TCP 445. Se producirá un error en las conexiones si se bloquea el
puerto 445. Puede comprobar si el firewall o ISP está bloqueando el puerto 445 con el
cmdlet Test-NetConnection . Consulte Puerto 445 bloqueado.
Uso de un recurso compartido de archivos de

Azure con Windows
Para usar un recurso compartido de archivos de Azure con Windows, debe montarlo, lo
que significa asignarle una letra de unidad o una ruta de acceso a un punto de montaje,
o acceder a él mediante su ruta de acceso UNC.
En este artículo se usa la clave de la cuenta de almacenamiento para tener acceso al

recurso compartido de archivos. Una clave de cuenta de almacenamiento es una clave
de administrador para una cuenta de almacenamiento, lo que incluye los permisos de
administrador de todos los archivos y carpetas dentro de un recurso compartido de
archivos al que accede, y de todos los recursos compartidos de archivos y otros recursos
de almacenamiento (blobs, colas, tablas, etc.) contenidos en la cuenta de
almacenamiento. Si esto no es suficiente para la carga de trabajo, se puede usar Azure
File Sync, o la autenticación basada en identidad a través de SMB.
Un patrón común para elevar y desplazar aplicaciones de línea de negocio (LOB) que
esperan un recurso compartido de archivos de SMB es usar un recurso compartido de
archivos de Azure como alternativa a ejecutar un servidor de archivos de Windows
dedicado en una máquina virtual de Azure. Un aspecto importante que se debe tener en
cuenta para migrar correctamente una aplicación de línea de negocio para usar un
recurso compartido de archivos de Azure es que muchas aplicaciones se ejecutan en el
contexto de una cuenta de servicio dedicada con permisos de sistema limitados y no en
la cuenta administrativa de la máquina virtual. Por lo tanto, debe asegurarse de montar
o guardar las credenciales del recurso compartido de archivos de Azure desde el
contexto de la cuenta de servicio y no de la cuenta administrativa.
Montaje del recurso compartido de archivos de Azure
Azure Portal proporciona un script que puede usar para montar el recurso compartido
de archivos directamente en un host. Se recomienda usar este script proporcionado.
Para obtener este script:
2. Vaya a la cuenta de almacenamiento que contiene el recurso compartido de

archivos que le gustaría montar.
3. Seleccione Recursos compartidos de archivos.
4. Seleccione el recurso compartido de archivos que desea montar.
5. Seleccione Conectar.
6. Seleccione la letra de unidad en la que montar el recurso compartido.
7. Copie el script proporcionado.

8. Pegue el script en un shell del host en el que desea montar el recurso compartido
de archivos y ejecútelo.
Ya ha montado el recurso compartido de archivos de Azure.

Montaje del recurso compartido de archivos de Azure
con el Explorador de archivos
７ Nota
Tenga en cuenta que las instrucciones siguientes se muestran en Windows 10 y

pueden variar ligeramente en las versiones anteriores.
1. Abra el Explorador de archivos desde el menú Inicio, o bien presione las teclas
Win+E.
2. Vaya a Este PC en el lado izquierdo de la ventana. Esta operación cambiará los

menús disponibles en la barra de herramientas. En el menú Equipo, seleccione
Conectar a unidad de red.
3. Seleccione la letra de unidad y escriba la ruta de acceso UNC al recurso

compartido de archivos de Azure. El formato de ruta de acceso UNC es \\
<storageAccountName>.file.core.windows.net\<fileShareName> . Por ejemplo:
\\anexampleaccountname.file.core.windows.net\file-share-name . Active la casilla
Conectar con credenciales diferentes. Seleccione Finalizar.

4. Seleccione Más opciones>Usar otra cuenta. En Dirección de correo electrónico,
use el nombre de la cuenta de almacenamiento y una clave de cuenta de
almacenamiento como contraseña. Seleccione Aceptar.
5. Use el recurso compartido de archivos de Azure como prefiera.
6. Cuando esté listo para desmontar el recurso compartido de archivos de Azure,

haga clic con el botón derecho en la entrada del recurso compartido en
Ubicaciones de red en el Explorador de archivos y seleccione Desconectar.
Acceso a un recurso compartido de archivos de Azure a

través de su ruta de acceso UNC
No es necesario montar el recurso compartido de archivos de Azure en una letra de
unidad determinada para usarlo. Puede acceder directamente al recurso compartido de
archivos de Azure usando la ruta de acceso UNC, escriba lo siguiente en Explorador de
archivos. Asegúrese de reemplazar storageaccountname por el nombre de la cuenta de
almacenamiento y myfileshare por el nombre del recurso compartido de archivos:
\\storageaccountname.file.core.windows.net\myfileshare
Se le pedirá que inicie sesión con sus credenciales de red. Inicie sesión con la
suscripción de Azure en la que ha creado la cuenta de almacenamiento y el recurso
compartido de archivos. Si no se le solicitan credenciales, puede agregar las
credenciales mediante el siguiente comando:
cmdkey /add:StorageAccountName.file.core.windows.net
/user:localhost\StorageAccountName /pass:StorageAccountKey
Para Azure Government Cloud, simplemente cambie el nombre del servidor a:
\\storageaccountname.file.core.usgovcloudapi.net\myfileshare
Acceso a instantáneas de recursos compartido de

Windows
Si ha tomado una instantánea de un recurso compartido, ya sea de forma manual o
automática mediante un script o un servicio como Azure Backup, puede ver las
versiones anteriores de un recurso compartido, un directorio o un archivo concreto
desde un recurso compartido de archivos en Windows. Las instantáneas de recursos
compartidos se pueden tomar desde Azure Portal, Azure PowerShell y la CLI de Azure.
Enumeración de versiones anteriores
Vaya al elemento o elemento principal que hay que restaurar. Haga doble clic para ir al
directorio deseado. Haga clic con el botón derecho y seleccione Propiedades en el
menú.
Seleccione Versiones anteriores para ver la lista de instantáneas de recursos
compartidos de este directorio. La lista puede tardar unos segundos en cargarse
dependiendo de la velocidad de red y del número de instantáneas de recursos
compartidos que haya en el directorio.
Puede seleccionar Abrir para abrir una instantánea concreta.
Restaurar desde una versión anterior
Haga clic en Restaurar para copiar el contenido de todo un directorio de forma

recursiva en el momento de la creación de la instantánea del recurso compartido en la
ubicación original.
Para la compatibilidad con SMB multicanal en Azure Files es necesario asegurar que
Windows tenga aplicadas todas las revisiones pertinentes para estar actualizado. En
varias versiones anteriores de Windows, como Windows Server 2016, Windows 10
versión 1607 y Windows 10 versión 1507, es necesario establecer claves del Registro
adicionales para que todas las correcciones multicanal de SMB pertinentes se apliquen
en instalaciones totalmente revisadas. Si ejecuta una versión de Windows que es más
reciente que estas tres versiones, no se necesita ninguna acción adicional.
Windows Server 2016 y Windows 10, versión 1607

Para habilitar todas las correcciones multicanal de SMB para Windows Server 2016 y
Windows 10 versión 1607, ejecute el siguiente comando de PowerShell:
PowerShell
Set-ItemProperty `
-Path
"HKLM:SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Override
s" `
-Name "2291605642" `
-Value 1 `
-Force
Windows 10, versión 1507

Para habilitar todas las correcciones multicanal de SMB para Windows 10 versión 1507,
ejecute el siguiente comando de PowerShell:
PowerShell
Set-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Services\MRxSmb\KBSwitch" `
-Name "{FFC376AE-A5D2-47DC-A36F-FE9A46D53D75}" `
-Value 1 `
-Force
Pasos siguientes
Consulte los vínculos siguientes para más información sobre Azure Files:

P+F
archivos de Azure de SMB en Linux
Artículo • 25/03/2023

compartidos de archivos de Azure se pueden montar en distribuciones de Linux
mediante el cliente kernel de SMB .
Para montar un recurso compartido de archivos de Azure en Linux se recomienda usar

SMB 3.1.1. De forma predeterminada, Azure Files requiere cifrado en tránsito, que solo
se admite SMB 3.0, y en las versiones posteriores. Azure Files también admite SMB 2.1,
que no admite el cifrado en tránsito, pero no puede montar recursos compartidos de
archivos de Azure con SMB 2.1 desde otra región de Azure o de forma local por motivos
de seguridad. Salvo que la aplicación requiera específicamente SMB 2.1, use SMB 3.1.1.
Distribución SMB 3.1.1 (recomendado) SMB 3.0
Versión del kernel de Compatibilidad básica Compatibilidad básica

Linux con 3.1.1: 4.17 con 3.0: 3.12
Montaje predeterminado: 5.0 Cifrado AES-128-
Cifrado AES-128-GCM: 5.3 CCM: 4.11
Cifrado AES-256-GCM: 5.10
Ubuntu Cifrado AES-128-GCM: 18.04.5 LTS+ Cifrado AES-128-CCM: 16.04.4

LTS+
Red Hat Enterprise Linux Básico: 8.0 (o posterior) 7.5 (o posterior)

(RHEL) Montaje predeterminado: 8.2
(o posterior)
Cifrado AES-128-GCM: 8.2 (o
posterior)
Debian Básico: 10 (o posterior) Cifrado AES-128-CCM: 10 (o

posterior)
SUSE Linux Enterprise Cifrado AES-128-GCM: 15 SP2 (o Cifrado AES-128-GCM: 12 SP2

Server posterior) (o posterior)
Si la distribución de Linux no aparece en la tabla anterior, puede comprobar la versión

del kernel de Linux con el comando uname :
Bash
uname -r
７ Nota
Se agregó compatibilidad con SMB 2.1 a la versión 3.7 del kernel de Linux. Si usa
una versión del kernel de Linux posterior a la 3.7, debe ser compatible con SMB 2.1.
Se aplica a
Prerrequisitos
Asegúrese de que el paquete cifs-utils está instalado.
El paquete cifs-utils se puede instalar con el administrador de paquetes en la
distribución de Linux de su elección.
Ubuntu
En Ubuntu y Debian, use el administrador de paquetes apt :
Bash
sudo apt update

sudo apt install cifs-utils
En otras distribuciones, use el administrador de paquetes apropiado o compile desde el

origen .
La versión más reciente de la interfaz de la línea de comandos (CLI). Para más

información sobre cómo instalar la CLI de Azure, consulte Instalación de la CLI de
Azure y seleccione el sistema operativo. Si prefiere usar el módulo de Azure
PowerShell en PowerShell 6+, puede hacerlo. Sin embargo, las instrucciones de
este artículo son para la CLI de Azure.
Asegúrese de que el puerto 445 está abierto: SMB se comunica a través del
puerto TCP 445, así que asegúrese de que el firewall o ISP no bloquea el puerto
TCP 445 en el equipo cliente. Reemplace <your-resource-group> y <your-storage-
account> y luego ejecute el siguiente script:
Bash
RESOURCE_GROUP_NAME="<your-resource-group>"
STORAGE_ACCOUNT_NAME="<your-storage-account>"
# This command assumes you have logged in with az login

HTTP_ENDPOINT=$(az storage account show \
--resource-group $RESOURCE_GROUP_NAME \
--name $STORAGE_ACCOUNT_NAME \
--query "primaryEndpoints.file" --output tsv | tr -d '"')
SMBPATH=$(echo $HTTP_ENDPOINT | cut -c7-${#HTTP_ENDPOINT})
FILE_HOST=$(echo $SMBPATH | tr -d "/")
nc -zvw3 $FILE_HOST 445
Si la conexión se realizó correctamente, verá algo parecido a la siguiente salida:
Resultados
Connection to <your-storage-account> 445 port [tcp/microsoft-ds]

succeeded!
Si no puede abrir el puerto 445 en su red corporativa o si un ISP le impide hacerlo,

puede utilizar una conexión VPN o ExpressRoute como solución alternativa al
puerto 445. Para más información, consulte Consideraciones de redes para el
acceso directo a los recursos compartidos de archivos de Azure.
Montaje del recurso compartido de archivos de

Azure a petición con mount
Al montar un recurso compartido de archivos en un sistema operativo Linux, el recurso
compartido de archivos remoto se representa como una carpeta en el sistema de
archivos local. Los recursos compartidos de archivos se pueden montar en cualquier
lugar del sistema. En el ejemplo siguiente el montaje se realiza en la ruta de acceso
/mount . Para cambiarla por otra que desee, modifique la variable $MNT_ROOT .
Reemplace <resource-group-name> , <storage-account-name> y <file-share-name> por la
información correcta para su entorno:
Bash
RESOURCE_GROUP_NAME="<resource-group-name>"
STORAGE_ACCOUNT_NAME="<storage-account-name>"
FILE_SHARE_NAME="<file-share-name>"
MNT_ROOT="/mount"
MNT_PATH="$MNT_ROOT/$STORAGE_ACCOUNT_NAME/$FILE_SHARE_NAME"
sudo mkdir -p $MNT_PATH
A continuación, monte el recurso compartido de archivos mediante el comando mount .

En el siguiente ejemplo, el comando $SMB_PATH se rellena con el nombre de dominio
completo para el punto de conexión del archivo de la cuenta de almacenamiento y
$STORAGE_ACCOUNT_KEY se rellena con la clave de la cuenta de almacenamiento.
SMB 3.1.1
７ Nota
A partir de la versión 5.0 del kernel de Linux, SMB 3.1.1 es el protocolo

negociado predeterminado. Si usa una versión del kernel de Linux anterior a
la 5.0, especifique vers=3.1.1 en la lista de opciones de montaje.
Azure CLI
# This command assumes you have logged in with az login

SMB_PATH=$(echo $HTTP_ENDPOINT | cut -
c7-${#HTTP_ENDPOINT})$FILE_SHARE_NAME
STORAGE_ACCOUNT_KEY=$(az storage account keys list \

--account-name $STORAGE_ACCOUNT_NAME \
--query "[0].value" --output tsv | tr -d '"')
sudo mount -t cifs $SMB_PATH $MNT_PATH -o

username=$STORAGE_ACCOUNT_NAME,password=$STORAGE_ACCOUNT_KEY,serverino,n
osharesock,actimeo=30,mfsymlinks
Puede usar uid / gid o dir_mode y file_mode en las opciones de montaje del comando
mount para establecer permisos. Para obtener más información sobre cómo establecer
permisos, consulte Notación numérica de UNIX .
Si lo desea, también puede montar el mismo recurso compartido de archivos de Azure

en varios puntos de montaje. Cuando haya terminado de usar el recurso compartido de
archivos de Azure, use sudo umount $mntPath para desmontarlo.
Montaje automático de recursos compartidos

de archivos
Al montar un recurso compartido de archivos en un sistema operativo Linux, el recurso
compartido de archivos remoto se representa como una carpeta en el sistema de
archivos local. Los recursos compartidos de archivos se pueden montar en cualquier
lugar del sistema. En el ejemplo siguiente el montaje se realiza en la ruta de acceso
/mount . Para cambiarla por otra que desee, modifique la variable $MNT_ROOT .
Bash
MNT_ROOT="/mount"
sudo mkdir -p $MNT_ROOT
Para montar un recurso compartido de archivos de Azure en Linux, use el nombre de la

cuenta de almacenamiento como nombre de usuario del recurso compartido de
archivos y la clave de la cuenta de almacenamiento como contraseña. Dado que las
credenciales de la cuenta de almacenamiento pueden cambiar con el tiempo, deben
almacenarse por separado de la configuración de montaje.
En el ejemplo siguiente se muestra cómo crear un archivo para almacenar las

credenciales. No olvide reemplazar <resource-group-name> y <storage-account-name>
por la información correcta para su entorno.
Bash
RESOURCE_GROUP_NAME="<resource-group-name>"
STORAGE_ACCOUNT_NAME="<storage-account-name>"
# Create a folder to store the credentials for this storage account and
# any other that you might set up.
CREDENTIAL_ROOT="/etc/smbcredentials"
sudo mkdir -p "/etc/smbcredentials"
# Get the storage account key for the indicated storage account.
# You must be logged in with az login and your user identity must have
# permissions to list the storage account keys for this command to work.
STORAGE_ACCOUNT_KEY=$(az storage account keys list \
--account-name $STORAGE_ACCOUNT_NAME \
--query "[0].value" --output tsv | tr -d '"')
# Create the credential file for this individual storage account

SMB_CREDENTIAL_FILE="$CREDENTIAL_ROOT/$STORAGE_ACCOUNT_NAME.cred"
if [ ! -f $SMB_CREDENTIAL_FILE ]; then
echo "username=$STORAGE_ACCOUNT_NAME" | sudo tee $SMB_CREDENTIAL_FILE >
/dev/null
echo "password=$STORAGE_ACCOUNT_KEY" | sudo tee -a $SMB_CREDENTIAL_FILE
> /dev/null
else
echo "The credential file $SMB_CREDENTIAL_FILE already exists, and was
not modified."
fi
# Change permissions on the credential file so only root can read or modify
the password file.
sudo chmod 600 $SMB_CREDENTIAL_FILE
Para montar automáticamente un recurso compartido de archivos, puede elegir entre

usar un montaje estático a través de la utilidad /etc/fstab o un montaje dinámico a
través de la utilidad autofs .
Montaje estático con /etc/fstab

Utilice el entorno anterior para crear una carpeta para su cuenta de almacenamiento o
recurso compartido de archivos en la carpeta de montaje. Reemplace <file-share-name>
por el nombre adecuado del recurso compartido de archivos de Azure.
Bash
MNT_PATH="$MNT_ROOT/$STORAGE_ACCOUNT_NAME/$FILE_SHARE_NAME"
sudo mkdir -p $MNT_PATH
Por último, cree un registro en el archivo /etc/fstab para el recurso compartido de

archivos de Azure. En el comando siguiente, se usa el valor predeterminado de los
permisos de archivo y carpeta de Linux, 0755, lo que significa lectura, escritura y
ejecución para el propietario (según el propietario de Linux de archivo o directorio),
lectura y ejecución para los usuarios en el grupo de propietarios y lectura y ejecución
para otros en el sistema. Es posible que desee establecer los permisos uid y gid , o
dir_mode y file_mode alternativos en el montaje según sea necesario. Para obtener más
información sobre cómo establecer permisos, consulte notación numérica de UNIX en
Wikipedia.
 Sugerencia
Si quiere que los contenedores Docker que ejecutan aplicaciones de .NET Core
puedan escribir en el recurso compartido de archivos de Azure, incluya nobrl en las
opciones de montaje de SMB para evitar el envío de solicitudes de bloqueo de
intervalo de bytes al servidor.
Bash

SMB_PATH=$(echo $HTTP_ENDPOINT | cut -c7-${#HTTP_ENDPOINT})$FILE_SHARE_NAME
if [ -z "$(grep $SMB_PATH\ $MNT_PATH /etc/fstab)" ]; then

echo "$SMB_PATH $MNT_PATH cifs
nofail,credentials=$SMB_CREDENTIAL_FILE,serverino,nosharesock,actimeo=30" |
sudo tee -a /etc/fstab > /dev/null
else
echo "/etc/fstab was not modified to avoid conflicting entries as this
Azure file share was already present. You may want to double check
/etc/fstab to ensure the configuration is as desired."
fi
sudo mount -a
７ Nota
A partir de la versión 5.0 del kernel de Linux, SMB 3.1.1 es el protocolo negociado
predeterminado. Puede especificar versiones alternativas del protocolo mediante la
opción de montaje vers (las versiones de protocolo son 3.1.1 , 3.0 y 2.1 ).
Montaje dinámico con autofs

Para montar dinámicamente un recurso compartido de archivos con la utilidad autofs ,
instálelo mediante el administrador de paquetes en la distribución de Linux que prefiera.
Ubuntu
En las distribuciones de Ubuntu y Debian, use el administrador de paquetes apt :
Bash
sudo apt update

sudo apt install autofs
A continuación, actualice los archivos de configuración autofs .
Bash

SMB_PATH=$(echo $HTTP_ENDPOINT | cut -c7-$(expr length
$HTTP_ENDPOINT))$FILE_SHARE_NAME
echo "$FILE_SHARE_NAME -fstype=cifs,credentials=$SMB_CREDENTIAL_FILE

:$SMB_PATH" > /etc/auto.fileshares
echo "/fileshares /etc/auto.fileshares --timeout=60" > /etc/auto.master
El último paso es reiniciar el servicio autofs .
Bash
sudo systemctl restart autofs
Montaje de una instantánea de recurso

Si quiere montar una instantánea específica de un recurso compartido de archivos SMB
de Azure, debe proporcionar la opción snapshot como parte del comando mount ,
donde snapshot es el momento en que se creó la instantánea concreta en un formato
como @GMT-2023.01.05-00.08.20. La opción snapshot se admite en el kernel de Linux
desde la versión 4.19.
Después de crear la instantánea del recurso compartido de archivos, siga estas

instrucciones para montarla.
1. En Azure Portal, vaya a la cuenta de almacenamiento que contiene el recurso
compartido de archivos del que quiere montar una instantánea.
2. Seleccione Almacenamiento de datos > Recursos compartidos de archivos y

seleccione el recurso compartido de archivos.
3. Seleccione Operaciones > Instantáneas y anote el nombre de la instantánea que

quiere montar. El nombre de la instantánea será una marca de tiempo GMT, como
se muestra en la captura de pantalla siguiente.
4. Convierta la marca de tiempo al formato que espera el comando mount , es decir,

@GMT-año.mes.día-hora.minutos.segundos. En este ejemplo, convertiría 2023-
01-05T00:08:20.0000000Z en @GMT-2023.01.05-00.08.20.
5. Ejecute el comando mount con la hora GMT para especificar el valor snapshot .
Asegúrese de reemplazar <storage-account-name> , <file-share-name> y la marca
de tiempo GMT por sus valores. El archivo .cred contiene las credenciales que se
usarán para montar el recurso compartido (consulte Montaje automático de
recursos compartidos de archivos).
Bash
sudo mount -t cifs //<storage-account-

name>.file.core.windows.net/<file-share-name> /mnt/<file-share-
name>/snapshot1 -o
credentials=/etc/smbcredentials/snapshottestlinux.cred,snapshot=@GMT-
2023.01.05-00.08.20
6. Si puede examinar la instantánea en la ruta de acceso /mnt/<file-share-

name>/snapshot1 , el montaje se realizó correctamente.
Si se produce un error en el montaje, vea Solución de problemas de conectividad y
acceso de Azure Files (SMB).
Pasos siguientes

Eliminación de SMB 1 en Linux
Solución de problemas generales de SMB en Linux
Solución de problemas generales de NFS en Linux
archivos de Azure de NFS en Linux
Artículo • 04/12/2023
Los recursos compartidos de archivos de Azure se pueden montar en distribuciones de

Linux mediante el protocolo Bloque de mensajes del servidor (SMB) o el protocolo
Network File System (NFS). Este artículo se centra en el montaje con NFS. Para más
información sobre el montaje de recursos compartidos de archivos SMB de Azure,
consulte Uso de Azure Files con Linux. Para obtener más información sobre los
protocolos disponibles, consulte Protocolos de recurso compartido de archivos de
Azure.
Se aplica a
ﾉ Expandir tabla
Soporte técnico
Actualmente, solo se admite la versión 4.1 de NFS. Los recursos compartidos de NFS 4.1
solo se admiten en el tipo de cuenta de almacenamiento de FileStorage (solo recursos
compartidos de archivos premium).
Los recursos compartidos de archivos de Azure de NFS admiten la mayoría de las

características de la especificación del protocolo 4.1. No se admiten algunas
características, como delegaciones y devoluciones de llamada de todo tipo, la
autenticación Kerberos y el cifrado en tránsito.
Los recursos compartidos de archivos NFS de Azure se admiten en las mismas regiones
que admiten el almacenamiento de archivos Prémium.
Para obtener la lista más actualizada, consulte la entrada Premium Files Storage en la
página Productos de Azure disponibles por región .
Requisitos previos
Creación de un recurso compartido de NFS
Abra el puerto 2049 en cualquier cliente en el que quiera montar el recurso

compartido NFS.
） Importante
Solo se puede tener acceso a los recursos compartidos de NFS desde redes
de confianza.
Cree un punto de conexión privado (recomendado) o restrinja el acceso al punto

de conexión público.
Para habilitar el acceso híbrido a un recurso compartido de archivos de Azure NFS,

use una de las siguientes soluciones de red:
Configure una VPN de punto a sitio (P2S) en Linux para su uso con Azure Files.
Configure una VPN de sitio a sitio para su uso con Azure Files.
Configure ExpressRoute.

1. Inicie sesión en Azure Portal y acceda a la cuenta de almacenamiento que
contiene el recurso compartido de NFS que creó.
2. Seleccione Configuración.
3. Seleccione Deshabilitado para Se requiere transferencia segura.

Opciones de montaje
Se recomiendan o requieren las siguientes opciones de montaje al montar recursos
compartidos de archivos de Azure NFS.
ﾉ Expandir tabla
Opción de Valor Descripción

montaje recomendado
vers 4 Necesario. Especifica la versión del protocolo NFS que se va a

usar. Azure Files solo admite NFS v4.1.
minorversion 1 Necesario. Especifica la versión secundaria del protocolo NFS.

Algunas distribuciones de Linux no reconocen versiones
secundarias en el parámetro vers . Por lo tanto, en lugar de
vers=4.1 , use vers=4,minorversion=1 .
sec sys Necesario. Especifica el tipo de seguridad que se va a usar al

autenticar una conexión NFS. Al establecer sec=sys , se usan los
UID y los GID de UNIX locales que usan AUTH_SYS para
autenticar operaciones NFS.
rsize 1048576 Opción recomendada. Establece el número máximo de bytes

que se van a transferir en una sola operación de lectura NFS.
Especificar el nivel máximo de 1 048 576 bytes normalmente
dará como resultado el mejor rendimiento.
wsize 1048576 Opción recomendada. Establece el número máximo de bytes

que se van a transferir en una sola operación de escritura NFS.
Opción de Valor Descripción
montaje recomendado
Especificar el nivel máximo de 1 048 576 bytes normalmente

dará como resultado el mejor rendimiento.
noresvport N/D Opción recomendada. Indica al cliente NFS que use un puerto
de origen sin privilegios al comunicarse con un servidor NFS
para el punto de montaje. El uso de la opción de montaje
noresvport ayuda a garantizar que el recurso compartido NFS
tenga disponibilidad ininterrumpida después de una
reconexión. Se recomienda usar esta opción para lograr la alta
disponibilidad.
actimeo 30-60 Opción recomendada. Al especificar actimeo , se establecen

acregmin , acregmax , acdirmin y acdirmax en el mismo valor. El
uso de un valor inferior a 30 segundos puede provocar una
degradación del rendimiento porque las memorias caché de
atributos de los archivos y directorios expiran demasiado
rápidamente. Se recomienda establecer actimeo entre 30 y
60 segundos.
Montaje de un recurso compartido NFS

mediante Azure Portal
７ Nota
Puede usar la opción de montaje de Linux nconnect para mejorar el rendimiento de

los recursos compartidos de archivos de Azure NFS a escala. Para más información,
consulte Mejora del rendimiento del recurso compartido de archivos NFS de
Azure.
1. Una vez creado el recurso compartido de archivos, selecciónelo y elija Conectarse

desde Linux.
2. Escriba la ruta de acceso de montaje que quiere usar y, después, copie el script.
3. Conéctese al cliente y use el script de montaje proporcionado. Solo se incluyen las

opciones de montaje necesarias en el script, pero puede agregar otras opciones de
montaje recomendadas.
Ya ha montado el recurso compartido de NFS.
Montaje de un recurso compartido NFS

mediante /etc/fstab
Si desea que el recurso compartido de archivos NFS se monte automáticamente cada
vez que arranque el servidor Linux o la máquina virtual, cree un registro en el archivo
/etc/fstab para el recurso compartido de archivos de Azure. Reemplace
YourStorageAccountName y FileShareName por su propia información.
Bash
<YourStorageAccountName>.file.core.windows.net:/<YourStorageAccountName>/<Fi
leShareName> /media/<YourStorageAccountName>/<FileShareName> nfs
vers=4,minorversion=1,sec=sys 0 0
Para obtener más información, escriba el comando man fstab en la línea de comandos
de Linux.
Validar conectividad
Si se produjo un error en el montaje, es posible que el punto de conexión privado no se
haya configurado correctamente o sea inaccesible. Para más información sobre cómo
confirmar la conectividad, consulte Comprobación de la conectividad.
Instantáneas del recurso compartido de

archivos NFS (versión preliminar)
Los clientes que usan recursos compartidos de archivos de Azure NFS ahora pueden
crear, enumerar y eliminar instantáneas de recursos compartidos de archivos de Azure
NFS. Esta funcionalidad permite a los usuarios revertir sistemas de archivos completos o
recuperar archivos que se eliminaron o dañaron accidentalmente.
） Importante
Debe montar el recurso compartido de archivos antes de crear instantáneas. Si crea

un nuevo recurso compartido de archivos NFS y toma instantáneas antes de
montar el recurso compartido, al intentar enumerar las instantáneas del recurso
compartido se devolverá una lista vacía. Se recomienda eliminar las instantáneas
tomadas antes del primer montaje y volver a crearlas después de montar el recurso
compartido.
Limitaciones
Solo se admiten las API de administración de archivos ( AzRmStorageShare ) para los
recursos compartidos de archivos de Azure NFS. No se admiten las API del plano de
datos de archivos ( AzStorageShare ).
Azure Backup no se admite actualmente para recursos compartidos de archivos NFS.
AzCopy no se admite actualmente para recursos compartidos de archivos NFS. Para

copiar datos desde un recurso compartido de archivos de Azure NFS o una instantánea
de recurso compartido, use herramientas de copia del sistema de archivos como rsync o
fpsync.
La versión preliminar de instantáneas del recurso compartido de archivos NFS de Azure
ya está disponible en todas las regiones de nube pública de Azure.
Creación de una instantánea

Puede crear una instantánea de un recurso compartido de archivos de Azure NFS
mediante Azure PowerShell o la CLI de Azure. Un recurso compartido puede admitir la
creación de hasta 200 instantáneas de recurso compartido.
Azure PowerShell
Para crear una instantánea de un recurso compartido de archivos existente, ejecute
el siguiente comando de PowerShell. Reemplace <resource-group-name> , <storage-
account-name> y <file-share-name> con sus propios valores.
Azure PowerShell
New-AzRmStorageShare -ResourceGroupName "<resource-group-name>" -

StorageAccountName "<storage-account-name>" -Name "<file-share-name>" -
Snapshot
Enumerar recursos compartidos de archivos e

instantáneas
Puede enumerar todos los recursos compartidos de archivos de una cuenta de
almacenamiento, incluidas las instantáneas de recurso compartido, mediante Azure
PowerShell o la CLI de Azure.
Azure PowerShell
Para enumerar todos los recursos compartidos de archivos e instantáneas de una

cuenta de almacenamiento, ejecute el siguiente comando de PowerShell.
Reemplace <resource-group-name> y <storage-account-name> con sus propios
valores.
Azure PowerShell
Get-AzRmStorageShare -ResourceGroupName "<resource-group-name>" -

StorageAccountName "<storage-account-name>" -IncludeSnapshot
Eliminar instantáneas
Las instantáneas de recurso compartido existentes nunca se sobrescriben. Deben
eliminarse explícitamente. Puede eliminar instantáneas de recurso compartido mediante
Azure PowerShell o la CLI de Azure.
Azure PowerShell
Para eliminar una instantánea de recurso compartido de archivos, ejecute el

siguiente comando de PowerShell. Reemplace <resource-group-name> , <storage-
account-name> y <file-share-name> con sus propios valores. El parámetro
SnapshotTime debe seguir el formato de nombre correcto, como 2021-05-
10T08:04:08Z .
Azure PowerShell
Remove-AzRmStorageShare -ResourceGroupName "<resource-group-name>" -

StorageAccountName "<storage-account-name>" -Name "<file-share-name>" -
SnapshotTime "<snapshot-time>"
Para eliminar un recurso compartido de archivos y todas sus instantáneas, ejecute el

siguiente comando de PowerShell. Reemplace <resource-group-name> , <storage-
account-name> y <file-share-name> con sus propios valores.
Azure PowerShell
Remove-AzRmStorageShare "<resource-group-name>" -StorageAccountName "

<storage-account-name>" -Name "<file-share-name>" -Include Snapshots
Montaje de una instantánea de recurso compartido de

archivos de Azure NFS
Para montar una instantánea de recurso compartido de archivos de Azure NFS en una
máquina virtual Linux (cliente NFS) y restaurar archivos, siga estos pasos.
1. Ejecute el siguiente comando en una consola. Consulte Opciones de montaje para

ver otras opciones de montaje recomendadas. Para mejorar el rendimiento de la
copia, monte la instantánea con nconnect para usar varios canales TCP.
Bash
sudo mount -o vers=4,minorversion=1,proto=tcp,sec=sys

$server:/nfs4account/share /media/nfs
2. Cambie el directorio a /media/nfs/.snapshots para poder ver las instantáneas

disponibles. El directorio .snapshots está oculto de forma predeterminada, pero
puede acceder a él y leerlo como cualquier directorio.
Bash
cd /media/nfs/.snapshots
3. Enumere el contenido de la carpeta .snapshots .
Bash
ls
4. Cada instantánea tiene su propio directorio que actúa como punto de

recuperación. Cambie al directorio de instantáneas cuyos archivos desea restaurar.
Bash
cd <snapshot-name>
5. Enumere el contenido del directorio para ver una lista de archivos y directorios que
se pueden recuperar.
Bash
ls
6. Copie todos los archivos y directorios de la instantánea en un directorio de

restauración para completar la restauración.
Bash
cp -r <snapshot-name> ../restore
Los archivos y directorios de la instantánea ahora deben estar disponibles en el

directorio /media/nfs/restore .
Pasos siguientes
Obtenga más información sobre Azure Files con nuestro artículo Planeamiento de
una implementación de Azure Files.
Si tiene algún problema, consulte Solución de problemas de los recursos
compartidos de archivos NFS de Azure.
archivos de Azure de SMB en macOS
Artículo • 01/06/2023

compartidos de archivos de Azure se pueden montar con el protocolo estándar del
sector SMB 3 con macOS High Sierra 10.13 y versiones posteriores. En este artículo se
muestran dos maneras diferentes de montar un recurso compartido de archivos de
Azure en macOS, con la interfaz de usuario de Finder y utilizando el Terminal.
Requisitos previos para el montaje de un

recurso compartido de archivos de Azure en
macOS
Nombre de la cuenta de almacenamiento: para montar un recurso compartido de
archivos de Azure, necesitará el nombre de la cuenta de almacenamiento.
Clave de la cuenta de almacenamiento: para montar un recurso compartido de

archivos de Azure, necesitará la clave principal (o secundaria) de la cuenta de
almacenamiento. Actualmente no se admiten claves SAS para el montaje.
Asegúrese de que el puerto 445 está abierto: SMB se comunica a través del
puerto TCP 445. En el equipo cliente (Mac), compruebe que el firewall no bloquea
el puerto TCP 445. Si la organización o el ISP bloquea el puerto 445, es posible que
tenga que configurar una VPN desde el entorno local en la cuenta de
almacenamiento de Azure con Azure Files expuesto en la red interna mediante
puntos de conexión privados, de modo que el tráfico pase por un túnel seguro en
lugar de hacerlo por Internet. Para más información, consulte Consideraciones de
redes para el acceso directo a los recursos compartidos de archivos de Azure. Para
ver el resumen de los ISP que permiten o deniegan el acceso desde el puerto 445,
visite TechNet .
Se aplica a

Montaje de un recurso compartido de archivos

de Azure con Finder
1. Abrir Finder: Finder está abierto en macOS de forma predeterminada, pero puede
asegurarse de sea la aplicación seleccionada si hace clic en el "icono de cara de
macOS" en el Dock:
2. Seleccione "Connect to Server" (Conectar a servidor) en el menú "Go" (Ir) : en la

ruta de acceso UNC de los requisitos previos, convierta la doble barra diagonal
inversa de comienzo ( \\ ) en smb:// y todas las otras barras diagonales inversas
( \ ) en barras diagonales ( / ). El vínculo debe ser similar al siguiente:
3. Utilice el nombre y la clave de la cuenta de almacenamiento cuando se le solicite

un nombre de usuario y contraseña: al hacer clic en "Conectar" en el cuadro de
diálogo "Conectar a servidor", se le pedirá el nombre de usuario y una contraseña
(se rellenará automáticamente con el nombre de usuario de macOS). Puede
guardar el nombre y la clave de la cuenta de almacenamiento en la cadena de
claves de macOS.
4. Use el recurso compartido de archivos de Azure de la forma deseada: después de

sustituir el nombre del recurso compartido y la clave de la cuenta de
almacenamiento por el nombre de usuario y la contraseña, se montará el recurso
compartido. Se puede utilizar como lo haría normalmente con una carpeta local o
un recurso compartido de archivos, incluido arrastrar y soltar archivos en el recurso
compartido de archivos:

de Azure con el Terminal
1. Reemplace <storage-account-name> , <storage-account-key> y <share-name> por
los valores adecuados para su entorno.
open smb://<storage-account-name>:<storage-account-key>@<storage-
account-name>.file.core.windows.net/<share-name>
2. Uso del recurso compartido de archivos de Azure: el recurso compartido de

archivos de Azure se montará en el punto de montaje especificado por el
comando anterior.
Pasos siguientes
Conectar el Mac a ordenadores y servidores compartidos: soporte técnico de
Apple
Configuración de puntos de conexión
de red de Azure Files
Artículo • 11/05/2023
Azure Files proporciona dos tipos principales de puntos de conexión para el acceso a los
recursos compartidos de archivos de Azure:
Puntos de conexión públicos, que tienen una dirección IP pública y a los que se
puede acceder desde cualquier parte del mundo.
Puntos de conexión privados, que existen dentro de una red virtual y tienen una
dirección IP privada en el espacio de direcciones de esa red virtual.
Los puntos de conexión públicos y privados existen en la cuenta de almacenamiento de

Azure. Una cuenta de almacenamiento es una construcción de administración que
representa un grupo compartido de almacenamiento en el que puede implementar
varios recursos compartidos de archivos u otros recursos de almacenamiento, como
Este artículo se centra en cómo configurar los puntos de conexión de una cuenta de
almacenamiento para acceder directamente al recurso compartido de archivos de Azure.
La mayoría de los detalles proporcionados en este documento también se aplican al
modo en que Azure File Sync interopera con puntos de conexión públicos y privados de
la cuenta de almacenamiento; sin embargo, para más información sobre las
consideraciones de redes para una implementación de Azure File Sync, consulte
Configuración del proxy y el firewall de Azure File Sync.
Se recomienda leer Consideraciones de redes para Azure Files antes de pasar a esta guía
de procedimientos.
Se aplica a
Prerrequisitos
En este artículo se supone que ya ha creado una suscripción a Azure. Si todavía no
tiene una suscripción, cree una cuenta gratuita antes de empezar.
En este artículo se supone que ya ha creado un recurso compartido de archivos de
Azure en una cuenta de almacenamiento a la que le gustaría conectarse desde el
entorno local. Para aprender a crear un recurso compartido de archivos de Azure,
consulte Creación de un recurso compartido de archivos de Azure.
Configuraciones de punto de conexión

Puede configurar los puntos de conexión para restringir el acceso de red a su cuenta de
almacenamiento. Existen dos enfoques para restringir el acceso de una cuenta de
almacenamiento a una red virtual:
Cree uno o varios puntos de conexión privados para la cuenta de almacenamiento

y restrinja todo el acceso al punto de conexión público. De esta forma se garantiza
que solo el tráfico que se origina en las redes virtuales deseadas pueda acceder a
los recursos compartidos de archivos de Azure dentro de la cuenta de
almacenamiento. *Consulte Costes de Private Link .
Restrinja el punto de conexión público a una o más redes virtuales. Para ello, se
usa una funcionalidad de la red virtual llamada puntos de conexión de servicio. Al
restringir el tráfico a una cuenta de almacenamiento a través de un punto de
conexión de servicio, sigue teniendo acceso a la cuenta de almacenamiento a
través de la dirección IP pública, pero el acceso solo es posible desde las
ubicaciones especificadas en la configuración.
Creación de un punto de conexión privado

La creación de un punto de conexión privado para la cuenta de almacenamiento hará
que se implementen los siguientes recursos de Azure:
Punto de conexión privado: un recurso de Azure que representa el punto de

conexión privado de la cuenta de almacenamiento. Puede considerarlo como un
recurso que conecta una cuenta de almacenamiento y una interfaz de red.
Interfaz de red (NIC) : la interfaz de red que mantiene una dirección IP privada
dentro de la red virtual o subred especificadas. Es el mismo recurso exacto que se
implementa cuando se implementa una máquina virtual, pero en lugar de
asignarlo a una máquina virtual, es propiedad del punto de conexión privado.
Zona DNS privada: si nunca ha implementado antes un punto de conexión privado
para esta red virtual, se implementará una nueva zona DNS privada para ella.
También se creará en esta zona DNS un registro D de DNS para la cuenta de
almacenamiento. Si ya ha implementado un punto de conexión privado en esta
red virtual, se agregará a la zona DNS existente un nuevo registro D para la cuenta
de almacenamiento. La implementación de una zona DNS es opcional, sin
embargo, es muy recomendable y necesaria si va a montar los recursos
compartidos de archivos de Azure con una entidad de servicio de AD o mediante
la API FileREST.
７ Nota
En este artículo se usa el sufijo DNS de la cuenta de almacenamiento para las

regiones públicas de Azure core.windows.net . Este comentario también se aplica a
nubes soberanas de Azure, como la nube de Azure US Government y la nube de
Azure China; simplemente sustituya los sufijos adecuados en su entorno.
Portal
Vaya a la cuenta de almacenamiento para la que desea crear un punto de conexión

privado. En la tabla de contenido de la cuenta de almacenamiento, seleccione
Redes, Private endpoint connections (Conexiones de punto de conexión privado) y,
por último, + Private endpoint (+ Punto de conexión privado) para crear un punto
de conexión privado.
El asistente resultante tiene varias páginas que debe completar:

En la hoja Aspectos básicos, seleccione la suscripción, el grupo de recursos, el
nombre, el nombre de la interfaz de red y la región que quiera para el punto de
conexión privado. Estos pueden ser cualquier cosa que desee y no tienen que
coincidir con la cuenta de almacenamiento en ningún aspecto, aunque debe crear
el punto de conexión privado en la misma región que la red virtual en la que quiere
crear el punto de conexión privado. Después, seleccione Siguiente: Recurso.
En la hoja Recurso, seleccione archivo para el subrecurso de destino. A

continuación, seleccione Siguiente: Red virtual.
La hoja Red virtual permite seleccionar la red virtual y la subred específicas a las
que le gustaría agregar el punto de conexión privado. Seleccione la asignación de
direcciones IP dinámicas o estáticas para el nuevo punto de conexión privado. Si
selecciona estáticas, también deberá proporcionar un nombre y una dirección IP
privada. También puede especificar opcionalmente un grupo de seguridad de
aplicación. Al acabar, seleccione Siguiente: DNS.
La hoja DNS contiene la información de integración del punto de conexión privado

con una zona DNS privada. Asegúrese de que la suscripción y el grupo de recursos
sean correctos y seleccione Siguiente: Etiquetas.
Opcionalmente, puede aplicar etiquetas para clasificar los recursos, como aplicar el

Haga clic en Revisar y crear para crear el punto de conexión privado.
Verificación de la conectividad
Portal
Si tiene una máquina virtual dentro de la red virtual o ha configurado el reenvío de

DNS tal como se describe en Configuración del reenvío de DNS para Azure Files,
puede comprobar que el punto de conexión privado se ha configurado
correctamente mediante la ejecución de los siguientes comandos desde PowerShell,
la línea de comandos o el terminal (sirve para Windows, Linux o macOS). Debe
reemplazar <storage-account-name> por el nombre adecuado de la cuenta de
almacenamiento:
nslookup <storage-account-name>.file.core.windows.net
Si todo ha funcionado correctamente, verá la siguiente salida, donde 192.168.0.5

es la dirección IP privada del punto de conexión privado de la red virtual (salida
mostrada para Windows):
Output
Server: UnKnown
Address: 10.2.4.4
Non-authoritative answer:
Name: storageaccount.privatelink.file.core.windows.net
Address: 192.168.0.5
Aliases: storageaccount.file.core.windows.net
Restricción del acceso al punto de conexión
público
Para limitar el acceso al punto de conexión público es necesario deshabilitar el acceso
general al punto de conexión público. Deshabilitar el acceso al punto de conexión
público no afecta a los puntos de conexión privados. Una vez deshabilitado el punto de
conexión público, puede seleccionar redes o direcciones IP específicas que puedan
seguir accediendo a él. En general, la mayoría de las directivas de firewall de una cuenta
de almacenamiento restringen el acceso de red a una o varias redes virtuales.
Deshabilitación del acceso al punto de conexión público

Si el acceso al punto de conexión público está deshabilitado, aún se puede acceder a la
cuenta de almacenamiento a través de los puntos de conexión privados. De lo contrario,
se rechazarán las solicitudes válidas al punto de conexión público de la cuenta de
almacenamiento, a menos que provengan de un origen permitido específicamente.
Portal
Vaya a la cuenta de almacenamiento para la que desea restringir todo el acceso al

punto de conexión público. En la tabla de contenido de la cuenta de
almacenamiento, seleccione la entrada Redes.
En la parte superior de la página, seleccione el botón de radio Habilitado desde

redes virtuales y direcciones IP seleccionadas. Esta acción anulará la ocultación de
una serie de opciones para controlar la restricción del punto de conexión público.
Seleccione Permitir que los servicios de Azure de la lista de servicios de confianza
accedan a esta cuenta de almacenamiento para permitir que los servicios de
Microsoft de confianza de terceros, como Azure File Sync, accedan a la cuenta de
almacenamiento.

Restricción del acceso al punto de conexión público a redes

virtuales específicas
Al restringir la cuenta de almacenamiento a redes virtuales específicas, se permiten
solicitudes al punto de conexión público en las redes virtuales especificadas. Para ello, se
usa una funcionalidad de la red virtual llamada puntos de conexión de servicio. Esta
funcionalidad se puede usar con o sin puntos de conexión privados.
Portal
Vaya a la cuenta de almacenamiento para la que desea restringir el punto de

conexión público a redes virtuales específicas. En la tabla de contenido de la cuenta
de almacenamiento, seleccione la entrada Redes.
En la parte superior de la página, seleccione el botón de radio Habilitado desde

redes virtuales y direcciones IP seleccionadas. Esta acción anulará la ocultación de
una serie de opciones para controlar la restricción del punto de conexión público.
Seleccione +Agregar red virtual existente para seleccionar la red virtual específica
a la que se debe permitir el acceso a la cuenta de almacenamiento a través del
punto de conexión público. Seleccione una red virtual y una subred para esa red
virtual y, luego, elija Habilitar.
Seleccione Permitir que los servicios de Azure de la lista de servicios de confianza
accedan a esta cuenta de almacenamiento para permitir que los servicios de
Microsoft de confianza de terceros, como Azure File Sync, accedan a la cuenta de
almacenamiento.
Consulte también
Configuración del reenvío de DNS para Azure Files
Configuración de VPN S2S para Azure Files
Configuración del reenvío de DNS para
Azure Files
Artículo • 03/09/2023
Azure Files le permite crear puntos de conexión privados para las cuentas de
almacenamiento que contienen los recursos compartidos de archivos. Aunque son útiles
para muchas aplicaciones diferentes, los puntos de conexión privados lo son
especialmente para conectarse a los recursos compartidos de archivos de Azure desde
la red local mediante una conexión VPN o ExpressRoute con emparejamiento privado.
Para que las conexiones a la cuenta de almacenamiento pasen por el túnel de red, el
nombre de dominio completo (FQDN) de la cuenta de almacenamiento debe resolverse
en la dirección IP privada del punto de conexión privado. Para ello, debe reenviar el
sufijo del punto de conexión de almacenamiento ( core.windows.net para las regiones
de la nube pública) al servicio DNS privado de Azure accesible desde la red virtual. En
esta guía se muestra cómo configurar el reenvío de DNS para que se resuelva
correctamente en la dirección IP del punto de conexión privado de la cuenta de
almacenamiento.
Se recomienda encarecidamente leer Planeamiento de una implementación de Azure

Files y Consideraciones de redes para Azure Files antes de seguir los pasos que se
describen en este artículo.
Se aplica a
Información general
Azure Files proporciona los siguientes tipos de puntos de conexión para el acceso a los
recursos compartidos de archivos de Azure:
Puntos de conexión públicos, que tienen una dirección IP pública y a los que se
puede acceder desde cualquier parte del mundo.
Puntos de conexión privados, que existen dentro de una red virtual y tienen una
dirección IP privada en el espacio de direcciones de esa red virtual.
Puntos de conexión de servicio, que restringen el acceso al punto de conexión
público a redes virtuales específicas. Sigue accediendo a la cuenta de
almacenamiento a través de la dirección IP pública, pero el acceso solo es posible
desde las ubicaciones especificadas en la configuración.
Los puntos de conexión públicos y privados existen en la cuenta de almacenamiento de

Azure. Una cuenta de almacenamiento es una construcción de administración que
representa un grupo compartido de almacenamiento en el que puede implementar
varios recursos compartidos de archivos u otros recursos de almacenamiento, como
Cada cuenta de almacenamiento tiene un nombre de dominio completo (FQDN). En el

caso de las regiones de la nube pública, este FQDN sigue el patrón
storageaccount.file.core.windows.net , donde storageaccount es el nombre de la
cuenta de almacenamiento. Cuando se realizan solicitudes con este nombre, como

montar el recurso compartido en la estación de trabajo, el sistema operativo hace una
búsqueda DNS para resolver el nombre de dominio completo en una dirección IP.
De forma predeterminada, storageaccount.file.core.windows.net se resuelve en la

dirección IP del punto de conexión público. El punto de conexión público de una cuenta
de almacenamiento se hospeda en un clúster de almacenamiento de Azure que
hospeda muchos otros puntos de conexión públicos de las cuentas de almacenamiento.
Cuando se crea un punto de conexión privado, una zona DNS privada se vincula a la red
virtual a la que se agregó, con una asignación de registros CNAME
storageaccount.file.core.windows.net a una entrada de registros D para la dirección IP
privada del punto de conexión privado de la cuenta de almacenamiento. Esto le permite

usar el FQDN storageaccount.file.core.windows.net dentro de la red virtual y hacer
que se resuelva en la dirección IP del punto de conexión privado.
Dado que nuestro objetivo final es acceder a los recursos compartidos de archivos de
Azure hospedados en la cuenta de almacenamiento desde el entorno local mediante un
túnel de red, como una conexión VPN o ExpressRoute, debe configurar los servidores
DNS locales para que reenvíen las solicitudes realizadas al servicio Azure Files al servicio
DNS privado de Azure.
Puede configurar el reenvío DNS de una de estas dos maneras:
Uso de las máquinas virtuales de servidor DNS: Configure el reenvío condicional

de *.core.windows.net (o el sufijo del punto de conexión de almacenamiento
adecuado para las nubes nacionales de EE. UU., Alemania o China) en un servidor
DNS hospedado en la red virtual de Azure. A continuación, este servidor DNS
reenviará de forma recursiva la solicitud al servicio DNS privado de Azure, que
resolverá el nombre de dominio completo de la cuenta de almacenamiento en la
dirección IP privada adecuada. Este es un paso único para todos los recursos
compartidos de archivos de Azure hospedados en la red virtual.
Uso de Azure DNS Private Resolver: Si no desea implementar un servidor DNS

basado en máquina virtual, puede realizar la misma tarea mediante Azure DNS
Private Resolver.
Además de Azure Files, las solicitudes de resolución de nombres DNS para otros
servicios de almacenamiento de Azure (Azure Blob Storage, Azure Table Storage, Azure
Queue Storage, etc.) se reenviarán al servicio DNS privado de Azure. Si lo desea, puede
agregar puntos de conexión adicionales para otros servicios de Azure.
Requisitos previos
Para poder configurar el reenvío de DNS a Azure Files, necesitará lo siguiente:
Una cuenta de almacenamiento que contenga un recurso compartido de archivos

de Azure que le gustaría montar. Para aprender a crear una cuenta de
almacenamiento y un recurso compartido de archivos de Azure, consulte Creación
de un recurso compartido de archivos de Azure.
Un punto de conexión privado para la cuenta de almacenamiento. Consulte
Creación de un punto de conexión privado.
La versión más reciente del módulo de Azure PowerShell.
Configuración del reenvío de DNS mediante

máquinas virtuales
Si ya tiene colocados servidores DNS en la red virtual de Azure, o si prefiere
implementar sus propias máquinas virtuales como servidores DNS por cualquier
metodología que use la organización, puede configurar DNS con los cmdlets de
PowerShell integrados del servidor DNS.

） Importante
En esta guía se da por supuesto que está usando el servidor DNS en

Windows Server en el entorno local. Todos los pasos descritos aquí son posibles
con cualquier servidor DNS, no solo con el de Windows.
En los servidores DNS locales, cree un reenviador condicional mediante Add-

DnsServerConditionalForwarderZone . Este reenviador condicional debe implementarse en
todos los servidores DNS locales para que sea eficaz a la hora de reenviar correctamente
el tráfico a Azure. No olvide reemplazar las entradas <azure-dns-server-ip> por las
direcciones IP adecuadas para su entorno.
PowerShell
$vnetDnsServers = "<azure-dns-server-ip>", "<azure-dns-server-ip>"
$storageAccountEndpoint = Get-AzContext | `
Select-Object -ExpandProperty Environment | `
Select-Object -ExpandProperty StorageEndpointSuffix
Add-DnsServerConditionalForwarderZone `
-Name $storageAccountEndpoint `
-MasterServers $vnetDnsServers
En los servidores DNS de la red virtual de Azure, también deberá colocar un reenviador
de forma que las solicitudes de la zona DNS de la cuenta de almacenamiento se dirijan
al servicio DNS privado de Azure, encabezado por la dirección IP reservada
168.63.129.16 . (Si ejecuta los comandos en una sesión de PowerShell diferente,
recuerde rellenar $storageAccountEndpoint ).
PowerShell
-MasterServers "168.63.129.16"
Configuración del reenvío de DNS mediante

Azure DNS Private Resolver
Si prefiere no implementar máquinas virtuales del servidor DNS, puede realizar la misma
tarea mediante Azure DNS Private Resolver. Creación de una instancia de Azure DNS
Private Resolver mediante Azure Portal.

No hay ninguna diferencia en la forma de configurar los servidores DNS locales, salvo
que, en lugar de apuntar a las direcciones IP de los servidores DNS en Azure, apunte a la
dirección IP del punto de conexión de entrada del solucionador. La resolución no
requiere ninguna configuración, ya que reenviará consultas al servidor DNS privado de
Azure de forma predeterminada. Si una zona DNS privada está vinculada a la red virtual
donde se implementa la resolución, el solucionador podrá responder con registros de
esa zona DNS.
２ Advertencia
Al configurar reenviadores para la zona de core.windows.net , todas las consultas de

este dominio público se reenviarán a la infraestructura de Azure DNS. Esto provoca
un problema al intentar acceder a una cuenta de almacenamiento de un inquilino
diferente que se ha configurado con puntos de conexión privados, ya que Azure
DNS responderá a la consulta del nombre público de la cuenta de almacenamiento
con un CNAME que no existe en la zona DNS privada. Una solución alternativa para
este problema es crear un punto de conexión privado entre inquilinos en el
entorno para conectarse a esa cuenta de almacenamiento.
Para configurar el reenvío DNS mediante Azure DNS Private Resolver, ejecute este script
en los servidores DNS locales. Reemplace <resolver-ip> por la dirección IP del punto
de conexión de entrada del solucionador.
PowerShell
$privateResolver = "<resolver-ip>"
$storageAccountEndpoint = Get-AzContext | `
Select-Object -ExpandProperty Environment | `
Select-Object -ExpandProperty StorageEndpointSuffix
-MasterServers $privateResolver
Confirmación de reenviadores DNS

Antes de realizar pruebas para ver si los reenviadores de DNS se han aplicado
correctamente, se recomienda borrar la caché de DNS en la estación de trabajo local
mediante Clear-DnsClientCache . Para comprobar si puede resolver correctamente el
nombre de dominio completo de la cuenta de almacenamiento, use Resolve-DnsName o
nslookup .
PowerShell
# Replace storageaccount.file.core.windows.net with the appropriate FQDN for

your storage account.
# Note that the proper suffix (core.windows.net) depends on the cloud you're
deployed in.
Resolve-DnsName -Name storageaccount.file.core.windows.net
Si la resolución de nombres se realiza correctamente, verá que la dirección IP resuelta

coincide con la dirección IP de la cuenta de almacenamiento.
Output

---- ---- --- ------- --------
csostoracct.privatelink.file.core.windows.net
net
Name : storageaccount.privatelink.file.core.windows.net
QueryType : A
TTL : 1769
Section : Answer
IP4Address : 192.168.0.4
Si va a montar un recurso compartido de archivos SMB, también puede usar el comando

Test-NetConnection para confirmar que se puede realizar correctamente una conexión
TCP a la cuenta de almacenamiento.
PowerShell
Test-NetConnection -ComputerName storageaccount.file.core.windows.net -

CommonTCPPort SMB
Consulte también
Configuración de puntos de conexión de red de Azure Files
Configuración de una VPN de sitio a
sitio para su uso con Azure Files
Artículo • 13/12/2023
Puede usar una conexión VPN de sitio a sitio (S2S) para montar los recursos
compartidos de archivos de Azure desde la red local, sin necesidad de enviar datos por
la red abierta de Internet. Puede configurar una VPN de sitio a sitio mediante Azure VPN
Gateway, que es un recurso de Azure que ofrece servicios VPN y se implementa en un
grupo de recursos junto con las cuentas de almacenamiento u otros recursos de Azure.
Se recomienda encarecidamente que lea introducción a la conexión en red de Azure

Files antes de continuar con este artículo para obtener una explicación completa de las
opciones de red disponibles para Azure Files.
En este artículo se detallan los pasos para configurar una VPN de sitio a sitio para
montar recursos compartidos de archivos de Azure directamente en el entorno local. Si
quiere enrutar el tráfico de sincronización de Azure File Sync a través de una VPN de
sitio a sitio, consulte configuración del proxy y del firewall de Azure File Sync.
Se aplica a
ﾉ Expandir tabla
Requisitos previos
Un recurso compartido de archivos de Azure que le gustaría montar en el entorno
local. Los recursos compartidos de archivos de Azure se implementan en cuentas
de almacenamiento, que son construcciones de administración que representan un
grupo compartido de almacenamiento en el que puede implementar varios
recursos compartidos de archivos, así como otros recursos de almacenamiento,
como blobs o colas. Puede encontrar más información sobre cómo implementar
cuentas de almacenamiento y recursos compartidos de archivos de Azure en
Creación de un recurso compartido de archivos de Azure.
Un punto de conexión privado para la cuenta de almacenamiento que contiene el

recurso compartido de archivos de Azure que quiere montar localmente. Para más
información sobre cómo crear un punto de conexión privado, consulte
Configuración de puntos de conexión de red de Azure Files.
Un dispositivo de red o un servidor en el centro de datos local que sea compatible

con Azure VPN Gateway. Azure Files es independiente del dispositivo de red local
elegido, pero Azure VPN Gateway mantiene una lista de los dispositivos probados.
Los diferentes dispositivos de red ofrecen distintas funciones, características de
rendimiento y funcionalidades de administración, por lo que debe tenerlas en
cuenta al seleccionar un dispositivo de red.
Si no tiene un dispositivo de red existente, Windows Server contiene un rol de servidor

integrado, enrutamiento y acceso remoto (RRAS), que se puede usar como dispositivo
de red local. Para obtener más información acerca de cómo configurar el enrutamiento y
acceso remoto en Windows Server, consulte Puerta de enlace de RAS.
Agregar red virtual a una cuenta de
almacenamiento
Para agregar una red virtual nueva o existente a la cuenta de almacenamiento, siga
estos pasos.
1. Inicie sesión en Azure Portal y vaya a la cuenta de almacenamiento que contiene el

recurso compartido de archivos de Azure que desea montar en el entorno local.
2. En la tabla de contenido de la cuenta de almacenamiento, seleccione Seguridad +

conexión en red > Redes. A menos que haya agregado una red virtual a la cuenta
de almacenamiento al crearla, el panel resultante debe tener el botón de radio
para Habilitado desde todas las redes seleccionada en Acceso a la red pública.
3. Para agregar una red virtual, seleccione el Habilitado en redes virtuales

seleccionadas y direcciones IP botón de radio. En el subred Redes virtuales,
seleccione + Agregar de red virtual existente o + Agregar nueva red virtual. Al
crear una nueva red virtual, se creará un nuevo recurso de Azure. El recurso de red
virtual nuevo o existente debe estar en la misma región que la cuenta de
almacenamiento, pero no es necesario que esté en el mismo grupo de recursos o
suscripción. Sin embargo, tenga en cuenta que el grupo de recursos, la región y la
suscripción en los que implemente la red virtual deben coincidir donde
implemente la puerta de enlace de red virtual en el paso siguiente.
Si agrega una red virtual existente, primero debe crear una subred de puerta de
enlace en la red virtual. Se le pedirá que seleccione una o varias subredes de esa
red virtual. Si crea una nueva red virtual, creará una subred como parte del proceso
de creación. Puede agregar más subredes más adelante a través del recurso de
Azure resultante para la red virtual.
Si no ha habilitado el acceso de red pública a la red virtual anteriormente, es

necesario agregar el punto de conexión de servicio Microsoft.Storage a la subred
de la red virtual. Esto puede tardar hasta 15 minutos en completarse, aunque en la
mayoría de los casos se completará mucho más rápido. Hasta que se haya
completado esta operación, no podrá acceder a los recursos compartidos de
archivos de Azure dentro de esa cuenta de almacenamiento, incluido a través de la
conexión VPN.
4. En la parte superior de la página, seleccione Guardar.
Implementación de una puerta de enlace de

red virtual
Para implementar una puerta de enlace de red virtual, siga estos pasos.
1. En el cuadro de búsqueda de la parte superior de Azure Portal, busque y

seleccione Puertas de enlace de red virtual. Debería aparecer la página puertas de
enlace de red virtual. En la parte superior de la página, seleccione + Crear.
2. En la pestaña Aspectos básicos, rellene los valores de Detalles del proyecto y

Detalles de la instancia. La puerta de enlace de red virtual debe estar en la misma
suscripción, región de Azure y grupo de recursos que la red virtual.
Suscripción: seleccione la suscripción que desea usar en la lista desplegable.
Grupo de recursos: esta configuración se rellena automáticamente cuando
selecciona la red virtual en esta página.
Nombre: Nombre a la puerta de enlace de red virtual. Asignar un nombre a la
puerta de enlace no es el mismo que asignar un nombre a una subred de
puerta de enlace. Es el nombre del objeto de puerta de enlace de red virtual
que está creando.
Región: Seleccione la región en la que quiere crear este recurso. La región de
la puerta de enlace de red virtual debe ser la misma que la red virtual.
Tipo de puerta de enlace: Seleccione VPN. Las puertas de enlace VPN usan el
tipo de puerta de enlace de red virtual VPN.
SKU: seleccione el SKU de puerta de enlace que admita las características que
desea usar en la lista desplegable. la SKU controla el número de túneles de
sitio a sitio permitidos y el rendimiento deseado de la VPN. Consulte SKU de
puerta de enlace. No use la SKU básico si desea usar la autenticación IKEv2
(VPN basada en rutas).
Generación: seleccione la generación que desea usar. Se recomienda usar
una SKU de segunda generación. Consulte SKU de puertas de enlace para
más información.
Red virtual: En la lista desplegable, seleccione la red virtual que agregó a la
cuenta de almacenamiento en el paso anterior.
Subred: este campo debería estar atenuado y enumerar el nombre de la
subred de la puerta de enlace que ha creado, junto con su intervalo IP de
direcciones. Si en su lugar ve un intervalo de direcciones de subred de puerta
de enlace campo con un cuadro de texto, aún no ha configurado una subred
de puerta de enlace en la red virtual.
3. Especifique los valores de la dirección IP pública que se asocia a la puerta de

enlace de red virtual. La dirección IP pública se asigna a este objeto cuando se crea
la puerta de enlace de red virtual. La única vez que la dirección IP pública principal
cambia es cuando la puerta de enlace se elimina y se vuelve a crear. No cambiará
al modificar el tamaño, restablecer o realizar otro tipo de mantenimiento interno o
actualizaciones.
Dirección IP pública: la dirección IP de la puerta de enlace de red virtual que

se expondrá a Internet. Es probable que tenga que crear una nueva dirección
IP, pero también puede usar una dirección IP existente sin usar. Si selecciona
Crear nuevo, se creará un nuevo recurso de Azure de dirección IP en el
mismo grupo de recursos que la puerta de enlace de red virtual y el nombre
de dirección IP pública será el nombre de la dirección IP recién creada. Si
selecciona Usar existente, debe seleccionar la dirección IP existente sin usar.
Nombre de dirección IP pública: En el cuadro de texto, escriba un nombre
para la dirección IP pública.
SKU de dirección IP pública: la configuración se selecciona automáticamente.
Asignación: por lo general, la asignación se selecciona automáticamente y
puede ser dinámica o estática.
Habilitar el modo activo/activo: seleccione Deshabilitado. Habilite esta
configuración solo si va a crear una configuración de puerta de enlace activa-
activa. Para obtener más información sobre el modo activo/activo, consulte
Conectividad de alta disponibilidad entre locales y de red virtual a red virtual.
Configurar BGP: Seleccione Deshabilitado, a menos que la configuración
requiera específicamente el protocolo de puerta de enlace de borde. Si
necesita este valor de configuración, el valor predeterminado del ASN es
65515, aunque esto se puede cambiar. Para obtener más información acerca
de esta configuración, consulte Acerca de BGP con Azure VPN Gateway.
4. Seleccione Revisar y crear para ejecutar la validación. Una vez superada la

validación, seleccione Crear para implementar la puerta de enlace de red virtual. La
implementación puede tardar hasta 45 minutos en completarse.
Creación de una puerta de enlace de red local para la

puerta de enlace local
Una puerta de enlace de red local es un recurso de Azure que representa al dispositivo
de red local. Se implementa junto con la cuenta de almacenamiento, la red virtual y la
puerta de enlace de red virtual, pero no es necesario estar en el mismo grupo de
recursos o suscripción que la cuenta de almacenamiento. Para crear una puerta de
enlace de red local, siga estos pasos.
1. En el cuadro de búsqueda de la parte superior de Azure Portal, busque y

seleccione puertas de enlace de red locales. Debería aparecer la página puertas de
enlace de red local. En la parte superior de la página, seleccione + Crear.

Detalles de la instancia.
Suscripción: La suscripción de Azure deseada. No es necesario que coincida
con la suscripción que se usa para la puerta de enlace de red virtual o la
Grupo de recursos: el grupo de recursos deseado. No es necesario que
coincida con el grupo de recursos usado para la puerta de enlace de red
virtual o la cuenta de almacenamiento.
Región: la región de Azure en la que se debe crear el recurso de puerta de
enlace de red local. Debe coincidir con la región seleccionada para la puerta
de enlace de red virtual y la cuenta de almacenamiento.
Nombre: nombre del recurso de Azure para la puerta de enlace de red local.
Este puede ser cualquier nombre que le resulte útil para la administración.
Punto de conexión: deje seleccionada la dirección IP.
Dirección IP: dirección IP pública de la puerta de enlace local en el entorno
local.
Espacio de direcciones: intervalo o intervalos de direcciones de la red que
representa esta puerta de enlace de red local. Por ejemplo:192.168.0.0/16. Si
agrega varios intervalos de espacio de direcciones, asegúrese de que los
intervalos especificados no se superpongan con intervalos de otras redes a
las que desea conectarse. Si tiene previsto usar esta puerta de enlace de red
local en una conexión habilitada para BGP, el prefijo mínimo que debe
declarar es la dirección de host de la dirección IP del par BGP en el
dispositivo VPN.
3. Si su organización requiere BGP, seleccione la pestaña Avanzado para configurar
los valores de BGP. Para más información, consulte Acerca de BGP con Azure VPN
Gateway.

validación, seleccione Crear para crear la puerta de enlace de red local.
Configuración del dispositivo de red local

Los pasos específicos para configurar el dispositivo de red local dependen del
dispositivo de red seleccionado por la organización. Según el dispositivo que haya
elegido la organización, la lista de dispositivos probadospodría tener un vínculo a las
instrucciones del proveedor del dispositivo para configurar con la puerta de enlace de
red virtual de Azure.
Creación de la conexión de sitio a sitio

Para completar la implementación de una VPN S2S, debe crear una conexión entre el
dispositivo de red local (representado por el recurso de puerta de enlace de red local) y
la puerta de enlace de red virtual de Azure. Para hacerlo, siga estos pasos.
1. Vaya a la puerta de enlace de red virtual que creó. En la tabla de contenido de la

puerta de enlace de red virtual, seleccione Configuración > Conexionesy luego
seleccione+ Agregar.

Suscripción: La suscripción de Azure deseada.
Grupo de recursos: el grupo de recursos deseado.
Tipo de conexión: Como se trata de una conexión S2S, seleccione Sitio a
sitio de (IPSec) en la lista desplegable.
Nombre: nombre de la conexión. Una puerta de enlace de red virtual puede
hospedar varias conexiones, por lo que elija un nombre que sea útil para la
administración y que distinguirá esta conexión determinada.
Región: La región seleccionada para la puerta de enlace de red virtual y la
3. En la pestaña Configuración, proporcione la siguiente información.

Puerta de enlace de red virtual: seleccione la puerta de enlace de red virtual
que ha creado.
Puerta de enlace de red local: seleccione la puerta de enlace de red local que
ha creado.
Clave compartida (PSK): una combinación de letras y números usados para
establecer el cifrado de la conexión. Se debe usar la misma clave compartida
tanto en la red virtual como en las puertas de enlace de red locales. Si el
dispositivo de puerta de enlace no proporciona una, puede crearla aquí y
establecerla en el dispositivo.
Protocolo IKE: en función del dispositivo VPN, seleccione IKEv1 para VPN
basada en directivas o IKEv2 para VPN basada en rutas. Para obtener más
información sobre los dos tipos de puertas de enlace de VPN, consulte
Acerca de las puertas de enlace de VPN basadas en directivas y en rutas.
Uso de la dirección IP privada de Azure: la comprobación de esta opción le
permite usar direcciones IP privadas de Azure para establecer una conexión
VPN IPsec. El soporte para IPs privadas debe estar configurado debe
establecerse en la puerta de enlace VPN para que esta opción funcione. Solo
es admitido en las SKU de puerta de enlace AZ.
Habilitar BGP: deje desactivada a menos que la organización requiera
específicamente esta configuración.
Habilitar direcciones BGP personalizadas: deje desactivada a menos que la
organización requiera específicamente este valor.
FastPath: FastPath está diseñado para mejorar el rendimiento de la ruta de
datos entre la red local y la red virtual. Más información .
Directiva de IPsec o IKE: la directiva IPsec o IKE que se negociará para la
conexión. Deje Predeterminado seleccionado a menos que la organización
requiera una directiva personalizada. Más información.
Use el selector de tráfico basado en directivas: Deje deshabilitado a menos
que necesite configurar la puerta de enlace de VPN de Azure para conectarse
a un firewall de VPN basado en directivas local. Si habilita este campo, debe
asegurarse de que el dispositivo VPN tiene los selectores de tráfico
coincidentes definidos con todas las combinaciones de los prefijos de red
local (puerta de enlace de red local) hacia y desde los prefijos de red virtual
de Azure, en lugar de cualquier uno a cualquiera. Por ejemplo, si los prefijos
de red locales son 10.1.0.0/16 y 10.2.0.0/16, y los prefijos de red virtual son
192.168.0.0/16 y 172.16.0.0/16, debe especificar los siguientes selectores de
tráfico:
10.1.0.0/16 <====> 192.168.0.0/16
10.1.0.0/16 <====> 172.16.0.0/16
10.2.0.0/16 <====> 192.168.0.0/16
10.2.0.0/16 <====> 172.16.0.0/16
Tiempo de espera de DPD en segundos: tiempo de espera de detección del
nodo mismo nivel inactivo de la conexión en segundos. El valor
recomendado y predeterminado de esta propiedad es de 45 segundos.
Modo de conexión: el modo de conexión se usa para decidir qué puerta de
enlace puede iniciar la conexión. Cuando este valor se establece en:
Predeterminado: Tanto Azure como la puerta de enlace VPN local pueden
iniciar la conexión.
ResponderOnly: Azure VPN Gateway nunca iniciará la conexión. La puerta
de enlace de VPN local debe iniciar la conexión.
IniciadorOnly: Azure VPN Gateway iniciará la conexión y rechazará los
intentos de conexión de la puerta de enlace de VPN local.

validación, seleccione Crear para crear la conexión. Puede comprobar que la
conexión se ha realizado correctamente a través de la página Conexiones de la
puerta de enlace de red virtual.

de Azure
El último paso para configurar una VPN de sitio a sitio es comprobar que funciona para
Azure Files. Para ello, monte el recurso compartido de archivos de Azure local. Consulte
las instrucciones de montaje por sistema operativo aquí:
Windows
macOS
Linux (NFS)
Linux (SMB)
Consulte también
Introducción a las redes de Azure Files
Configuración de una VPN de punto a sitio (P2S) en Windows para su uso con
Azure Files
Configuración de una VPN de punto a sitio (P2S) en Linux para su uso con Azure
Files
Configuración de una VPN de punto a
sitio (P2S) en Windows para su uso con
Azure Files
Artículo • 06/12/2023
Puede usar una conexión VPN de punto a sitio (P2S) para montar los recursos
compartidos de archivos de Azure a través de SMB desde fuera de Azure, sin necesidad
de abrir el puerto 445. Una conexión VPN de punto a sitio es una conexión VPN entre
Azure y un cliente individual. Para usar una conexión VPN de punto a sitio con
Azure Files, debe configurar una conexión VPN para cada cliente que quiera conectarse.
Si tiene muchos clientes que necesitan conectarse a sus recursos compartidos de
archivos de Azure desde la red local, puede usar una conexión VPN de sitio a sitio (S2S)
en lugar de una conexión de punto a sitio para cada cliente. Para obtener más
información, consulte Configuración de una VPN de sitio a sitio para su uso con
Azure Files.
Se recomienda encarecidamente que consulte Consideraciones sobre redes para el

acceso directo a los recursos compartidos de archivos de Azure antes de continuar con
este artículo paso a paso para obtener una descripción completa de las opciones de red
disponibles para Azure Files.
En este artículo se detallan los pasos para configurar una VPN de punto a sitio en
Windows (cliente de Windows y Windows Server) para montar recursos compartidos de
archivos de Azure directamente en el entorno local. Si quiere enrutar el tráfico de
Azure File Sync a través de una VPN, consulte Configuración del proxy y el firewall de
Azure File Sync.
Se aplica a
ﾉ Expand table

Requisitos previos
La versión más reciente del módulo de Azure PowerShell. Consulte Instalación del
módulo de Azure PowerShell.

de almacenamiento, que son construcciones de administración que representan un
grupo compartido de almacenamiento en el que puede implementar varios
recursos compartidos de archivos u otros recursos de almacenamiento. Obtenga
más información sobre cómo implementar cuentas de almacenamiento y recursos
compartidos de archivos de Azure en Creación de un recurso compartido de
archivos de Azure.
Una red virtual con un punto de conexión privado para la cuenta de

almacenamiento que contiene el recurso compartido de archivos de Azure que
quiere montar localmente. Para más información sobre cómo crear un punto de
conexión privado, consulte Configuración de puntos de conexión de red de Azure
Files.
Debe crear una subred de puerta de enlace en la red virtual. Para crear una subred
de puerta de enlace, inicie sesión en Azure Portal, vaya a la red virtual, seleccione
Configuración> Subredes, y después seleccione +Subred de puerta de enlace. Al
crear la subred de puerta de enlace, especifique el número de direcciones IP que
contiene la subred. El número de direcciones IP que se necesitan depende de la
configuración de puerta de enlace de VPN que se desea crear. Es mejor especificar
/27 o mayor (/26, /25, etc.) para permitir suficientes direcciones IP para cambios
futuros, como agregar una puerta de enlace de ExpressRoute.
Recopilación de información del entorno

Antes de configurar la VPN de punto a sitio, debe recopilar información sobre su
entorno.
Portal
Para configurar una VPN de punto a sitio mediante Azure Portal, deberá conocer el
nombre del grupo de recursos, el nombre de la red virtual, el nombre de la subred
de puerta de enlace y el nombre de la cuenta de almacenamiento.
Creación de certificados raíz para la
autenticación de VPN
Para que las conexiones VPN desde las máquinas Windows locales se autentiquen para
acceder a la red virtual, debe crear dos certificados:
1. Un certificado raíz, que se proporcionará a la puerta de enlace de máquina virtual

2. Un certificado de cliente, que se firmará con el certificado raíz
Puede usar un certificado raíz que se generó con una solución empresarial o puede
generar un certificado autofirmado. Si usa una solución empresarial, adquiera el archivo
.cer para el certificado raíz de la organización de TI.
Si no usa una solución de certificado empresarial, cree un certificado raíz autofirmado

mediante este script de PowerShell. Creará el certificado de cliente después de
implementar la puerta de enlace de red virtual. Si es posible, deje abierta la sesión de
PowerShell para que no necesite volver a definir las variables al crear el certificado de
cliente más adelante en este artículo.
） Importante
Ejecute este script de PowerShell como administrador desde una máquina local que
ejecute Windows 10/Windows Server 2016 o posterior. No ejecute el script desde
una máquina virtual o Cloud Shell en Azure.
PowerShell
$rootcertname = "CN=P2SRootCert"
$certLocation = "Cert:\CurrentUser\My"
$vpnTemp = "C:\vpn-temp\"
$exportedencodedrootcertpath = $vpnTemp + "P2SRootCertencoded.cer"
$exportedrootcertpath = $vpnTemp + "P2SRootCert.cer"
if (-Not (Test-Path $vpnTemp)) {

New-Item -ItemType Directory -Force -Path $vpnTemp | Out-Null
}
if ($PSVersionTable.PSVersion -ge [System.Version]::new(6, 0)) {

Install-Module WindowsCompatibility
Import-WinModule PKI
}
$rootcert = New-SelfSignedCertificate `
-Type Custom `
-KeySpec Signature `
-Subject $rootcertname `
-KeyExportPolicy Exportable `
-HashAlgorithm sha256 `
-KeyLength 2048 `
-CertStoreLocation $certLocation `
-KeyUsageProperty Sign `
-KeyUsage CertSign
Export-Certificate `
-Cert $rootcert `
-FilePath $exportedencodedrootcertpath `
-NoClobber | Out-Null
certutil -encode $exportedencodedrootcertpath $exportedrootcertpath | Out-

Null
$rawRootCertificate = Get-Content -Path $exportedrootcertpath
[System.String]$rootCertificate = ""
foreach($line in $rawRootCertificate) {
if ($line -notlike "*Certificate*") {
$rootCertificate += $line
}
}
Implementación de puerta de enlace de red

virtual
La puerta de enlace de red virtual de Azure es el servicio al que se conectarán las
máquinas Windows locales. Si aún no lo ha hecho, debe crear una subred de puerta de
enlace en la red virtual antes de implementar la puerta de enlace de red virtual.
La implementación de una puerta de enlace de red virtual requiere dos componentes

básicos:
1. Una IP pública que identificará la puerta de enlace a los clientes dondequiera que
estén en el mundo
2. El certificado raíz que creó en el paso anterior, que se usará para autenticar a los
clientes
Puede usar Azure Portal o Azure PowerShell para implementar la puerta de enlace de
red virtual. La implementación puede tardar hasta 45 minutos en completarse.
Portal
Para implementar una puerta de enlace de red virtual mediante Azure Portal, siga
estas instrucciones.
2. En Buscar recursos, servicios y documentos, escriba puertas de enlace de red

virtual. Busque Puertas de enlace de red virtual en los resultados de búsqueda
de Marketplace y selecciónelo.
3. Seleccione + Crear para crear una nueva puerta de enlace de red virtual.

Suscripción: seleccione la suscripción que desea usar en la lista

desplegable.
Grupo de recursos: esta configuración se rellena automáticamente
cuando selecciona la red virtual en esta página.
Name: Asigne un nombre a la puerta de enlace. Asignar nombre a la
puerta de enlace no es lo mismo que asignar nombre a una subred de
puerta de enlace. Este es el nombre del objeto de puerta de enlace que
va a crear.
Región: Seleccione la región en la que quiere crear este recurso. La
región de la puerta de enlace debe ser la misma que la red virtual.
Tipo de puerta de enlace: Seleccione VPN. Las puertas de enlace VPN
usan el tipo de puerta de enlace de red virtual VPN.
SKU: seleccione el SKU de puerta de enlace que admita las características
que desea usar en la lista desplegable. Consulte SKU de puerta de
enlace. No use la SKU básica, ya que no admite la autenticación IKEv2.
Generación: seleccione la generación que desea usar. Se recomienda
usar una SKU de segunda generación. Consulte SKU de puertas de
enlace para más información.
Red virtual: En el menú desplegable, seleccione la red virtual a la que
quiera agregar esta puerta de enlace. Si no puede ver la red virtual para
la que desea crear una puerta de enlace, asegúrese de seleccionar la
suscripción y la región correctas.
Subred: este campo debería estar atenuado y enumerar el nombre de la
subred de la puerta de enlace que ha creado, junto con su intervalo IP de
direcciones. Si, en cambio, ve un campo Intervalo de direcciones de
subred de puerta de enlace con un cuadro de texto, es que aún no ha
configurado una subred de puerta de enlace (consulte Requisitos
previos).
5. Especifique los valores de la dirección IP pública que se asocia a la puerta de

enlace de red virtual. La dirección IP pública se asigna a este objeto cuando se
crea la puerta de enlace de red virtual. La única vez que la dirección IP pública
principal cambia es cuando la puerta de enlace se elimina y se vuelve a crear.
No cambiará al modificar el tamaño, restablecer o realizar otro tipo de
mantenimiento interno o actualizaciones.
Dirección IP pública: Mantenga la opción Crear nueva seleccionada.

Nombre de dirección IP pública: En el cuadro de texto, escriba un
nombre para la dirección IP pública.
SKU de dirección IP pública: la configuración se selecciona
automáticamente.
Asignación: por lo general, la asignación se selecciona automáticamente
y puede ser dinámica o estática.
Habilitar el modo activo/activo: seleccione Deshabilitado. Habilite esta
configuración solo si va a crear una configuración de puerta de enlace
activa-activa.
Configurar BGP: Seleccione Deshabilitado, a menos que su
configuración requiera específicamente este valor. Si necesita este valor
de configuración, el valor predeterminado del ASN es 65515, aunque
esto se puede cambiar.

validación, seleccione Crear para implementar la puerta de enlace de red
virtual. La implementación puede tardar hasta 45 minutos en completarse.
7. Una vez finalizada la implementación, seleccione Ir al recurso.
8. En el panel izquierdo, seleccione Configuración> Configuración de punto a

sitio y después seleccione Configurar ahora. Debería ver la página
configuración de punto a sitio.
Grupo de direcciones: agregue el intervalo de direcciones IP privadas

que quiera usar. Los clientes VPN reciben de forma dinámica una
dirección IP del intervalo que especifique. La máscara de subred mínima
es de 29 bits para la configuración activa/pasiva, y de 28 bits para la
configuración activa/activa.
Tipo de túnel: especifique el tipo de túnel que quiere usar. Los equipos
que se conectan a través del cliente VPN nativo de Windows probarán
primero IKEv2. Si eso no conecta, vuelven a SSTP (si selecciona tanto
IKEv2 como SSTP en la lista desplegable). Si selecciona el tipo de túnel
OpenVPN, puede conectarse mediante un cliente OpenVPN o el cliente
VPN de Azure.
Tipo de autenticación: especifique el tipo de autenticación que desea
usar (en este caso, elija Certificado de Azure).
Nombre del certificado raíz: el nombre de archivo del certificado raíz
(archivo.cer).
Datos de certificado público: abra el certificado raíz con el Bloc de notas
y copie o pegue los datos del certificado público en este campo de texto.
Si usó el script de PowerShell en este artículo para generar un certificado
raíz autofirmado, se ubicará en C:\vpn-temp . Asegúrese de pegar solo el
texto que está entre -----BEGIN CERTIFICATE----- y -----END
CERTIFICATE-----. No incluya espacios ni caracteres adicionales.
７ Nota
Si no ve el tipo de túnel o el tipo de autenticación, la puerta de enlace

usa la SKU básica. La SKU básica no admite la autenticación de IKEv2. Si
quiere usar IKEv2, debe eliminar y volver a crear la puerta de enlace con
una SKU de puerta de enlace diferente.
9. Seleccione Guardar en la parte superior de la página para guardar todas las

opciones de configuración y cargar la información de clave pública del
certificado raíz en Azure.
Creación del certificado de cliente

Cada equipo cliente que se conecta a una red virtual con una conexión de punto a sitio
debe tener instalado un certificado de cliente. Genere el certificado de cliente a partir
del certificado raíz e instálelo en cada equipo cliente. Si no instala ningún certificado de
cliente válido, la autenticación no podrá realizarse cuando el cliente trate de conectarse.
Puede crear un certificado de cliente a partir de un certificado raíz que se generó con
una solución empresarial o puede crear un certificado de cliente a partir de un
certificado raíz autofirmado.
Creación de un certificado de cliente mediante una

solución empresarial
Si usa una solución de certificación de empresa, genere un certificado de cliente con el
formato de valor de nombre común name@yourdomain.com. Use este formato en lugar
de domain name\username. Asegúrese de que el certificado de cliente se base en la
plantilla de certificado de usuario que tenga Autenticación de cliente como primer
elemento de la lista de usuarios. Para comprobar el certificado, haga doble clic en él y
vea Uso mejorado de clave en la pestaña Detalles.
Creación de un certificado de cliente a partir de un

certificado raíz autofirmado
Si no usa una solución de certificado empresarial, puede usar PowerShell para crear un
certificado de cliente con el URI de la puerta de enlace de red virtual. Este certificado se
firmará con el certificado raíz que creó anteriormente. Si genera un certificado de cliente
desde un certificado raíz autofirmado, este se instala automáticamente en el equipo que
utilizó para generarlo.
Si desea instalar un certificado de cliente en otro equipo cliente, exporte el certificado

como un archivo .pfx, junto con toda la cadena de certificados. De esta forma, creará un
archivo .pfx que contiene la información del certificado raíz necesaria para que el cliente
se autentique. Para exportar el certificado raíz autofirmado como archivo .pfx, seleccione
el certificado raíz y use los mismos pasos descritos en Exportación del certificado de
cliente.
Identificación del certificado raíz autofirmado

Si usa la misma sesión de PowerShell que usó para crear el certificado raíz autofirmado,
puede ir directamente a Generar un certificado de cliente.
Si no es así, siga estos pasos para identificar el certificado raíz autofirmado instalado en
el equipo.
1. Obtenga una lista de los certificados instalados en el equipo.
PowerShell
Get-ChildItem -Path "Cert:\CurrentUser\My"
2. Busque el nombre del firmante de la lista devuelta y, luego, copie la huella digital
que se encuentra junto a él en un archivo de texto. En el ejemplo siguiente, hay
dos certificados. El nombre CN es el nombre del certificado raíz autofirmado a
partir del que va a generar un certificado secundario. En este caso, se denomina
P2SRootCert.
Thumbprint Subject
---------- -------
AED812AD883826FF76B4D1D5A77B3C08EFA79F3F CN=P2SChildCert4
7181AA8C1B4D34EEDB2F3D3BEC5839F3FE52D655 CN=P2SRootCert
3. Declare una variable para el certificado raíz con la huella digital del paso anterior.
Reemplace THUMBPRINT por la huella digital del certificado raíz desde el que
desea generar un certificado de cliente.
PowerShell
$rootcert = Get-ChildItem -Path "Cert:\CurrentUser\My\<THUMBPRINT>"
Por ejemplo, con la huella digital de P2SRootCert en el paso anterior, el comando

tiene el siguiente aspecto:
PowerShell
$rootcert = Get-ChildItem -Path

"Cert:\CurrentUser\My\7181AA8C1B4D34EEDB2F3D3BEC5839F3FE52D655"
Generación de un certificado de cliente

Use el cmdlet de PowerShell New-AzVpnClientConfiguration para generar un certificado
de cliente. Si no usa la misma sesión de PowerShell que usó para crear el certificado raíz
autofirmado, deberá identificar el certificado raíz autofirmado como se describe en la
sección anterior. Antes de ejecutar el script, reemplace <resource-group-name> por el
nombre del grupo de recursos y <vpn-gateway-name> por el nombre de la puerta de
enlace de red virtual que acaba de implementar.
） Importante
Ejecute este script de PowerShell como administrador desde la máquina Windows

local que desea conectar al recurso compartido de archivos de Azure. El equipo
debe ejecutar Windows 10/Windows Server 2016 o posterior. No ejecute el script
desde Cloud Shell en Azure. Asegúrese de iniciar sesión en su cuenta de Azure
antes de ejecutar el script ( Connect-AzAccount ).
PowerShell
$clientcertpassword = "1234"
$resourceGroupName = "<resource-group-name>"
$vpnName = "<vpn-gateway-name>"
$vpnTemp = "C:\vpn-temp\"
$vpnClientConfiguration = New-AzVpnClientConfiguration `
-ResourceGroupName $resourceGroupName `
-Name $vpnName `
-AuthenticationMethod EAPTLS
Invoke-WebRequest `
-Uri $vpnClientConfiguration.VpnProfileSASUrl `
-OutFile "$vpnTemp\vpnclientconfiguration.zip"
Expand-Archive `
-Path "$vpnTemp\vpnclientconfiguration.zip" `
-DestinationPath "$vpnTemp\vpnclientconfiguration"
$vpnGeneric = "$vpnTemp\vpnclientconfiguration\Generic"
$vpnProfile = ([xml](Get-Content -Path
"$vpnGeneric\VpnSettings.xml")).VpnProfile
$exportedclientcertpath = $vpnTemp + "P2SClientCert.pfx"

$clientcertname = "CN=" + $vpnProfile.VpnServer
$clientcert = New-SelfSignedCertificate `
-Type Custom `
-DnsName $vpnProfile.VpnServer `
-Subject $clientcertname `
-KeyLength 2048 `
-Signer $rootcert `
-TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")
$mypwd = ConvertTo-SecureString -String $clientcertpassword -Force -

AsPlainText
Export-PfxCertificate `
-FilePath $exportedclientcertpath `
-Password $mypwd `
-Cert $clientcert | Out-Null
Configuración del cliente VPN

La puerta de enlace de red virtual de Azure creará un paquete descargable con los
archivos de configuración necesarios para inicializar la conexión VPN en la máquina
Windows local. El paquete de configuración contiene la configuración específica de la
puerta de enlace de VPN que ha creado. Si realiza cambios en la puerta de enlace, como
cambiar un tipo de túnel, un certificado o un tipo de autenticación, deberá generar otro
paquete de configuración de perfil de cliente VPN e instalarlo en cada cliente. De lo
contrario, es posible que los clientes VPN no puedan conectarse.
Configurará la conexión VPN con la característica Always On VPN incorporada en

Windows 10 y Windows Server 2016. Este paquete también contiene archivos
ejecutables que configurarán el cliente VPN de Windows heredado, si lo desea. En esta
guía se usa Always On para VPN en lugar del cliente VPN heredado de Windows, ya que
el cliente VPN de Always On le permite conectarse o desconectarse de la VPN de Azure
sin tener permisos de administrador en la máquina.
Portal
Instalación del certificado de cliente

Para instalar el certificado de cliente necesario para la autenticación en la puerta de
enlace de red virtual, siga estos pasos en el equipo cliente.
1. Una vez que se exporte el certificado de cliente, busque y copie el archivo .pfx
en el equipo cliente.
2. En el equipo cliente, haga doble clic en el archivo .pfx para instalarlo. Deje
Ubicación del almacén como Usuario actual y seleccione Siguiente.
3. En la página File to import (Archivo para importar), no haga ningún cambio.
Seleccione Siguiente.
4. En la página Protección de clave privada, escriba la contraseña del certificado
o compruebe que la entidad de seguridad sea correcta y seleccione Siguiente.
5. En la página Almacén de certificados, deje la ubicación predeterminada y
seleccione Siguiente.
6. Seleccione Finalizar. En la advertencia de seguridad para la instalación de
certificados, seleccione Sí. Puede seleccionar con total tranquilidad el valor
"Sí" en esta advertencia de seguridad, ya que ha generado el certificado.
7. El certificado se importó correctamente.
Instalación del cliente VPN

Esta sección le ayuda a configurar el cliente VPN nativo que forma parte del sistema
operativo Windows para conectarse a la red virtual (IKEv2 y SSTP). Esta
configuración no requiere software cliente adicional.
Visualización de los archivos de configuración
En el equipo cliente, vaya a C:\vpn-temp y abra la carpeta vpnclientconfiguration
para ver las subcarpetas siguientes:
WindowsAmd64 y WindowsX86, que contienen los paquetes del instalador

de Windows de 64 y 32 bits, respectivamente. El paquete del instalador
WindowsAmd64 es para todos los clientes de Windows de 64 bits, no solo de
AMD.
La carpeta Genérico contiene información general que usará para crear su
propia configuración de cliente VPN, La carpeta Genérico se proporciona si se
ha configurado la opción IKEv2 o SSTP + IKEv2 en la puerta de enlace. Si solo
se ha configurado SSTP, la carpeta Genérico no aparece.
Configuración del perfil del cliente VPN

Puede utilizar el mismo paquete de configuración de cliente VPN en todos los
equipos cliente Windows, siempre que la versión coincida con la arquitectura del
cliente.
７ Nota
Debe tener derechos de administrador en el equipo cliente windows desde el

que desea conectarse para ejecutar el paquete del instalador.
1. Seleccione los archivos de configuración de cliente VPN que correspondan a

la arquitectura del equipo Windows. Para una arquitectura de procesador de
64 bits, elija el paquete del instalador de VpnClientSetupAmd64 . Para una
arquitectura de procesador de 32 bits, elija el paquete del instalador de
VpnClientSetupX86 .
2. Haga doble clic en el paquete para instalarlo. Si ve una ventana emergente de

SmartScreen, seleccione Más información y, después, Ejecutar de todas
formas.
3. Conéctese a la VPN. Vaya a Configuración de VPN y busque la conexión VPN

que creó. Tiene el mismo nombre que su red virtual. Seleccione Conectar. Es
posible que aparezca un mensaje emergente. Seleccione Continuar para usar
privilegios elevados.
4. En la página Estado de conexión, seleccione Conectar para iniciar la conexión.

Si ve una pantalla para Seleccionar certificado , compruebe que el certificado
de cliente que se muestra es el que desea utilizar para conectarse. Si no es así,
use la flecha de lista desplegable para seleccionar el certificado correcto y,
luego, seleccione Aceptar.

de Azure
Ahora que ha configurado la VPN de punto a sitio, puede usarla para montar el recurso
compartido de archivos de Azure en una máquina local.
Portal
Para montar el recurso compartido de archivos mediante la clave de la cuenta de

almacenamiento, abra un símbolo del sistema de Windows y ejecute el siguiente
comando. Reemplace <YourStorageAccountName> , <FileShareName> y
<YourStorageAccountKey> con sus propios valores. Si Z ya está en uso, reemplácelo
por una letra de unidad disponible. Para encontrar la clave de la cuenta de

almacenamiento en Azure Portal, vaya a la cuenta de almacenamiento y seleccione
Seguridad y redes>Claves de acceso.
net use Z: \\<YourStorageAccountName>.file.core.windows.net\

<FileShareName> /user:localhost\<YourStorageAccountName>
<YourStorageAccountKey>
Rotación del certificado raíz de VPN

Si es necesario rotar un certificado raíz debido a la expiración o a nuevos requisitos,
puede agregar un nuevo certificado raíz a la puerta de enlace de red virtual existente sin
necesidad de volver a implementar la puerta de enlace de red virtual. Después de
agregar el certificado raíz mediante el siguiente script, deberá volver a crear el
certificado de cliente VPN.
Reemplace <resource-group-name> , <desired-vpn-name-here> y <new-root-cert-name>

por sus propios valores y después ejecute el script.
PowerShell
#Creating the new Root Certificate
$ResourceGroupName = "<resource-group-name>"
$vpnName = "<desired-vpn-name-here>"
$NewRootCertName = "<new-root-cert-name>"
$rootcertname = "CN=$NewRootCertName"
$date = get-date -Format "MM_yyyy"
$vpnTemp = "C:\vpn-temp_$date\"
$exportedencodedrootcertpath = $vpnTemp + "P2SRootCertencoded.cer"
$exportedrootcertpath = $vpnTemp + "P2SRootCert.cer"
if (-Not (Test-Path $vpnTemp)) {

New-Item -ItemType Directory -Force -Path $vpnTemp | Out-Null
}
$rootcert = New-SelfSignedCertificate `
-Type Custom `
-Subject $rootcertname `
-KeyLength 2048 `
-KeyUsageProperty Sign `
-KeyUsage CertSign
Export-Certificate `
-Cert $rootcert `
-FilePath $exportedencodedrootcertpath `
-NoClobber | Out-Null
certutil -encode $exportedencodedrootcertpath $exportedrootcertpath | Out-

Null
$rawRootCertificate = Get-Content -Path $exportedrootcertpath
[System.String]$rootCertificate = ""
foreach($line in $rawRootCertificate) {
if ($line -notlike "*Certificate*") {
$rootCertificate += $line
}
}
#Fetching gateway details and adding the newly created Root Certificate.
$gateway = Get-AzVirtualNetworkGateway -Name $vpnName -ResourceGroupName
$ResourceGroupName
Add-AzVpnClientRootCertificate `
-PublicCertData $rootCertificate `
-ResourceGroupName $ResourceGroupName `
-VirtualNetworkGatewayName $gateway `
-VpnClientRootCertificateName $NewRootCertName
Consulte también
Configuración de los ajustes del servidor para conexiones VPN Gateway P2S
Consideraciones de red para el acceso directo a los recursos compartidos de
archivos de Azure
Configure una VPN de punto a sitio (P2S) en Linux para su uso con Azure Files
Configuración de una VPN de sitio a sitio (S2S) para su uso con Azure Files
Configuración de una VPN de punto a
sitio (P2S) en Linux para su uso con
Azure Files
Artículo • 10/03/2023
Puede usar una conexión VPN de punto a sitio (P2S) para montar los recursos
compartidos de archivos de Azure desde fuera de Azure, sin necesidad de enviar los
datos por la red Internet abierta. Una conexión VPN de punto a sitio es una conexión
VPN entre Azure y un cliente individual. Para usar una conexión VPN de punto a sitio
con Azure Files, se debe configurar una conexión VPN de punto a sitio para cada cliente
que quiera conectarse. Si tiene muchos clientes que necesitan conectarse a sus recursos
compartidos de archivos de Azure desde la red local, puede usar una conexión VPN de
sitio a sitio (S2S) en lugar de una conexión de punto a sitio para cada cliente. Para
obtener más información, consulte Configuración de una VPN de sitio a sitio para su uso
con Azure Files.
Se recomienda que lea Introducción a las redes de Azure Files antes de continuar con
este artículo para obtener una descripción completa de las opciones de red disponibles
para Azure Files.
En este artículo se detallan los pasos para configurar una VPN de punto a sitio en Linux
para montar recursos compartidos de archivos de Azure directamente en el entorno
local.
Se aplica a
Prerrequisitos
La versión más reciente de la CLI de Azure. Para más información sobre cómo
instalar la CLI de Azure, consulte Instalación de la CLI de Azure PowerShell y
seleccione el sistema operativo. Si prefiere usar el módulo de Azure PowerShell en
Linux, puede hacerlo. Sin embargo, las instrucciones siguientes son para la CLI de
Azure.

de almacenamiento, que son construcciones que representan un grupo
compartido de almacenamiento en el que puede implementar varios recursos
compartidos de archivos u otros recursos de almacenamiento, como contenedores
de blobs o colas. Puede encontrar más información sobre cómo implementar
cuentas de almacenamiento y recursos compartidos de archivos de Azure en
Creación de un recurso compartido de archivos de Azure.
Un punto de conexión privado para la cuenta de almacenamiento que contiene el

recurso compartido de archivos de Azure que quiere montar localmente. Para más
información sobre cómo crear un punto de conexión privado, consulte
Configuración de puntos de conexión de red de Azure Files.
Instalación del software necesario

La puerta de enlace de red virtual de Azure puede ofrecer conexiones VPN mediante
varios protocolos VPN, entre los que se incluyen IPsec y OpenVPN. En este artículo se
muestra cómo usar IPsec y se usa el paquete strongSwan para proporcionar
compatibilidad con Linux.
Comprobada con Ubuntu 18.10.
Bash
sudo apt update

sudo apt install strongswan strongswan-pki libstrongswan-extra-plugins curl
libxml2-utils cifs-utils unzip
INSTALL_DIR="/etc/"
Si se produce un error en la instalación o se produce un error como EAP_IDENTITY no

se admite, enviar EAP_NAK, es posible que tenga que instalar complementos
adicionales:
Bash
sudo apt install -y libcharon-extra-plugins

Implementar una red virtual
Para acceder al recurso compartido de archivos de Azure y a otros recursos de Azure
desde el entorno local a través de una VPN de punto a sitio, debe crear una red virtual o
VNet. La conexión VPN de punto a sitio que creará automáticamente es un puente entre
la máquina Linux local y esta red virtual de Azure.
El siguiente script creará una red virtual de Azure con tres subredes: una para el punto
de conexión de servicio de la cuenta de almacenamiento, otra para el punto de
conexión privado de la cuenta de almacenamiento (que es necesaria para acceder a la
cuenta de almacenamiento local sin crear un enrutamiento personalizado para la
dirección IP pública de la cuenta de almacenamiento que puede cambiar) y otra para la
puerta de enlace de red virtual que proporciona el servicio VPN.
No olvide reemplazar <region> , <resource-group> y <desired-vnet-name> por los

valores correctos para su entorno.
Bash
REGION="<region>"
RESOURCE_GROUP_NAME="<resource-group>"
VIRTUAL_NETWORK_NAME="<desired-vnet-name>"
VIRTUAL_NETWORK=$(az network vnet create \

--name $VIRTUAL_NETWORK_NAME \
--location $REGION \
--address-prefixes "192.168.0.0/16" \
--query "newVNet.id" | tr -d '"')
SERVICE_ENDPOINT_SUBNET=$(az network vnet subnet create \

--vnet-name $VIRTUAL_NETWORK_NAME \
--name "ServiceEndpointSubnet" \
--service-endpoints "Microsoft.Storage" \
--query "id" | tr -d '"')
PRIVATE_ENDPOINT_SUBNET=$(az network vnet subnet create \

--name "PrivateEndpointSubnet" \
GATEWAY_SUBNET=$(az network vnet subnet create \

--name "GatewaySubnet" \
Creación de certificados para la autenticación

de VPN
Para que las conexiones VPN de las máquinas Linux locales se autentiquen para acceder
a la red virtual, debe crear dos certificados: un certificado raíz, que se proporcionará a la
puerta de enlace de máquina virtual, y un certificado de cliente, que se firmará con el
certificado raíz. El siguiente script crea los certificados necesarios.
Bash
ROOT_CERT_NAME="P2SRootCert"
USERNAME="client"
PASSWORD="1234"
mkdir temp
cd temp
sudo ipsec pki --gen --outform pem > rootKey.pem

sudo ipsec pki --self --in rootKey.pem --dn "CN=$ROOT_CERT_NAME" --ca --
outform pem > rootCert.pem
ROOT_CERTIFICATE=$(openssl x509 -in rootCert.pem -outform der | base64 -w0 ;

echo)
sudo ipsec pki --gen --size 4096 --outform pem > "clientKey.pem"
sudo ipsec pki --pub --in "clientKey.pem" | \
sudo ipsec pki \
--issue \
--cacert rootCert.pem \
--cakey rootKey.pem \
--dn "CN=$USERNAME" \
--san $USERNAME \
--flag clientAuth \
--outform pem > "clientCert.pem"
openssl pkcs12 -in "clientCert.pem" -inkey "clientKey.pem" -certfile

rootCert.pem -export -out "client.p12" -password "pass:$PASSWORD"
Implementación de puerta de enlace de red

virtual
La puerta de enlace de red virtual de Azure es el servicio al que se conectarán las
máquinas Linux locales. La implementación de este servicio requiere dos componentes
básicos: una dirección IP pública que identificará la puerta de enlace para los clientes
dondequiera que se encuentren en el mundo y un certificado raíz creado anteriormente
que se usará para autenticar a los clientes.
No olvide reemplazar <desired-vpn-name-here> por el nombre que quiera para estos

recursos.
７ Nota
La implementación de una puerta de enlace de red virtual de Azure puede tardar

hasta 45 minutos. Aunque este recurso va a implementarse, el script de Bash se
bloqueará para que se complete la implementación.
Las conexiones P2S IKEv2/OpenVPN no son compatibles con la SKU básica. Este
script usa la SKU VpnGw1 para la puerta de enlace de red virtual, según
corresponda.
Azure CLI
VPN_NAME="<desired-vpn-name-here>"
PUBLIC_IP_ADDR_NAME="$VPN_NAME-PublicIP"
PUBLIC_IP_ADDR=$(az network public-ip create \

--name $PUBLIC_IP_ADDR_NAME \
--sku "Basic" \
--allocation-method "Dynamic" \
--query "publicIp.id" | tr -d '"')
az network vnet-gateway create \

--name $VPN_NAME \
--vnet $VIRTUAL_NETWORK_NAME \
--public-ip-addresses $PUBLIC_IP_ADDR \
--sku "VpnGw1" \
--gateway-typ "Vpn" \
--vpn-type "RouteBased" \
--client-protocol "IkeV2" > /dev/null
az network vnet-gateway root-cert create \

--gateway-name $VPN_NAME \
--name $ROOT_CERT_NAME \
--public-cert-data $ROOT_CERTIFICATE \
--output none
Configuración del cliente VPN

La puerta de enlace de red virtual de Azure creará un paquete descargable con los
archivos de configuración necesarios para inicializar la conexión VPN en la máquina
Linux local. El siguiente script colocará los certificados creados en el lugar correcto y
configurará el archivo ipsec.conf con los valores correctos del archivo de configuración
en el paquete descargable.
Azure CLI
VPN_CLIENT=$(az network vnet-gateway vpn-client generate \

--name $VPN_NAME \
--authentication-method EAPTLS | tr -d '"')
curl $VPN_CLIENT --output vpnClient.zip

unzip vpnClient.zip
VPN_SERVER=$(xmllint --xpath "string(/VpnProfile/VpnServer)"

Generic/VpnSettings.xml)
VPN_TYPE=$(xmllint --xpath "string(/VpnProfile/VpnType)"
Generic/VpnSettings.xml | tr '[:upper:]' '[:lower:]')
ROUTES=$(xmllint --xpath "string(/VpnProfile/Routes)"
Generic/VpnSettings.xml)
sudo cp "${INSTALL_DIR}ipsec.conf" "${INSTALL_DIR}ipsec.conf.backup"

sudo cp "Generic/VpnServerRoot.cer_0" "${INSTALL_DIR}ipsec.d/cacerts"
sudo cp "${USERNAME}.p12" "${INSTALL_DIR}ipsec.d/private"
sudo tee -a "${installDir}ipsec.conf" <<EOF

conn $VIRTUAL_NETWORK_NAME
keyexchange=$VPN_TYPE
type=tunnel
leftfirewall=yes
left=%any
leftauth=eap-tls
leftid=%client
right=$vpnServer
rightid=%$vpnServer
rightsubnet=$routes
leftsourceip=%config
auto=add
EOF
echo ": P12 client.p12 '$PASSWORD'" | sudo tee -a

"${INSTALL_DIR}ipsec.secrets" > /dev/null
sudo ipsec restart
sudo ipsec up $VIRTUAL_NETWORK_NAME

de Azure
Ahora que ha configurado la VPN de punto a sitio, puede montar el recurso compartido
de archivos de Azure. Consulte Montaje de un recurso compartido de archivos SMB en
Linux o Montaje de un recurso compartido de archivos NFS en Linux.
Consulte también
Introducción a las redes de Azure Files
Configuración de una VPN de punto a sitio (P2S) en Windows para su uso con
Azure Files
Configuración de una VPN de sitio a sitio (S2S) para su uso con Azure Files
Introducción: autenticación de
Active Directory Domain Services local
en SMB para recursos compartidos de
archivos de Azure
Artículo • 21/11/2023
Azure Files admite la autenticación basada en identidades para recursos compartidos de

archivos de Windows a través del Bloque de mensajes del servidor (SMB) con el
protocolo de autenticación Kerberos mediante los métodos siguientes:

Microsoft Entra Kerberos para identidades de usuario híbrido
Se recomienda encarecidamente consultar la sección Funcionamiento para seleccionar

el origen de AD adecuado para la autenticación. La instalación es diferente en función
del servicio de dominio que se elija. Este artículo se centra en la habilitación y
configuración de Azure AD DS local para la autenticación con recursos compartidos de
archivos de Azure.
Si no está familiarizado con Azure Files, se recomienda que lea la guía de planeamiento.
Se aplica a
Escenarios y restricciones admitidos

Las identidades de AD DS que se usen para la autenticación de AD DS local de
Azure Files deben sincronizarse con Microsoft Entra ID o usar un permiso de nivel
de recurso compartido predeterminado. La sincronización de hash de contraseña
es opcional.
Admite recursos compartidos de archivos de Azure administrados por Azure File
Sync.
Admite la autenticación Kerberos con AD y con cifrado AES 256 (recomendado) y
RC4-HMAC. Todavía no se admite el cifrado de Kerberos con AES 128.
Admite la experiencia de inicio de sesión único.
Solo se admite en clientes Windows que ejecutan versiones del sistema operativo
Windows 8/Windows Server 2012 o posteriores, o máquinas virtuales Linux
(Ubuntu 18.04+ o una máquina virtual RHEL o SLES equivalente) que se ejecutan
en Azure.
Solo se admite en el bosque de AD en el que está registrada la cuenta de
almacenamiento. Los usuarios que pertenecen a dominios diferentes dentro del
mismo bosque deben poder acceder al recurso compartido de archivos y a los
directorios o archivos subyacentes, siempre y cuando tengan los permisos
adecuados.
De forma predeterminada, solo se puede acceder a los recursos compartidos de
archivos de Azure con las credenciales de AD DS desde un solo bosque. Si necesita
acceso al recurso compartido de archivos de Azure desde otro bosque, asegúrese
de tener configurada la confianza de bosque adecuada. Para ver más detalles,
consulte Uso de Azure Files con varios bosques de Active Directory.
No se admite la asignación de permisos de nivel de recurso compartido a cuentas
de equipo (cuentas de máquina) con RBAC de Azure. Puede usar un permiso de
nivel de recurso compartido predeterminado para permitir que las cuentas de
equipo accedan al recurso compartido o considerar la posibilidad de usar una
cuenta de inicio de sesión del servicio en su lugar.
No admite la autenticación en recursos compartidos de archivos de Network File
System (NFS).
Al habilitar AD DS para recursos compartidos de archivos de Azure en SMB, las

máquinas unidas a AD DS pueden montar recursos compartidos de archivos de Azure
con sus credenciales de AD DS existentes. Esta funcionalidad se puede habilitar con un
entorno de AD DS hospedado en máquinas del entorno local o en una máquina virtual
(VM) en Azure.
Vídeos
Con el fin de ayudarle a configurar la autenticación basada en la identidad para algunos
casos de uso comunes, hemos publicado dos vídeos con una guía paso a paso para los
siguientes escenarios:
Reemplazo de servidores de archivos Uso de Azure Files como contenedor de
locales por Azure Files (incluida la perfiles para Azure Virtual Desktop (incluida
configuración en un vínculo privado para la la configuración de la autenticación de AD y
autenticación de archivos y AD) la configuración de FSLogix)
Requisitos previos
Antes de habilitar la autenticación de AD DS para los recursos compartidos de archivos
de Azure, asegúrese de que cumple los siguientes requisitos previos:
Seleccione o cree su entorno de AD DS y sincronícelo con Microsoft Entra ID

mediante la aplicación de sincronización de Microsoft Entra Connect local o
Microsoft Entra Connect Cloud Sync, un agente ligero que se puede instalar desde
el Centro de Administración de Microsoft Entra.
La característica se puede habilitar en un entorno de AD DS nuevo o existente. Las

identidades que se usen para el acceso deben sincronizarse con Microsoft Entra ID
o usar un permiso de nivel de recurso compartido predeterminado. El inquilino de
Microsoft Entra y el recurso compartido de archivos al que accede debe estar
asociado con la misma suscripción.
Unir una máquina local o una máquina virtual de Azure por dominio a un AD DS
local. Para información acerca de cómo unirse a un dominio, consulte Unión de un
equipo a un dominio.
Si una máquina no está unida a un dominio, todavía puede usar AD DS para la

autenticación si la máquina tiene conectividad de red con el controlador de
dominio de AD local y el usuario proporciona credenciales explícitas. Para más
información, consulte Montaje del recurso compartido de archivos desde una
máquina virtual no unida a un dominio o una máquina virtual unida a un dominio
de AD diferente.
Seleccione o cree una cuenta de almacenamiento de Azure. Para conseguir un

rendimiento óptimo, se recomienda implementar la cuenta de almacenamiento en
la misma región que el cliente desde el que vaya a acceder al recurso compartido.
A continuación, monte el recurso compartido de archivos de Azure con la clave de
la cuenta de almacenamiento. Al montar con la clave de la cuenta de
almacenamiento, se comprueba la conectividad.
Asegúrese de que la cuenta de almacenamiento que contiene los recursos

compartidos de archivos no esté aún configurada para la autenticación basada en
la identidad. Si ya hay un origen de AD habilitado en la cuenta de almacenamiento,
debe deshabilitarlo antes de habilitar AD DS local.
Si tiene problemas para conectarse a Azure Files, vea la herramienta de solución de

problemas publicada para solucionar los errores de montaje de Azure Files en
Windows .
Realice una configuración de red relevante antes de habilitar y configurar la

autenticación de AD DS en los recursos compartidos de archivos de Azure.
Consulte Consideraciones de redes para Azure Files para obtener más información.
La autenticación de Azure Files con AD DS está disponible en todas las regiones
públicas, en China y en las de Azure Government .
Información general
Si planea habilitar configuraciones de red en el recurso compartido de archivos, se
recomienda que lea el artículo sobre consideraciones de redes y que complete la
configuración relacionada antes de habilitar la autenticación de AD DS.
Habilitar la autenticación de AD DS para los recursos compartidos de archivos de Azure

le permite autenticarse en los recursos compartidos de archivos de Azure con las
credenciales de AD DS local. Además, le permite administrar mejor los permisos para
permitir el control de acceso granular. Hacer esto requiere la sincronización de
identidades de AD DS local con Microsoft Entra ID mediante la aplicación de
sincronización de Microsoft Entra local o Microsoft Entra Connect Cloud Sync, un agente
ligero que se puede instalar desde el Centro de Administración de Microsoft Entra. Debe
asignar permisos de nivel de recurso compartido a identidades híbridas sincronizadas
con Microsoft Entra ID al administrar el acceso de nivel de archivo o directorio mediante
listas ACL de Windows.
Siga estos pasos para configurar Azure Files para la autenticación de AD DS:
1. Habilitación de la autenticación con AD DS en la cuenta de almacenamiento

2. Asignación de permisos de nivel de recurso compartido a la identidad de Microsoft
Entra (usuario, grupo o entidad de servicio) que está sincronizada con la identidad
de AD de destino
3. Configuración de ACL de Windows en SMB para directorios y archivos
4. Monte un recurso compartido de archivos de Azure en una VM unida a su AD DS.
5. Actualice la contraseña de la identidad de la cuenta de almacenamiento en AD DS.
En el diagrama siguiente se ilustra el flujo de trabajo completo para habilitar la

autenticación de Azure AD DS a través de SMB para Azure Files.
Las identidades que se usan para acceder a los recursos compartidos de archivos de
Azure se deben sincronizar con Microsoft Entra ID para aplicar los permisos de archivo
de nivel de recurso compartido mediante el modelo de control de acceso basado en
roles de Azure (RBAC de Azure). También puede usar un permiso de nivel de recurso
compartido predeterminado. Se conservarán y aplicarán las DACL tipo Windows en
archivos o directorios transferidos desde servidores de archivos existentes. Esto ofrece
una perfecta integración con el entorno de AD DS de la empresa. A medida que
reemplaza los servidores de archivos locales por recursos compartidos de archivos de
Azure, los usuarios existentes pueden acceder a estos desde sus clientes actuales con
una experiencia de inicio de sesión único, sin ningún cambio en las credenciales en uso.
Pasos siguientes
Para empezar, debe habilitar la autenticación de AD DS para la cuenta de
almacenamiento.
Habilitación de la autenticación de
AD DS para recursos compartidos de
archivos de Azure
Artículo • 19/10/2023
En este artículo se describe el proceso para habilitar la autenticación de Active Directory

Domain Services (AD DS) en la cuenta de almacenamiento con el fin de usar
credenciales de Active Directory local (AD) para autenticarse en recursos compartidos de
archivos de Azure.
） Importante
Antes de habilitar la autenticación de AD DS, asegúrese de comprender los

escenarios admitidos y los requisitos del artículo de información general y de
completar los requisitos previos necesarios. Si el entorno de Active Directory
abarca varios bosques, consulte Uso de Azure Files con varios bosques de Active
Directory.
Para habilitar la autenticación de AD DS en SMB para los recursos compartidos de

archivos de Azure, debe registrar la cuenta de almacenamiento de Azure en AD DS local
y, después, establecer las propiedades de dominio necesarias en la cuenta de
almacenamiento. Para registrar la cuenta de almacenamiento con AD DS, cree una
cuenta de equipo (o una cuenta de inicio de sesión en el servicio) que la represente en
AD DS. Este proceso se puede considerar como si se tratara de la creación de una
cuenta que representa un servidor local de archivos de Windows en AD DS. Cuando la
característica está habilitada en la cuenta de almacenamiento, se aplica a todos los
recursos compartidos de archivos nuevos y existentes de la cuenta.
Se aplica a

Opción 1 (recomendada): Uso del módulo de
PowerShell AzFilesHybrid
El módulo AzFilesHybrid de PowerShell proporciona cmdlets para implementar y
configurar Azure Files. Incluye cmdlets para unir cuentas de almacenamiento de
dominio a Active Directory local y configurar los servidores DNS. Los cmdlets realizan las
modificaciones necesarias y habilitan la característica automáticamente. Puesto que
algunas partes del cmdlet interactúan con la instancia local de AD DS, se explica lo que
hacen los cmdlets, para que pueda determinar si los cambios se alinean con las
directivas de cumplimiento y seguridad, y asegurarse de que tiene los permisos
adecuados para ejecutar los cmdlets. Aunque se recomienda usar el módulo
AzFilesHybrid, si no puede hacerlo, se proporcionan pasos manuales.
Prerrequisitos
Si no tiene instalado .NET Framework 4.7.2 o superior , instálelo ahora. Es
necesario para que el módulo AzFilesHybrid se importe correctamente.
Asegúrese de que tiene instalado Azure PowerShell (módulo Az) Az.Storage .
Debe tener al menos Az.PowerShell 2.8.0+ y Az.Storage 4.3.0+ para usar
AzFilesHybrid.
Instale el módulo PowerShell de Active Directory.
Descarga del módulo AzFilesHybrid

Descargue y descomprima la última versión del módulo AzFilesHybrid . Tenga en
cuenta que el cifrado Kerberos AES-256 se admite en la versión 0.2.2 y posteriores y es
el método de cifrado predeterminado a partir de la versión 0.2.5. Si ha habilitado la
característica con una versión de AzFilesHybrid anterior a la 0.2.2 y quiere actualizarla
para que admita el cifrado Kerberos AES-256, consulte Solución de problemas de
autenticación SMB de Azure Files.
Ejecución de Join-AzStorageAccount
El cmdlet Join-AzStorageAccount realiza la acción equivalente a la unión a un dominio
sin conexión en nombre de la cuenta de almacenamiento especificada. El script
siguiente usa este cmdlet para crear una cuenta de equipo en el dominio de AD. Si, por
cualquier motivo, no puede usar una cuenta de equipo, puede modificar el script para
crear una cuenta de inicio de sesión de servicio en su lugar. El uso del cifrado AES-256
con cuentas de inicio de sesión de servicio se admite a partir de la versión 0.2.5 de
AzFilesHybrid.
La cuenta de AD DS que crea el cmdlet representa la cuenta de almacenamiento. Si la
cuenta de AD DS se crea en una unidad organizativa (OU) que aplica la expiración de
contraseñas, debe actualizar la contraseña antes de su vigencia máxima. Si no actualiza
la contraseña de la cuenta antes de esa vigencia, se producirán errores de autenticación
al acceder a los recursos compartidos de archivos de Azure. Para saber cómo actualizar
la contraseña, consulte Actualización de la contraseña de la cuenta de AD DS.
） Importante
El cmdlet Join-AzStorageAccount creará una cuenta de AD para representar la

cuenta de almacenamiento (recurso compartido de archivos) en AD. Puede optar
por registrarla como una cuenta de equipo o una cuenta de inicio de sesión de
servicio; consulte Preguntas más frecuentes para obtener más información. Las
contraseñas de la cuenta de inicio de sesión de servicio pueden expirar en AD si
tienen establecida una antigüedad de expiración de contraseña predeterminada en
el dominio o la unidad organizativa de AD. Dado que los cambios de contraseña de
la cuenta de equipo los controla el equipo cliente y no AD, no expiran en AD,
aunque los equipos cliente cambian sus contraseñas de manera predeterminada
cada 30 días. Para ambos tipos de cuenta, se recomienda comprobar cuál es el
tiempo de expiración de la contraseña configurado y planificar la actualización de
la contraseña de la identidad de la cuenta de almacenamiento de la cuenta de AD
antes de la vigencia máxima de la contraseña. Puede considerar la posibilidad de
crear una unidad organizativa de AD en AD y deshabilitar la directiva de
expiración de contraseñas en las cuentas de equipo o las cuentas de inicio de
sesión de servicio, según corresponda.
Debe ejecutar el siguiente script en PowerShell 5.1 y en un dispositivo que esté unido
al dominio de su instancia de AD DS local, mediante las credenciales de AD DS local
que tengan permisos para crear una cuenta de equipo o una cuenta de inicio de
sesión del servicio en la instancia de AD de destino (como el dominio administración).
Para seguir el principio de privilegios mínimos, la credencial de AD DS local debe tener
los siguientes roles de Azure:
Lector en el grupo de recursos donde se encuentra la cuenta de almacenamiento

de destino.
Colaborador en la cuenta de almacenamiento que se va a unir a AD DS.
Si la cuenta usada para unirse a la cuenta de almacenamiento en AD DS es un

Propietario o Colaborador en la suscripción de Azure donde se encuentran los recursos
de destino, entonces esa cuenta ya está habilitada para realizar la unión y no se
requieren más asignaciones.
La credencial de AD DS también debe tener permisos para crear una cuenta de equipo o
una cuenta de inicio de sesión de servicio en la instancia de AD de destino. Reemplace
los valores de marcador de posición por los suyos propios antes de ejecutar el script.
PowerShell
# Change the execution policy to unblock importing AzFilesHybrid.psm1 module

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
# Navigate to where AzFilesHybrid is unzipped and stored and run to copy the
files into your path
.\CopyToPSPath.ps1
# Import AzFilesHybrid module

Import-Module -Name AzFilesHybrid
# Login to Azure using a credential that has either storage account owner or
contributor Azure role
# assignment. If you are logging into an Azure environment other than Public
(ex. AzureUSGovernment)
# you will need to specify that.
# See https://learn.microsoft.com/azure/azure-government/documentation-
government-get-started-connect-with-ps
# for more information.
Connect-AzAccount
# Define parameters
# $StorageAccountName is the name of an existing storage account that you
want to join to AD
# $SamAccountName is the name of the to-be-created AD object, which is used
by AD as the logon name
# for the object. It must be 20 characters or less and has certain character
restrictions.
# Make sure that you provide the SamAccountName without the trailing '$'
sign.
# See https://learn.microsoft.com/windows/win32/adschema/a-samaccountname
for more information.
$SubscriptionId = "<your-subscription-id-here>"
$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
$SamAccountName = "<sam-account-name-here>"
$DomainAccountType = "<ComputerAccount|ServiceLogonAccount>" # Default is
set as ComputerAccount
# If you don't provide the OU name as an input parameter, the AD identity
that represents the
# storage account is created under the root directory.
$OuDistinguishedName = "<ou-distinguishedname-here>"
# Specify the encryption algorithm used for Kerberos authentication. Using
AES256 is recommended.
$EncryptionType = "<AES256|RC4|AES256,RC4>"
# Select the target subscription for the current session

Select-AzSubscription -SubscriptionId $SubscriptionId
# Register the target storage account with your active directory environment
under the target OU
# (for example: specify the OU with Name as "UserAccounts" or
DistinguishedName as
# "OU=UserAccounts,DC=CONTOSO,DC=COM"). You can use this PowerShell cmdlet:
Get-ADOrganizationalUnit
# to find the Name and DistinguishedName of your target OU. If you are using
the OU Name, specify it
# with -OrganizationalUnitName as shown below. If you are using the OU
DistinguishedName, you can set it
# with -OrganizationalUnitDistinguishedName. You can choose to provide one
of the two names to specify
# the target OU. You can choose to create the identity that represents the
storage account as either a
# Service Logon Account or Computer Account (default parameter value),
depending on your AD permissions
# and preference. Run Get-Help Join-AzStorageAccountForAuth for more details
on this cmdlet.
Join-AzStorageAccount `
-ResourceGroupName $ResourceGroupName `
-StorageAccountName $StorageAccountName `
-SamAccountName $SamAccountName `
-DomainAccountType $DomainAccountType `
-OrganizationalUnitDistinguishedName $OuDistinguishedName `
-EncryptionType $EncryptionType
# You can run the Debug-AzStorageAccountAuth cmdlet to conduct a set of

basic checks on your AD configuration
# with the logged on AD user. This cmdlet is supported on AzFilesHybrid
v0.1.2+ version. For more details on
# the checks performed in this cmdlet, see Azure Files Windows
troubleshooting guide.
Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -
ResourceGroupName $ResourceGroupName -Verbose
Opción 2: Realización manual de las acciones

de habilitación
La mayoría de los clientes deben elegir la Opción uno que aparece arriba y usar el
módulo de PowerShell AzFilesHybrid para habilitar la autenticación de AD DS con Azure
Files. Sin embargo, si prefiere ejecutar los pasos manualmente mediante PowerShell de
Active Directory, use los que se describen a continuación.
） Importante
Si ya ha ejecutado correctamente el script Join-AzStorageAccount anterior, vaya
directamente a la sección Confirmación de que la característica está habilitada.
No tendrá que realizar los siguientes pasos manuales.
Comprobación del entorno

En primer lugar, compruebe el estado del entorno.
Compruebe si Active Directory PowerShell está instalado y si el shell se ejecuta con

privilegios de administrador.
Asegúrese de que está instalado el módulo Az.Storage y, si no lo está, instálelo.
Necesitará al menos la versión 2.0.
Después de completar esas comprobaciones, compruebe la instancia de AD DS
para ver si hay una cuenta de equipo (predeterminada) o una cuenta de inicio de
sesión en el servicio que ya se haya creado con SPN/UPN, como
"cifs/nombre_de_la_cuenta_de_almacenamiento.file.core.windows.net". Si la cuenta
no existe, cree una como se describe en la sección siguiente.
） Importante
Los cmdlets de PowerShell de Windows Server Active Directory de esta sección

deben ejecutarse en Windows PowerShell 5.1. PowerShell 7.x y Azure Cloud Shell
no funcionarán en este escenario.
Creación de una identidad que represente a la cuenta de

almacenamiento de AD manualmente
Para crear esta cuenta manualmente, primero cree una nueva clave Kerberos para la
cuenta de almacenamiento y obtenga la clave de acceso mediante los cmdlets de
PowerShell siguientes. Esta clave solo se usa durante la instalación. No se puede usar
para las operaciones de control o de plano de datos en la cuenta de almacenamiento.
PowerShell
# Create the Kerberos key on the storage account and get the Kerb1 key as
the password for the AD identity
# to represent the storage account
New-AzStorageAccountKey -ResourceGroupName $ResourceGroupName -Name

$StorageAccountName -KeyName kerb1
Get-AzStorageAccountKey -ResourceGroupName $ResourceGroupName -Name
$StorageAccountName -ListKerbKey | where-object{$_.Keyname -contains
"kerb1"}
Los cmdlets deben devolver el valor de clave. Una vez que tenga la clave kerb1, cree una
cuenta de equipo o una cuenta de servicio en AD en la unidad organizativa y use la
clave como contraseña para la identidad de AD.
1. Establezca el SPN en cifs/your-storage-account-name-here.file.core.windows.net

en la GUI de AD o ejecutando el comando Setspn desde la línea de comandos de
Windows como administrador (recuerde reemplazar el texto de ejemplo por el
nombre de la cuenta de almacenamiento y <ADAccountName> por el nombre de la
cuenta de AD).
shell
Setspn -S cifs/your-storage-account-name-here.file.core.windows.net
<ADAccountName>
2. Si tiene una cuenta de usuario, modifique el UPN para que coincida con el SPN del
objeto de AD (debe tener instalados los cmdlets de PowerShell de AD y ejecutar
los cmdlets en PowerShell 5.1 con privilegios elevados).
PowerShell
Set-ADUser -Identity $UserSamAccountName -UserPrincipalName

cifs/<StorageAccountName>.file.core.windows.net@<DNSRoot>
3. Establezca la contraseña de la cuenta de AD en el valor de la clave kerb1.
PowerShell
Set-ADAccountPassword -Identity servername$ -Reset -NewPassword

(ConvertTo-SecureString -AsPlainText "kerb1_key_value_here" -Force)
Si la unidad organizativa impone la expiración de la contraseña, debe actualizar la

contraseña antes de su vigencia máxima para evitar errores de autenticación al acceder
a recursos compartidos de archivos de Azure. Vea Actualización de la contraseña de la
identidad de la cuenta de almacenamiento en AD para obtener más información.
Mantenga el SID de la identidad recién creada; lo necesitará en el siguiente paso. No es

preciso sincronizar la identidad que ha creado y que representa la cuenta de
almacenamiento con Microsoft Entra ID.
Habilitación de la característica en la cuenta de
almacenamiento
Modifique el comando siguiente para incluir detalles de configuración para las
propiedades de dominio en el comando siguiente y, a continuación, ejecútelo para
habilitar la característica. El SID de la cuenta de almacenamiento necesario en el
siguiente comando es el de la identidad que creó en su AD DS en la sección anterior.
Asegúrese de proporcionar la propiedad ActiveDirectorySamAccountName sin el signo
"$" final.
PowerShell
# Set the feature flag on the target storage account and provide the
required AD domain information
Set-AzStorageAccount `
-ResourceGroupName "<your-resource-group-name>" `
-Name "<your-storage-account-name>" `
-EnableActiveDirectoryDomainServicesForFile $true `
-ActiveDirectoryDomainName "<your-domain-dns-root>" `
-ActiveDirectoryNetBiosDomainName "<your-domain-dns-root>" `
-ActiveDirectoryForestName "<your-forest-name>" `
-ActiveDirectoryDomainGuid "<your-guid>" `
-ActiveDirectoryDomainsid "<your-domain-sid>" `
-ActiveDirectoryAzureStorageSid "<your-storage-account-sid>" `
-ActiveDirectorySamAccountName "<your-domain-object-sam-account-
name>" `
-ActiveDirectoryAccountType "<your-domain-object-account-type, the
value could be 'Computer' or 'User'>"
Habilitación del cifrado AES-256 (recomendado)
Para habilitar el cifrado AES-256, siga los pasos de esta sección. Si piensa usar el cifrado
RC4, puede saltarse esta sección.
） Importante
Para habilitar el cifrado AES-256, el objeto de dominio que representa la cuenta de

almacenamiento debe ser una cuenta de equipo (predeterminada) o una cuenta de
inicio de sesión de servicio en el dominio de AD local. Si el objeto de dominio no
cumple este requisito, elimínelo y cree un nuevo objeto de dominio que lo haga.
Además, debe tener acceso de escritura al atributo msDS-SupportedEncryptionTypes
del objeto.
El cmdlet que ejecutará para configurar la compatibilidad con AES-256 depende de si el
objeto de dominio que representa la cuenta de almacenamiento es una cuenta de
equipo o una cuenta de inicio de sesión de servicio (cuenta de usuario). En cualquier
caso, debe tener instalados los cmdlets de PowerShell de AD y ejecutar el cmdlet en
PowerShell 5.1 con privilegios elevados.
Para habilitar el cifrado AES-256 en una cuenta de equipo, ejecute el siguiente

comando. Reemplace <domain-object-identity> y <domain-name> con sus valores.
PowerShell
Set-ADComputer -Identity <domain-object-identity> -Server <domain-name> -

KerberosEncryptionType "AES256"
Para habilitar el cifrado AES-256 en una cuenta de inicio de sesión de servicio, ejecute
el siguiente comando. Reemplace <domain-object-identity> y <domain-name> con sus
valores.
PowerShell
Set-ADUser -Identity <domain-object-identity> -Server <domain-name> -

KerberosEncryptionType "AES256"
Después de ejecutar el comando anterior, reemplace <domain-object-identity> en el

siguiente script por su valor y ejecute el script para actualizar la contraseña del objeto
de dominio:
PowerShell
$KeyName = "kerb1" # Could be either the first or second kerberos key, this
script assumes we're refreshing the first
$KerbKeys = New-AzStorageAccountKey -ResourceGroupName $ResourceGroupName -
Name $StorageAccountName -KeyName $KeyName
$KerbKey = $KerbKeys.keys | Where-Object {$_.KeyName -eq $KeyName} | Select-
Object -ExpandProperty Value
$NewPassword = ConvertTo-SecureString -String $KerbKey -AsPlainText -Force
Set-ADAccountPassword -Identity <domain-object-identity> -Reset -NewPassword

$NewPassword
） Importante
Si anteriormente usaba el cifrado RC4 y actualizaba la cuenta de almacenamiento

para usar AES-256, debe ejecutar klist purge en el cliente y, a continuación, volver
a montar el recurso compartido de archivos para obtener nuevos vales Kerberos
con AES-256.
Depuración
Si hace falta, puede ejecutar el cmdlet Debug-AzStorageAccountAuth para realizar un
conjunto de comprobaciones básicas en la configuración de AD con el usuario de AD
con el que ha iniciado sesión. Este cmdlet se admite en AzFilesHybrid v0.1.2+ y
versiones posteriores. Para más detalles sobre las comprobaciones realizadas en este
cmdlet, consulte No se puede montar recursos compartidos de archivos Azure con las
credenciales de AD.
PowerShell

Confirmación de que la característica está

habilitada
Puede comprobar si Active Directory está habilitado en la cuenta de almacenamiento
con el siguiente script:
PowerShell
# Get the target storage account

$storageaccount = Get-AzStorageAccount `
-ResourceGroupName "<your-resource-group-name-here>" `
-Name "<your-storage-account-name-here>"
# List the directory service of the selected service account

$storageAccount.AzureFilesIdentityBasedAuth.DirectoryServiceOptions
# List the directory domain information if the storage account has enabled
AD DS authentication for file shares
$storageAccount.AzureFilesIdentityBasedAuth.ActiveDirectoryProperties
En caso afirmativo, la salida debería ser similar a esta:
PowerShell
DomainName:<yourDomainHere>
NetBiosDomainName:<yourNetBiosDomainNameHere>
ForestName:<yourForestNameHere>
DomainGuid:<yourGUIDHere>
DomainSid:<yourSIDHere>
AzureStorageID:<yourStorageSIDHere>
Pasos siguientes
Ahora, ya ha habilitado correctamente AD DS en la cuenta de almacenamiento. Para
usar la característica, debe asignar permisos de nivel de recurso compartido.
Asignación de permisos de nivel de
recurso compartido
Artículo • 25/10/2023
Una vez habilitado un origen de Active Directory (AD) para la cuenta de

almacenamiento, debe configurar los permisos de nivel de recurso compartido para
poder acceder a los recursos compartidos de archivos. Hay dos maneras de asignar
permisos de nivel de recurso compartido. Puede asignarlos a usuarios o grupos
específicos de Microsoft Entra y puede asignarlos a todas las identidades autenticadas
como permiso de nivel de recurso compartido predeterminado.
） Importante
El control administrativo total de un recurso compartido de archivos, incluida la

capacidad de tomar posición de un archivo, requiere usar la clave de la cuenta de
almacenamiento. El control administrativo total no se admite con la autenticación
basada en identidades.
Se aplica a
Qué configuración debe usar

Los permisos de nivel de recurso compartido en los recursos compartidos de archivos
de Azure están configurados para usuarios, grupos o entidades de servicio de Microsoft
Entra, mientras que los permisos de nivel de directorio y archivo se aplican mediante
listas de control de acceso (ACL) de Windows. Debe asignar los permisos de nivel de
recurso compartido a la identidad de Microsoft Entra que representa el mismo usuario,
grupo o entidad de servicio en AD DS para admitir la autenticación de AD DS en el
recurso compartido de archivos de Azure. La autenticación y autorización con
identidades que solo existen en Microsoft Entra ID, como las identidades administradas
de Azure (MSI), no se admiten.
La mayoría de los usuarios deben asignar permisos de nivel de recurso compartido a

usuarios o grupos específicos de Microsoft Entra y, después, usar listas de control de
acceso de Windows para el control de acceso pormenorizado en el nivel de directorio y
archivo. Esta es la configuración más estricta y segura.
En su lugar, hay tres escenarios en los que se recomienda usar un permiso de nivel de
recurso compartido predeterminado para permitir el acceso de colaborador,
colaborador con privilegios elevados o lector a todas las identidades autenticadas:
Si no puede sincronizar el entorno local de AD DS con Microsoft Entra ID, puede

usar un permiso de nivel de recurso compartido predeterminado. Con la
asignación de este permiso puede evitar el requisito de sincronización, ya que no
es necesario especificar el permiso para las identidades en Microsoft Entra ID.
Después puede usar listas de control de acceso de Windows para la aplicación de
permisos pormenorizados en los archivos y directorios.
Las identidades asociadas a una instancia de AD pero no sincronizadas con
Microsoft Entra ID también pueden aprovechar el permiso de nivel
predeterminado de recurso compartido. Esto puede incluir cuentas de servicio
administradas independientes (sMSA), cuentas de servicio administradas de
grupo (gMSA) y cuentas de equipo.
El entorno local de AD DS que está usando se sincroniza con una instancia de
Microsoft Entra ID diferente de la instancia en la que se implementa el recurso
compartido.
Esto es habitual cuando se administran entornos multiinquilino. El uso de un
permiso de nivel de recurso compartido predeterminado le permite omitir el
requisito de una identidad híbrida de Microsoft Entra ID. Podrá seguir usando
las listas de control de acceso de Windows en los archivos y directorios para la
aplicación de permisos pormenorizados.
Prefiere aplicar la autenticación solo mediante listas de control de acceso de
Windows en el nivel de archivo y de directorio.
７ Nota
Dado que las cuentas de equipo no tienen una identidad en Microsoft Entra ID, no
se puede configurar el control de acceso basado en rol (RBAC) de Azure para estas.
Sin embargo, las cuentas de equipo pueden acceder a un recurso compartido de
archivos mediante un permiso de nivel de recurso compartido predeterminado.
Asignación de permisos de nivel de recurso
compartido
En la tabla siguiente se enumeran los permisos de nivel de recurso compartido y cómo
se corresponden con los roles de RBAC de Azure integrados:
Roles integrados Descripción

admitidos
Lector de recursos Permite el acceso de lectura a los archivos y directorios de los

compartidos de SMB de recursos compartidos de Azure. Este rol es análogo a una ACL de
datos de archivos de recurso compartido de lectura en los servidores de archivos de
Storage Windows. Más información.
Colaborador de recursos Permite el acceso de lectura, escritura y eliminación a los archivos

compartidos de SMB de y directorios de los recursos compartidos de Azure. Más
datos de archivos de información.
Storage
Colaborador elevado de Permite el acceso de lectura, escritura, eliminación y modificación

recursos compartidos de de ACL en los archivos y directorios de los recursos compartidos
SMB de datos de archivos de Azure. Este rol es análogo a una ACL de recurso compartido de
de Storage cambio en los servidores de archivos de Windows. Más
información.
Permisos de nivel de recurso compartido para

usuarios o grupos específicos de Microsoft
Entra
Si tiene previsto usar un usuario o grupo específico de Microsoft Entra para acceder a
recursos compartidos de archivos de Azure, esa identidad debe ser una identidad
híbrida que exista tanto en el entorno local de AD DS como en el de Microsoft Entra ID.
Por ejemplo, supongamos que tiene un usuario en su AD que es
user1@onprem.contoso.com y que se ha sincronizado a Microsoft Entra ID como
user1@contoso.com mediante Microsoft Entra Connect Sync o la sincronización en la
nube de Microsoft Entra Connect. Para que este usuario acceda a Azure Files, debe
asignar permisos de nivel de recurso compartido a user1@contoso.com. El mismo
concepto se aplica a los grupos y entidades de servicio.
） Importante
Asigne permisos al declarar explícitamente acciones y acciones de datos en lugar
de usar un carácter comodín (*). Si la definición de rol personalizada de una acción
de datos contiene un carácter comodín, se concede acceso a todas las identidades
asignadas a ese rol para todas las posibles acciones de datos. Esto significa que a
todas esas identidades también se les concederá cualquier nueva acción de datos
agregada a la plataforma. El acceso adicional y los permisos concedidos mediante
nuevas acciones o acciones de datos pueden ser comportamientos no deseados
para los clientes que usan un carácter comodín.
Para que los permisos de nivel de recurso compartido funcionen, debe:
Sincronice los usuarios y los grupos de su AD local a Microsoft Entra ID mediante

la aplicación Microsoft Entra Connect Sync o la sincronización en la nube de
Microsoft Entra Connect, un agente ligero que se puede instalar desde el Centro
de administración de Microsoft Entra.
Agregar grupos sincronizados de AD al rol RBAC para que puedan acceder a la
 Sugerencia
Opcional: Los clientes que quieran migrar permisos de nivel de recurso compartido
del servidor SMB a otros permisos de RBAC pueden usar el cmdlet Move-
OnPremSharePermissionsToAzureFileShare de PowerShell para migrar permisos de
nivel de directorio y archivo desde el entorno local hasta Azure. Este cmdlet evalúa
los grupos de un recurso compartido de archivos local determinado y, a
continuación, escribe los usuarios y grupos adecuados en el recurso compartido de
archivos de Azure mediante los tres roles RBAC. Al invocar el cmdlet, se
proporciona la información para el recurso compartido local y el recurso
Puede usar Azure Portal, Azure PowerShell o la CLI de Azure para asignar los roles
integrados a la identidad de Microsoft Entra de un usuario a fin de conceder permisos
de nivel de recurso compartido.
） Importante
Los permisos en el nivel de recurso compartido tardarán hasta tres horas en surtir
efecto una vez completado. Espere a que se sincronicen los permisos antes de
conectarse al recurso compartido de archivos con sus credenciales.
Portal
Para asignar un rol de Azure a una identidad de Microsoft Entra mediante Azure
Portal , siga estos pasos:
1. En Azure Portal, vaya al recurso compartido de archivos o cree uno.

2. Seleccione Access Control (IAM) .
3. Seleccione Agregar una asignación de roles.
4. En la hoja Agregar asignación de roles, seleccione el rol integrado apropiado
en la lista Rol.
a. Lector de recursos compartidos de SMB de datos de archivos de
almacenamiento
b. Colaborador de recursos compartidos de SMB de datos de archivos de
almacenamiento
c. Colaborador con privilegios elevados de recursos compartidos de SMB de
datos de archivos de almacenamiento
5. En Asignar acceso a, deje el valor predeterminado de Usuario, grupo o
entidad de servicio de Microsoft Entra. Seleccione la identidad de Microsoft
Entra de destino por nombre o dirección de correo electrónico. La identidad
de Microsoft Entra seleccionada debe ser una identidad híbrida y no puede
ser una identidad solo en la nube. Esto significa que la misma identidad
también se representa en AD DS.
6. Seleccione Guardar para completar la operación de asignación de roles.
Permisos de nivel de recurso compartido para

todas las identidades autenticadas
Puede agregar un permiso de nivel de recurso compartido predeterminado en la cuenta
de almacenamiento, en lugar de configurar permisos de nivel de recurso compartido
para usuarios o grupos de Microsoft Entra. Un permiso de nivel de recurso compartido
predeterminado asignado a la cuenta de almacenamiento se aplica a todos los recursos
compartidos contenidos en la cuenta de almacenamiento.
Al establecer un permiso de nivel de recurso compartido predeterminado, todos los

usuarios y grupos autenticados tendrán el mismo permiso. Los usuarios o grupos
autenticados se identifican, ya que la identidad se puede autenticar en el entorno local
de AD DS al que está asociado la cuenta de almacenamiento. El permiso de nivel de
recurso compartido predeterminado se establece en Ninguno durante la inicialización,
lo que implica que no se permite el acceso a los archivos o directorios en el recurso
Portal
Para configurar los permisos de nivel de recurso compartido predeterminados en la

cuenta de almacenamiento mediante Azure Portal , siga estos pasos.
1. En Azure Portal, vaya a la cuenta de almacenamiento que contiene los

recursos compartidos de archivos y seleccione Almacenamiento de datos y
Recursos compartidos de archivos.
2. Debe habilitar un origen de AD en la cuenta de almacenamiento antes de

asignar permisos predeterminados de nivel de recurso compartido. Si ya lo ha
hecho, seleccione Active Directory y continúe con el paso siguiente. De lo
contrario, seleccione Active Directory: No configurado, seleccione Configurar
en el origen de AD que quiera y habilite el origen de AD.
3. Después de habilitar un origen de AD, el Paso 2: Establecer permisos de nivel

de recurso compartido estará disponible para la configuración. Seleccione
Habilitar permisos para todos los usuarios y grupos autenticados.
4. Seleccione el rol adecuado que se va a habilitar como permiso de recurso

compartido predeterminado en la lista desplegable.
Qué ocurre si usa ambas configuraciones

También puede asignar permisos a todos los usuarios autenticados de Microsoft Entra, y
a usuarios y grupos específicos de Microsoft Entra. Con esta configuración, un usuario o
grupo específico tendrá el permiso de mayor nivel que combina el permiso de nivel de
recurso compartido y la asignación RBAC predeterminados. Es decir, supongamos que
ha concedido a un usuario el rol Lector de SMB de datos de archivos de
almacenamiento en el recurso compartido de archivos de destino. También ha
concedido el permiso de nivel de recurso compartido predeterminado Colaborador con
privilegios elevados de recursos compartidos de SMB de datos de archivos de
almacenamiento a todos los usuarios autenticados. Con esta configuración, ese usuario
concreto tendrá un nivel de acceso Colaborador con privilegios elevados de recursos
compartidos de SMB de datos de archivos de almacenamiento al recurso compartido.
Los permisos de nivel superior siempre tienen prioridad.
Pasos siguientes
Ahora que ha asignado los permisos de nivel de recurso compartido, puede configurar
los permisos de nivel de archivo y de directorio. Recuerde que los permisos de nivel de
recurso compartido pueden tardar hasta tres horas en surtir efecto.
Configuración de permisos de directorio
y de nivel de archivo sobre SMB
Artículo • 27/11/2023
Antes de comenzar este artículo, asegúrese de que ha leído, Asignación de permisos de

nivel de recurso compartido a una identidad, para garantizar la vigencia de los permisos
en el nivel de recurso compartido con el control de acceso basado en rol (RBAC) de
Azure.
Después de asignar los permisos de los recursos compartidos, puede configurar listas de
control de acceso (ACL) de Windows, también conocidas como permisos NTFS, en las
raíces, los directorios o los archivos. Si bien los permisos de nivel de recurso compartido
actúan como un equipo selector de alto nivel que determina si un usuario puede
acceder al recurso compartido, las listas de control de acceso de Windows operan en un
nivel más pormenorizado para controlar qué operaciones puede hacer un usuario en el
nivel de directorio o archivo.
Los permisos tanto de nivel de recurso compartido como de nivel de archivo o de

directorio se aplican cuando un usuario intenta acceder a un archivo o directorio, de
modo que, si existe alguna una diferencia entre alguno de ellos, solo se aplicará el más
restrictivo. Por ejemplo, si un usuario tiene acceso de lectura y escritura en el nivel de
archivo, pero solo de lectura en un nivel de recurso compartido, solo podrá leer ese
archivo. Y lo mismo sucede a la inversa: si un usuario tuviera acceso de lectura y
escritura en el nivel de recurso compartido, pero solo de lectura en el nivel de archivo,
solo podría leer el archivo.
） Importante
Para configurar las ACL de Windows, necesitará una máquina cliente que ejecute
Windows que tenga conectividad de red sin obstáculos al controlador de dominio.
Si va a autenticarse con Azure Files mediante Active Directory Domain Services
(AD DS) o Microsoft Entra Kerberos para identidades híbridas, esto significa que
necesitará conectividad de red sin obstáculos de AD local. Si usa Microsoft Entra
Domain Services, la máquina cliente debe tener conectividad de red sin obstáculos
a los controladores de dominio del dominio administrado por Microsoft Entra
Domain Services, que se encuentran en Azure.
Se aplica a
Permisos de Azure RBAC

En la siguiente tabla se incluyen los permisos de RBAC de Azure relacionados con esta
configuración. Si usa Explorador de Azure Storage, también necesitará el rol Lector y
acceso a datos para leer o acceder al recurso compartido de archivos.
Permiso en el nivel de recurso Permiso NTFS Acceso resultante

compartido (rol integrado)
Lector de recursos compartidos de Control total, Lectura & ejecución

SMB de datos de archivos de modificación, lectura,
Storage escritura y ejecución
Lectura Lectura
Colaborador de recursos Control total Modificación, lectura,

compartidos de SMB de datos de escritura y ejecución
archivos de Storage
Modificar Modificar
Lectura & ejecución Lectura & ejecución
Lectura Lectura
Escritura Escritura
Colaborador elevado de recursos Control total Modificar, leer, escribir,

compartidos de SMB de datos de editar (modificar los
archivos de Storage permisos), ejecutar
Modificar Modificar
Lectura & ejecución Lectura & ejecución
Lectura Lectura
Escritura Escritura
ACL de Windows admitidas

Azure Files admite el conjunto completo de ACL de Windows básicas y avanzadas.
Usuarios Definición
BUILTIN\Administrators Grupo de seguridad integrado que representa a los administradores

del servidor de archivos. Este grupo está vacío y no se puede agregar
a nadie.
BUILTIN\Users Grupo de seguridad integrado que representa a los usuarios del

servidor de archivos. Incluye NT AUTHORITY\Authenticated Users de
manera predeterminada. En el caso de un servidor de archivos
tradicional, puede configurar la definición de pertenencia por
servidor. Para Azure Files, no hay un servidor de hospedaje, por lo
que BUILTIN\Users incluye el mismo conjunto de usuarios que NT
AUTHORITY\Authenticated Users .
NT AUTHORITY\SYSTEM La cuenta de servicio del sistema operativo del servidor de archivos.

Esta cuenta de servicio no se aplica en el contexto de Azure Files. Se
incluye en el directorio raíz para ser coherente con la experiencia del
servidor de archivos de Windows para escenarios híbridos.
NT Todos los usuarios de AD que pueden obtener un token de Kerberos

AUTHORITY\Authenticated válido.
Users
CREATOR OWNER Cada objeto del directorio o archivo tiene un propietario para ese
objeto. Si hay ACL asignadas a CREATOR OWNER en ese objeto, el
usuario que es propietario de este objeto tiene los permisos para el
objeto definido por la ACL.
Los siguientes permisos están incluidos en el directorio raíz de un recurso compartido

de archivos:
BUILTIN\Administrators:(OI)(CI)(F)
BUILTIN\Users:(RX)
BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
NT AUTHORITY\Authenticated Users:(OI)(CI)(M)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(F)
CREATOR OWNER:(OI)(CI)(IO)(F)
Para más información sobre estos permisos avanzados, consulte la referencia de la línea
de comandos para icacls.
Cómo funciona
Hay dos enfoques que puede adoptar para configurar y editar ACL de Windows:
Inicie sesión con el nombre de usuario y la clave de la cuenta de

almacenamiento cada vez: cada vez que quiera configurar las ACL, monte el
recurso compartido de archivos mediante la clave de la cuenta de almacenamiento
en un equipo que tenga conectividad de red sin obstáculos al controlador de
dominio.
Configuración de la clave de cuenta de almacenamiento o nombre de usuario

único:
1. Inicie sesión con un nombre de usuario y una clave de cuenta de

almacenamiento en una máquina que tenga conectividad de red sin
obstáculos al controlador de dominio y conceda a algunos usuarios (o
grupos) permiso para editar permisos en la raíz del recurso compartido de
archivos.
2. Asigne a esos usuarios el rol RBAC de recursos compartidos de recursos
compartidos de SMB de datos de archivos de almacenamiento con
privilegios elevados.
3. En el futuro, siempre que quiera actualizar las ACL, puede usar uno de esos
usuarios autorizados para iniciar sesión desde una máquina que tenga
conectividad de red sin obstáculos al controlador de dominio y editar ACL.

mediante la clave de la cuenta de
almacenamiento
Antes de configurar las ACL de Windows, primero debe montar el recurso compartido
de archivos mediante la clave de la cuenta de almacenamiento. Para ello, inicie sesión en
un dispositivo unido a un dominio, abra un símbolo del sistema de Windows y ejecute el
siguiente comando. Recuerde reemplazar <YourStorageAccountName> , <FileShareName> y
<YourStorageAccountKey> por sus valores propios. Si Z ya está en uso, reemplácelo por
una letra de unidad disponible. Para encontrar la clave de la cuenta de almacenamiento

en Azure Portal, vaya a la cuenta de almacenamiento y seleccione Seguridad y
redes>Claves de acceso, o bien puede usar el cmdlet Get-AzStorageAccountKey de
PowerShell.
Es importante que use el comando net use de Windows para montar el recurso
compartido en esta fase, no PowerShell. Si usa PowerShell para montar el recurso
compartido, este no será visible para el Explorador de archivos de Windows o cmd.exe, y
tendrá dificultades a la hora de configurar las ACL de Windows.
７ Nota
Es posible que vea la ACL de control total ya aplicada a un rol. Normalmente, esto
ya ofrece la posibilidad de asignar permisos. Sin embargo, dado que hay
comprobaciones de acceso en dos niveles (el nivel de recurso compartido y el nivel
de archivo o directorio), esto está restringido. Solo los usuarios que tienen el rol
Colaborador con privilegios elevados de SMB y crean un archivo o directorio
pueden asignar permisos en esos archivos o directorios nuevos sin utilizar la clave
de cuenta de almacenamiento. El resto de la asignación de permisos de archivo o
directorio requiere primero conectarse al recurso compartido con la clave de
net use Z: \\<YourStorageAccountName>.file.core.windows.net\<FileShareName>

/user:localhost\<YourStorageAccountName> <YourStorageAccountKey>
Configuración de ACL de Windows

Las ACL de Windows se pueden configurar con icacls o con el Explorador de archivos de
Windows. También puede usar el comando Set-ACL de PowerShell.
） Importante
Si el entorno tiene varios bosques de AD DS, no use el Explorador de Windows para

configurar las ACL. En su lugar, use icacls.
Si tiene directorios o archivos en servidores de archivos locales con ACL de Windows

configuradas con identidades de AD DS, puede copiarlos en Azure Files, conservando las
ACL con herramientas tradicionales de copia de archivos como Robocopy o Azure
AzCopy versión 10.4+ . Si los directorios y archivos están organizados en niveles en
Azure Files a través de Azure File Sync, las ACL se trasladan y conservan en su formato
nativo.
Configuración de ACL de Windows con icacls

Para conceder permisos completos a todos los directorios y archivos del recurso
compartido de archivos, incluido el directorio raíz, ejecute el siguiente comando de
Windows desde un equipo que tenga línea de visión al controlador de dominio de AD.
No olvide reemplazar los valores del marcador de posición en el ejemplo por los suyos
propios.
icacls <mapped-drive-letter>: /grant <user-upn>:(f)
Para más información sobre cómo usar icacls para establecer ACL de Windows, así como
sobre los distintos tipos de permisos admitidos, vea la referencia de línea de comandos
de icacls.
Configuración de ACL de Windows con el Explorador de

archivos de Windows
Si ha iniciado sesión en un cliente Windows unido a un dominio, puede usar el
Explorador de archivos de Windows para conceder permiso completo a todos los
directorios y archivos del recurso compartido de archivos, incluido el directorio raíz. Si el
cliente no está unido a un dominio, use icacls para configurar las ACL de Windows.
1. Abra el Explorador de archivos de Windows y haga clic con el botón derecho en el

archivo o directorio, y seleccione Propiedades.
2. Seleccione la pestaña Seguridad .
3. Para cambiar los permisos, seleccione Editar.
4. Puede cambiar el permiso de los usuarios existentes o seleccionar Agregar... para
conceder permisos a los nuevos usuarios.
5. En la ventana del símbolo del sistema para agregar nuevos usuarios, escriba el
nombre de usuario de destino al que quiera conceder permisos en el cuadro
Escriba los nombres de objeto que desea seleccionar y seleccione Comprobar
nombres para buscar el nombre UPN completo del usuario de destino.
7. En la pestaña Seguridad, seleccione todos los permisos que desea conceder al
nuevo usuario.
8. Seleccione Aplicar.
Pasos siguientes
Ahora que la característica está habilitada y configurada, puede montar un recurso
compartido de archivos desde una máquina virtual unida a un dominio.
archivos de Azure
Artículo • 21/12/2023
Antes de comenzar este artículo, asegúrese de leer Configuración de permisos de nivel

de directorio y de archivo en SMB.
El proceso descrito en este artículo comprueba que su recurso compartido de archivos

SMB y los permisos de acceso se hayan configurado correctamente y que pueda montar
su recurso compartido de archivos SMB de Azure. Recuerde que la asignación de roles
de nivel de recurso compartido puede tardar un tiempo en surtir efecto.
Inicie sesión en el cliente con las credenciales de la identidad a la que concedió

permisos.
Se aplica a
ﾉ Expandir tabla
Requisitos previos de montaje

Antes de poder montar el recurso compartido de archivos de Azure, asegúrese de que
ha superado los requisitos previos siguientes:
Si va a montar el recurso compartido de archivos desde un cliente que lo haya

conectado previamente a la clave de la cuenta de almacenamiento, asegúrese de
que ha desconectado el recurso compartido, que ha quitado las credenciales
persistentes de la clave de la cuenta de almacenamiento y que actualmente usa
credenciales de AD DS para la autenticación. Para descubrir cómo quitar las
credenciales almacenadas en caché con la clave de la cuenta de almacenamiento y
eliminar las conexiones SMB existentes antes de inicializar una nueva conexión con
las credenciales de AD DS o Microsoft Entra, siga este proceso de dos pasos en la
página de Preguntas frecuentes.
El cliente debe tener conectividad de red no impedida a su AD DS. Si el equipo o la
máquina virtual está fuera de la red administrada por AD DS, tendrá que habilitar
la VPN a fin de acceder a AD DS para la autenticación.

desde una VM unida al dominio
Ejecute el script de PowerShell siguiente o use Azure Portal para montar de manera
persistente el recurso compartido de archivos de Azure y asignarlo a la unidad Z: en
Windows. Si Z ya está en uso, reemplácelo por una letra de unidad disponible. El script
comprobará si esta cuenta de almacenamiento es accesible a través del puerto TCP 445,
que es el puerto que SMB usa. Reemplace los valores del marcador de posición por los
suyos propios. Para más información, consulte Uso de un recurso compartido de
archivos de Azure con Windows.
A menos que use nombres de dominio personalizados, debe montar recursos

compartidos de archivos de Azure mediante el sufijo file.core.windows.net , incluso
aunque configure un punto de conexión privado para el recurso compartido.
PowerShell
$connectTestResult = Test-NetConnection -ComputerName <storage-account-

name>.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
cmd.exe /C "cmdkey /add:`"<storage-account-name>.file.core.windows.net`"
/user:`"localhost\<storage-account-name>`""
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<storage-account-
name>.file.core.windows.net\<file-share-name>" -Persist
} else {
Write-Error -Message "Unable to reach the Azure storage account via port
445. Check to make sure your organization or ISP is not blocking port 445,
or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic
over a different port."
}
También puede usar el comando net-use desde una ventana del sistema de Windows
para montar el recurso compartido de archivos. Recuerde reemplazar
<YourStorageAccountName> y <FileShareName> por sus valores propios.
Si tiene problemas, consulte No se pueden montar recursos compartidos de archivos de

Azure con las credenciales de AD.

desde una máquina virtual no unida a un
dominio o una máquina virtual unida a un
dominio de AD diferente
Las máquinas virtuales que no están unidas a un dominio o máquinas virtuales que
están unidas a un dominio de AD diferente al de la cuenta de almacenamiento pueden
acceder a los recursos compartidos de archivos de Azure si tienen conectividad de red
sin obstáculos con los controladores de dominio y proporcionan credenciales explícitas.
El usuario que accede al recurso compartido de archivos debe tener una identidad y
credenciales en el dominio de AD al que está unida la cuenta de almacenamiento.
Para montar un recurso compartido de archivos desde una máquina virtual no unida a
un dominio, use la notación username@domainFQDN, donde domainFQDN es el
nombre de dominio completo. Esto permitirá al cliente ponerse en contacto con el
controlador de dominio para solicitar y recibir vales de Kerberos. Es posible obtener el
valor de domainFQDN ejecutando (Get-ADDomain).Dnsroot en el PowerShell de Active
Directory.
Por ejemplo:

/user:<username@domainFQDN>
７ Nota
Azure Files no admite la traducción de SID a UPN para usuarios y grupos desde una
máquina virtual no unida a un dominio o una máquina virtual unida a un dominio
diferente a través del Explorador de archivos de Windows. Si desea ver los
propietarios de archivos o directorios o ver o modificar permisos NTFS a través del
Explorador de archivos de Windows, puede hacerlo solo desde máquinas virtuales
unidas a un dominio.
Montaje de recursos compartidos de archivos

mediante nombres de dominio personalizados
Si no quiere montar recursos compartidos de archivos de Azure usando el sufijo
file.core.windows.net , puede modificar el sufijo del nombre de la cuenta de
almacenamiento asociado con el recurso compartido de archivos de Azure y, luego,

agregar un registro de nombre canónico (CNAME) para enrutar el nuevo sufijo al punto
de conexión de la cuenta de almacenamiento. Las instrucciones siguientes son solo para
entornos de bosque único. Para obtener información sobre cómo configurar entornos
que tengan dos o más bosques, consulte Uso de Azure Files con varios bosques de
Active Directory.
７ Nota
Azure Files solo admite la configuración de CNAME mediante el nombre de la

cuenta de almacenamiento como prefijo de dominio. Si no quiere usar el nombre
de la cuenta de almacenamiento como prefijo, considere la posibilidad de usar
espacios de nombres DFS.
En este ejemplo, tenemos el dominio de Active Directory onpremad1.com y una cuenta

de almacenamiento denominada mystorageaccount, que contiene recursos compartidos
de archivos de Azure SMB. En primer lugar, es necesario modificar el sufijo SPN de la
cuenta de almacenamiento para asignar mystorageaccount.onpremad1.com a
mystorageaccount.file.core.windows.net.
Esto permitirá a los clientes montar el recurso compartido con net use
\\mystorageaccount.onpremad1.com porque los clientes de onpremad1 sabrán buscar
onpremad1.com a fin de encontrar el recurso adecuado para esa cuenta de

almacenamiento.
Para usar este método, complete los pasos siguientes:
1. Asegúrese de que ha configurado la autenticación basada en identidades y de que

ha sincronizado las cuentas de usuario de AD con Microsoft Entra ID.
2. Modifique el SPN de la cuenta de almacenamiento mediante la herramienta

setspn . Para encontrar <DomainDnsRoot> , ejecute el siguiente comando de
PowerShell de Active Directory: (Get-AdDomain).DnsRoot
setspn -s cifs/<storage-account-name>.<DomainDnsRoot> <storage-account-

name>
3. Agregue una entrada CNAME mediante el Administrador DNS de Active Directory

y siga los pasos siguientes para cada cuenta de almacenamiento del dominio al
que está unida la cuenta de almacenamiento. Si usa un punto de conexión privado,
agregue la entrada CNAME para asignarla al nombre del punto de conexión
privado.
a. Abra el Administrador DNS de Active Directory.
b. Vaya a su dominio (por ejemplo, onpremad1.com).
c. Vaya a "Zonas de búsqueda directa".
d. Seleccione el nodo denominado después del dominio (por ejemplo,
onpremad1.com) y haga clic con el botón derecho en Nuevo alias (CNAME).
e. En el nombre del alias, escriba el nombre de la cuenta de almacenamiento.
f. Para el nombre de dominio completo (FQDN), escriba <storage-account-name> .
<domain-name> , como mystorageaccount.onpremad1.com. La parte de nombre
de host del FQDN debe coincidir con el nombre de la cuenta de

almacenamiento. De lo contrario, recibirá un error de acceso denegado durante
la configuración de la sesión de SMB.
g. Para el FQDN del host de destino, escriba <storage-account-
name> .file.core.windows.net
h. Seleccione Aceptar.
Ahora debería poder montar el recurso compartido de archivos mediante

storageaccount.domainname.com. También puede montar el recurso compartido
mediante la clave de la cuenta de almacenamiento.
Pasos siguientes
Si la identidad que creó en AD DS para representar la cuenta de almacenamiento está
en un dominio o en una unidad organizativa que aplica la rotación de contraseñas, es
posible que tenga que actualizar la contraseña de la identidad de la cuenta de
almacenamiento en AD DS.
Actualización de la contraseña de la
identidad de la cuenta de
almacenamiento en AD DS
Artículo • 01/06/2023
Si registró la cuenta/identidad de Active Directory Domain Services (AD DS) que

representa la cuenta de almacenamiento en una unidad organizativa o un dominio que
aplica el tiempo de expiración de la contraseña, debe cambiar la contraseña antes de la
vigencia máxima de la contraseña. La organización puede ejecutar scripts de limpieza
automatizada que eliminen cuentas una vez que expire su contraseña. Por este motivo,
si no cambia la contraseña antes de que expire, podría eliminarse la cuenta, lo que hará
que pierda el acceso a los recursos compartidos de archivos de Azure.
Para evitar la rotación de contraseñas involuntaria, asegúrese de colocar la cuenta de

Azure Storage en una unidad organizativa independiente en AD DS durante la
incorporación en el dominio de dicha cuenta. Deshabilite la herencia de directivas de
grupo en esta unidad organizativa para evitar que se apliquen directivas de dominio
predeterminadas o directivas de contraseñas específicas.
７ Nota
Una identidad de cuenta de almacenamiento en AD DS puede ser una cuenta de

servicio o una cuenta de equipo. Las contraseñas de cuenta de servicio pueden
expirar en AD; sin embargo, dado que los cambios en la contraseña de la cuenta de
equipo están controlados por el equipo cliente y no por AD, no expiran en AD.
Hay dos opciones para desencadenar la rotación de contraseñas. Puede usar el

AzFilesHybrid módulo o PowerShell de Active Directory. Use solo uno de los dos
métodos.
Se aplica a

Use el módulo AzFilesHybrid
Puede ejecutar el Update-AzStorageAccountADObjectPassword cmdlet desde el módulo
AzFilesHybrid . Este comando debe ejecutarse en un entorno local unido a AD DS
mediante una identidad híbrida con permiso de propietario en la cuenta de
almacenamiento y permisos de AD DS para cambiar la contraseña de la identidad que
representa la cuenta de almacenamiento. El comando realiza acciones similares a la
rotación de claves de la cuenta de almacenamiento. Concretamente, obtiene la segunda
clave Kerberos de la cuenta de almacenamiento y la usa para actualizar la contraseña de
la cuenta registrada en AD DS. Luego, vuelve a generar la clave Kerberos de destino de
la cuenta de almacenamiento y actualiza la contraseña de la cuenta registrada en AD DS.
PowerShell
# Update the password of the AD DS account registered for the storage

account
# You may use either kerb1 or kerb2
Update-AzStorageAccountADObjectPassword `
-RotateToKerbKey kerb2 `
-ResourceGroupName "<your-resource-group-name-here>" `
-StorageAccountName "<your-storage-account-name-here>"
Esta acción cambiará la contraseña del objeto de AD de kerb1 a kerb2. Esto está
pensado para ser un proceso de dos fases: cambie de kerb1 a kerb2 (kerb2 se volverá a
generar en la cuenta de almacenamiento antes de establecerse), espere varias horas y, a
continuación, vuelva a kerb1 (este cmdlet también volverá a generar kerb1).
Use PowerShell de Active Directory

Si no desea descargar el AzFilesHybrid módulo, puede usar PowerShell de Active
Directory.
） Importante

deben ejecutarse en Windows PowerShell 5.1 con privilegios elevados.
PowerShell 7.x y Azure Cloud Shell no funcionarán en este escenario.
Reemplace el valor <domain-object-identity> en el siguiente script y, a continuación,

ejecútelo para actualizar la contraseña del objeto de dominio:
PowerShell
$KeyName = "kerb1" # Could be either the first or second kerberos key, this
script assumes we're refreshing the first
$KerbKeys = New-AzStorageAccountKey -ResourceGroupName $ResourceGroupName -
Name $StorageAccountName -KeyName $KeyName
$KerbKey = $KerbKeys.keys | Where-Object {$_.KeyName -eq $KeyName} | Select-
Object -ExpandProperty Value
$NewPassword = ConvertTo-SecureString -String $KerbKey -AsPlainText -Force
Set-ADAccountPassword -Identity <domain-object-identity> -Reset -NewPassword

$NewPassword
Uso de Azure Files con varios bosques
de Active Directory
Artículo • 21/11/2023
Muchas organizaciones quieren usar la autenticación basada en identidades para

recursos compartidos de archivos de Azure SMB en entornos que tienen varios bosques
de Active Directory local Domain Services (AD DS). Se trata de un escenario común de
TI, especialmente después de fusiones y adquisiciones, donde los bosques de AD de la
empresa adquirida están aislados de los bosques de AD de la empresa matriz. En este
artículo se explica cómo funcionan las relaciones de confianza de bosque y se
proporcionan instrucciones paso a paso para la configuración y validación de varios
bosques.
） Importante
Si desea establecer permisos de nivel de recurso compartido para usuarios o

grupos específicos de Microsoft Entra mediante el control de acceso basado en rol
(RBAC) de Azure, primero debe sincronizar las cuentas de AD locales con Microsoft
Entra ID mediante Microsoft Entra Connect. También puede usar un permiso de
nivel de recurso compartido predeterminado.
Se aplica a
Requisitos previos
Dos controladores de dominio de AD DS con bosques diferentes y en diferentes
redes virtuales (VNET)
Permisos suficientes de AD para realizar tareas administrativas (por ejemplo,
Administración de dominio )
Si usa RBAC de Azure, un único servidor de sincronización de Microsoft Entra
Connect debe ser accesible para ambos bosques.
Funcionamiento de las relaciones de confianza

de bosque
La autenticación con AD DS local para Azure Files solo se admite con el bosque del
servicio de dominio en el que está registrada la cuenta de almacenamiento. De forma
predeterminada, solo se puede acceder a los recursos compartidos de archivos de Azure
con las credenciales de AD DS desde un solo bosque. Si necesita acceder al recurso
compartido de archivos de Azure desde un bosque diferente, debe configurar una
confianza de bosque.
Una confianza de bosque es una confianza transitiva entre dos bosques de AD que
permite a los usuarios de cualquiera de los dominios de un bosque autenticarse en
cualquiera de los dominios del otro bosque.
Configuración de varios bosques

Para configurar una configuración de varios bosques, realizaremos los pasos siguientes:
Recopilación de información de dominio y conexiones de red virtual entre

dominios
Establecimiento y configuración de una confianza
Configuración de la autenticación basada en identidades y cuentas de usuario
híbridas
Recopilación de información de dominio

En este ejercicio, tenemos dos controladores de dominio de AD DS locales con dos
bosques diferentes y en redes virtuales diferentes.
Bosque Dominio VNET
Bosque 1 onpremad1.com DomainServicesVNet WUS
Bosque 2 onpremad2.com vnet2/workloads
Establecimiento y configuración de una confianza

Para permitir que los clientes del Bosque 1 accedan a Azure Files recursos de dominio
del Bosque 2, debemos establecer una confianza entre los dos bosques. Siga estos
pasos para establecer la confianza.
1. Inicie sesión en una máquina unida a un dominio en Bosque 2 y abra la consola

Dominios y confianzas de Active Directory.
2. Haga clic con el botón derecho en el dominio local onpremad2.com y, a

continuación, seleccione la pestaña Confianzas.
3. Seleccione Nuevas confianzas para iniciar el Asistente para nueva confianza.
4. Especifique el nombre de dominio con el que desea crear confianza (en este
ejemplo, onpremad1.com) y, a continuación, seleccione Siguiente.
5. En Tipo de confianza, seleccione Confianza de bosque y, a continuación,

6. En Direction of Trust (Dirección de confianza), seleccione Two-way (Bidireccional)

y, a continuación, seleccione Next (Siguiente).
7. En Lados de confianza, seleccione Este dominio solo y, a continuación, seleccione

Siguiente.
8. Los usuarios del bosque especificado se pueden autenticar para usar todos los
recursos del bosque local (autenticación en todo el bosque) o solo aquellos
recursos que seleccione (autenticación selectiva). En Nivel de autenticación de
confianza saliente, seleccione Autenticación en todo el bosque, que es la opción
preferida cuando ambos bosques pertenecen a la misma organización. Seleccione
Next (Siguiente).
9. Escriba una contraseña para la confianza y, a continuación, seleccione Siguiente.

Se debe usar la misma contraseña al crear esta relación de confianza en el dominio
especificado.
10. Debería ver un mensaje que indica que la relación de confianza se ha creado
correctamente. Para configurar la confianza, seleccione Siguiente.
11. Confirme la confianza saliente y seleccione Siguiente.
12. Escriba el nombre de usuario y la contraseña de un usuario que tenga privilegios

de administrador del otro dominio.
Una vez que se supera la autenticación, se establece la confianza y debería poder ver el
dominio especificado onpremad1.com en la pestaña Confianzas.
Configuración de la autenticación basada en identidades

y cuentas de usuario híbridas
Una vez que se establezca la confianza, siga estos pasos para crear una cuenta de
almacenamiento y un recurso compartido de archivos SMB para cada dominio, habilitar
la autenticación de AD DS en las cuentas de almacenamiento y crear cuentas de usuario
híbridas sincronizadas con Microsoft Entra ID.
1. Inicie sesión en el Azure Portal y cree dos cuentas de almacenamiento como
onprem1sa y onprem2sa. Para conseguir un rendimiento óptimo, se recomienda
implementar la cuenta de almacenamiento en la misma región que el cliente desde
el que vaya a acceder al recurso compartido.
７ Nota
No es necesario crear una segunda cuenta de almacenamiento. Estas

instrucciones están diseñadas para mostrar un ejemplo de cómo acceder a las
cuentas de almacenamiento que pertenecen a distintos bosques. Si solo tiene
una cuenta de almacenamiento, puede omitir las segundas instrucciones de
configuración de la cuenta de almacenamiento.
2. Cree un recurso compartido de archivos de Azure SMB en cada cuenta de

almacenamiento.
3. Sincronice el AD local con Microsoft Entra ID mediante la aplicación de

sincronización de Microsoft Entra Connect.
4. Unión a un dominio de una máquina virtual de Azure en Bosque 1 a su AD DS

local. Para información acerca de cómo unirse a un dominio, consulte Unión de un
equipo a un dominio.
5. Habilite la autenticación de AD DS en la cuenta de almacenamiento asociada al

Bosque 1, por ejemplo , onprem1sa. Esto creará una cuenta de equipo en la
instancia local de AD denominada onprem1sa para representar la cuenta de
Almacenamiento de Azure y unirla a la cuenta de almacenamiento al dominio
onpremad1.com. Puede comprobar que la identidad de AD que representa la
cuenta de almacenamiento se creó buscando en Usuarios y equipos de Active
Directory para obtener onpremad1.com. En este ejemplo, verá una cuenta de
equipo denominada onprem1sa.
6. Para crear una cuenta de usuario, vaya a Active Directory > onpremad1.com. Haga
clic con el botón derecho en Usuarios, seleccione Crear, escriba un nombre de
usuario (por ejemplo, onprem1user) y active la casilla Contraseña nunca expira
(opcional).
7. Opcional: si desea usar Azure RBAC para asignar permisos de nivel de recurso
compartido, debe sincronizar el usuario con el identificador de Microsoft Entra
mediante Microsoft Entra Connect. Normalmente, Microsoft Entra Connect Sync se
actualiza cada 30 minutos. Sin embargo, puede forzar que se sincronice
inmediatamente abriendo una sesión de PowerShell con privilegios elevados y
ejecutando Start-ADSyncSyncCycle -PolicyType Delta . Es posible que primero
tenga que instalar el módulo ADSync mediante la ejecución Import-Module ADSync .
Para comprobar que el usuario se ha sincronizado con Microsoft Entra ID, inicie
sesión en Azure Portal con la suscripción de Azure asociada al inquilino de varios
bosques y seleccione Microsoft Entra ID. Seleccione Administrar > usuarios y
busque el usuario que agregó (por ejemplo, onprem1user). La sincronización local
habilitada debe indicar Sí.
8. Establezca permisos de nivel de recurso compartido mediante roles RBAC de Azure

o un permiso de nivel de recurso compartido predeterminado.
Si el usuario se sincroniza con Microsoft Entra ID, puede conceder un permiso

de nivel de recurso compartido (rol RBAC de Azure) al usuario onprem1user
en la cuenta de almacenamiento onprem1sa para que el usuario pueda
montar el recurso compartido de archivos. Para ello, vaya al recurso
compartido de archivos que ha creado en onprem1sa y siga las instrucciones
de Asignación de permisos de nivel de recurso compartido para grupos o
usuarios específicos de Microsoft Entra.
De lo contrario, puede usar un permiso de nivel de recurso compartido
predeterminado que se aplique a todas las identidades autenticadas.
Repita los pasos del 4 al 8 para el dominio onpremad2.com (cuenta de usuario

onprem2sa/user onprem2user) de Bosque2. Si tiene más de dos bosques, repita los
pasos de cada bosque.
Configuración de permisos de directorio y de

nivel de archivo (opcional)
En un entorno de varios bosques, use la utilidad de línea de comandos icacls para
configurar los permisos de nivel de archivo y directorio para los usuarios de ambos
bosques. Consulte Configuración de ACL de Windows con icacls.
Si se produce un error de icacls con un error de acceso denegado, siga estos pasos para
configurar los permisos de nivel de archivo y directorio montando el recurso
compartido con la clave de la cuenta de almacenamiento.
1. Elimine el montaje del recurso compartido existente: net use * /delete /y
2. Vuelva a montar el recurso compartido mediante la clave de la cuenta de

almacenamiento:
net use <driveletter> \\storageaccount.file.core.windows.net\sharename
/user:AZURE\<storageaccountname> <storageaccountkey>
3. Establezca los permisos de icacls para el usuario de Forest2 en la cuenta de

almacenamiento unida a Forest1 desde el cliente de Forest1.
７ Nota
No se recomienda usar Explorador de archivos para configurar las ACL en un

entorno de varios bosques. Aunque los usuarios que pertenecen al bosque unido a
un dominio a la cuenta de almacenamiento pueden tener permisos de nivel de
archivo o directorio establecidos a través del Explorador de archivos, no funcionará
para los usuarios que no pertenecen al mismo bosque unido a un dominio a la
Configurar sufijos de dominio

Como se explicó anteriormente, la forma en que Azure Files registra en AD DS es casi
igual que un servidor de archivos normal, donde crea una identidad (de forma
predeterminada, una cuenta de equipo, también podría ser una cuenta de inicio de
sesión de servicio) que representa la cuenta de almacenamiento en AD DS para la
autenticación. La única diferencia es que el nombre de entidad de seguridad de servicio
registrado de la cuenta de almacenamiento finaliza en file.core.windows.net, que no
coincide con el sufijo del dominio. Debido al sufijo de dominio diferente, deberá
configurar una directiva de enrutamiento de sufijos para habilitar la autenticación de
varios bosques.
Dado que el sufijo file.core.windows.net es el sufijo de todos los recursos de Azure Files
en lugar de un sufijo para un dominio de AD específico, el controlador de dominio del
cliente no sabe a qué dominio reenviar la solicitud y, por tanto, producirá un error en
todas las solicitudes en las que el recurso no se encuentre en su propio dominio.
Por ejemplo, cuando los usuarios de un dominio del Bosque 1 quieren llegar a un
recurso compartido de archivos con la cuenta de almacenamiento registrada en un
dominio del Bosque 2, esto no funcionará automáticamente porque la entidad de
servicio de la cuenta de almacenamiento no tiene un sufijo que coincida con el sufijo de
ningún dominio del Bosque 1.
Para configurar sufijos de dominio, emplee uno de los métodos siguientes:

Modifique el sufijo de la cuenta de almacenamiento y agregue un registro CNAME
(recomendado: funcionará con dos o más bosques)
Agregue el sufijo de nombre personalizado y regla de enrutamiento (no funcionará
con más de dos bosques)
Modifique el sufijo del nombre de la cuenta de

almacenamiento y añada un registro CNAME
Para resolver el problema de enrutamiento de dominio, modifique el sufijo del nombre
de la cuenta de almacenamiento asociado al recurso compartido de archivos de Azure y
agregue un registro CNAME para enrutar el nuevo sufijo al punto de conexión de la
cuenta de almacenamiento. Con esta configuración, los clientes unidos a un dominio
pueden acceder a las cuentas de almacenamiento unidas a cualquier bosque. Esto
funciona para entornos que tienen dos o más bosques.
En nuestro ejemplo, tenemos los dominios onpremad1.com y onpremad2.com, y

tenemos onprem1sa y onprem2sa como cuentas de almacenamiento asociadas a
recursos compartidos de archivos de Azure SMB en los dominios respectivos. Estos
dominios se encuentran en bosques diferentes que confían entre sí para acceder a los
recursos de los bosques de los demás. Queremos permitir el acceso a ambas cuentas de
almacenamiento de clientes que pertenecen a cada bosque. Para ello, es necesario
modificar los sufijos de SPN de la cuenta de almacenamiento:
onprem1sa.onpremad1.com -> onprem1sa.file.core.windows.net
onprem2sa.onpremad2.com -> onprem2sa.file.core.windows.net
Esto permitirá a los clientes montar el recurso compartido con net use
\\onprem1sa.onpremad1.com porque los clientes de onpremad1 o onpremad2 sabrán
buscar onpremad1.com encontrar el recurso adecuado para esa cuenta de

almacenamiento.
Para usar este método, complete los pasos siguientes:
1. Asegúrese de que ha establecido confianza entre los dos bosques y ha

configurado la autenticación basada en identidades y las cuentas de usuario
híbridas, como se describe en las secciones anteriores.
2. Modifique el SPN de la cuenta de almacenamiento mediante la herramienta

setspn. Para encontrar <DomainDnsRoot> , ejecute el siguiente comando de
PowerShell de Active Directory: (Get-AdDomain).DnsRoot
setspn -s cifs/<storage-account-name>.<DomainDnsRoot> <storage-account-
name>
3. Agregue una entrada CNAME mediante el Administrador DNS de Active Directory

y siga los pasos siguientes para cada cuenta de almacenamiento del dominio al
que está unida la cuenta de almacenamiento. Si usa un punto de conexión privado,
agregue la entrada CNAME para asignarla al nombre del punto de conexión
privado.
a. Abra el Administrador DNS de Active Directory.
b. Vaya a su dominio (por ejemplo, onpremad1.com).
c. Vaya a "Zonas de búsqueda directa".
d. Seleccione el nodo denominado después del dominio (por ejemplo,

onpremad1.com) y haga clic con el botón derecho en Nuevo alias (CNAME).
e. En el nombre del alias, escriba el nombre de la cuenta de almacenamiento.
f. Para el nombre de dominio completo (FQDN), escriba <storage-account-name> .

<domain-name> , como mystorageaccount.onpremad1.com.
g. Si usa un punto de conexión privado (PrivateLink) para la cuenta de

almacenamiento, agregue una entrada CNAME adicional para asignarlo al
nombre del punto de conexión privado, por ejemplo, ,
mystorageaccount.privatelink.onpremad1.com.
h. Para el FQDN del host de destino, escriba <storage-account-

name> .file.core.windows.net
i. Seleccione Aceptar.
Ahora, desde clientes unidos a un dominio, debería poder usar cuentas de
almacenamiento unidas a cualquier bosque.
７ Nota
Asegúrese de que la parte de nombre de host del FQDN coincide con el nombre de
la cuenta de almacenamiento, como se ha descrito anteriormente. De lo contrario,
recibe un error de acceso denegado: "La sintaxis de nombre de archivo, nombre de
directorio o etiqueta de volumen es incorrecta". Un seguimiento de red mostrará
STATUS_OBJECT_NAME_INVALID (0xc0000033) mensaje durante la configuración de
la sesión de SMB.
Agregar sufijo de nombre personalizado y regla de

enrutamiento
Si ya ha modificado el sufijo del nombre de la cuenta de almacenamiento y ha agregado
un registro CNAME como se describe en la sección anterior, puede omitir este paso. Si
prefiere no realizar cambios en DNS ni modificar el sufijo de nombre de la cuenta de
almacenamiento, puede configurar una regla de enrutamiento de sufijos de Bosque 1 a
Bosque 2 para un sufijo personalizado de file.core.windows.net.
７ Nota
La configuración del enrutamiento de sufijos de nombres no afecta a la capacidad

de acceder a los recursos del dominio local. Solo es necesario permitir que el
cliente reenvíe la solicitud al dominio que coincida con el sufijo cuando el recurso
no se encuentre en su propio dominio.
En primer lugar, agregue un nuevo sufijo personalizado en Bosque 2. Asegúrese de que

tiene los permisos administrativos adecuados para cambiar la configuración y de que ha
establecido la confianza entre los dos bosques. A continuación, siga estos pasos:
1. Inicie sesión en una máquina o máquina virtual que esté unida a un dominio en el
bosque 2.
2. Abra la consola Dominios y confianzas de Active Directory.
3. Haga clic con el botón derecho en Dominios y confianzas de Active Directory.
4. Seleccione Propiedades y luego seleccione Añadir.
5. Agregue el sufijo "file.core.windows.net" como sufijo de UPN.
6. Seleccione Aplicar y, después, Aceptar para cerrar el asistente.
A continuación, agregue la regla de enrutamiento de sufijos en el Bosque 1 para que se

redirija al Bosque 2.
Bosque 1.
3. Haga clic con el botón derecho en el dominio desde el cual quiera acceder al
recurso compartido de archivos, haga clic en la pestaña Confianzas y seleccione el
dominio del Bosque 2 en las confianzas de salida.
4. Seleccione Propiedades y, a continuación, Enrutamiento de sufijo de nombre.
5. Compruebe si aparece el sufijo "*.file.core.windows.net". Si no es así, seleccione
Actualizar.
6. Seleccione "*.file.core.windows.net", y Habilitar y Aplicar.
Valide que la confianza funciona

Ahora validaremos que la confianza funciona ejecutando el comando klist para mostrar
el contenido de la caché de credenciales de Kerberos y la tabla de claves.
bosque 1 y abra un símbolo del sistema de Windows.
2. Para mostrar la caché de credenciales de la cuenta de almacenamiento unida a un
dominio en el Bosque 2, ejecute uno de los siguientes comandos:
Si usó el sufijo Modify storage account name (Modificar el sufijo de la cuenta

de almacenamiento) y agregar el método de registro CNAME , ejecute: klist
get cifs/onprem2sa.onpremad2.com
Si usó el método agregar sufijo de nombre personalizado y regla de

enrutamiento, ejecute: klist get cifs/onprem2sa.file.core.windows.net
3. Debería ver una salida similar a la siguiente. La salida klist variará ligeramente en
función del método que usó para configurar los sufijos de dominio.
Client: onprem1user @ ONPREMAD1.COM

Server: cifs/onprem2sa.file.core.windows.net @ ONPREMAD2.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent
name_canonicalize
Start Time: 11/22/2022 18:45:02 (local)
End Time: 11/23/2022 4:45:02 (local)
Renew Time: 11/29/2022 18:45:02 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
Kdc Called: onprem2.onpremad2.com
Bosque 2 y abra un símbolo del sistema de Windows.
5. Para mostrar la caché de credenciales de la cuenta de almacenamiento unida a un
dominio en el Bosque 1, ejecute uno de los siguientes comandos:
Si usó el sufijo Modify storage account name (Modificar el sufijo de la cuenta

de almacenamiento) y agregar el método de registro CNAME , ejecute: klist
get cifs/onprem1sa.onpremad1.com
Si usó el método agregar sufijo de nombre personalizado y regla de

enrutamiento, ejecute: klist get cifs/onprem1sa.file.core.windows.net
6. Debería ver una salida similar a la siguiente. La salida klist variará ligeramente en
función del método que usó para configurar los sufijos de dominio.

Server: krbtgt/ONPREMAD2.COM @ ONPREMAD2.COM
Ticket Flags 0x40e10000 -> forwardable renewable pre_authent
name_canonicalize
Start Time: 11/22/2022 18:46:35 (local)
End Time: 11/23/2022 4:46:35 (local)
Renew Time: 11/29/2022 18:46:35 (local)
Cache Flags: 0x1 -> PRIMARY
Kdc Called: onprem2

Server: cifs/onprem1sa.file.core.windows.net @ ONPREMAD1.COM
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent
name_canonicalize
Start Time: 11/22/2022 18:46:35 (local)
End Time: 11/23/2022 4:46:35 (local)
Renew Time: 11/29/2022 18:46:35 (local)
Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
Kdc Called: onpremad1.onpremad1.com
Si ve la salida anterior, ha terminado. Si no lo hace, siga estos pasos para proporcionar

sufijos UPN alternativos para que la autenticación de varios bosques funcione.
） Importante
Este método solo funcionará en entornos con dos bosques. Si tiene más de dos
bosques, use uno de los otros métodos para configurar los sufijos de dominio.
En primer lugar, agregue un nuevo sufijo personalizado en Bosque 1.
Bosque 1.
3. Haga clic con el botón derecho en Dominios y confianzas de Active Directory.
4. Seleccione Propiedades y luego seleccione Añadir.
5. Agregue un sufijo UPN alternativo, como "onprem1sa.file.core.windows.net".
6. Seleccione Aplicar y, después, Aceptar para cerrar el asistente.
A continuación, agregue la regla de enrutamiento de sufijos en el Bosque 2.
bosque 2.
3. Haga clic con el botón derecho en el dominio al que desea acceder al recurso
compartido de archivos y, a continuación, seleccione la pestaña Confianzas y
seleccione la confianza saliente del Bosque 2 donde se agregó el nombre de
enrutamiento de sufijo.
4. Seleccione Propiedades y, a continuación, Enrutamiento de sufijo de nombre.
5. Compruebe si aparece el sufijo "onprem1sa.file.core.windows.net". Si no es así,
seleccione Actualizar.
6. Seleccione "onprem1sa.file.core.windows.net", y Habilitar y Aplicar.
Pasos siguientes
Para obtener más información, vea estos recursos:
Introducción a la compatibilidad de la autenticación basada en la identidad de

Azure Files (solo SMB)
Preguntas más frecuentes de Azure Files
Habilitación de la autenticación de
Microsoft Entra Domain Services en
Azure Files
Artículo • 22/11/2023
Azure Files admite la autenticación basada en identidades para recursos compartidos de

archivos de Windows a través del Bloque de mensajes del servidor (SMB) con el
protocolo de autenticación Kerberos mediante los métodos siguientes:

Microsoft Entra Kerberos para identidades de usuario híbrido
Este artículo se centra en habilitar y configurar Microsoft Entra Domain Services

(anteriormente Azure Active Directory Domain Services) para la autenticación basada en
identidades con recursos compartidos de archivos de Azure. En este escenario de
autenticación, las credenciales de Microsoft Entra y las credenciales de Microsoft Entra
Domain Services son las mismas y se pueden usar indistintamente.
Se recomienda encarecidamente consultar la sección Funcionamiento para seleccionar

el origen de AD adecuado para la autenticación. La instalación difiere en función del
origen de AD que se elija.
Si no está familiarizado con Azure Files, se recomienda que lea la guía de planeamiento
antes de este artículo.
７ Nota
Azure Files admite la autenticación de Kerberos con Microsoft Entra Domain

Services mediante el cifrado RC4-HMAC y AES-256. Se recomienda usar AES-256.
Azure Files admite la autenticación de Microsoft Entra Domain Services con

sincronización completa o parcial (con ámbito) con Microsoft Entra ID. En el caso
de los entornos con sincronización con ámbito presente, los administradores deben
tener en cuenta que Azure Files solo respeta las asignaciones de roles de RBAC de
Azure que se conceden a las entidades de seguridad que están sincronizadas. El
servicio Azure Files omitirá las asignaciones de roles concedidas a identidades que
no se sincronicen de Microsoft Entra ID a Microsoft Entra Domain Services.
Se aplica a
Requisitos previos
Antes de habilitar Microsoft Entra Domain Services con SMB para los recursos
compartidos de archivos de Azure, asegúrese de que ha completado los requisitos
previos siguientes:
1. Seleccionar o crear un inquilino de Microsoft Entra.
Puede usar un inquilino nuevo o uno existente. El inquilino y el recurso compartido

de archivos a los que desea acceder deben asociarse con la misma suscripción.
Para crear un nuevo inquilino de Microsoft Entra, puede Agregar un inquilino de

Microsoft Entra y una suscripción de Microsoft Entra. Si ya tiene un inquilino de
Microsoft Entra, pero desea crear otro para usarlo con los recursos compartido de
archivos de Azure, consulte Creación de un inquilino de Microsoft Entra.
2. Habilitar Microsoft Entra Domain Services en el inquilino de Microsoft Entra.
Para admitir la autenticación con credenciales de Microsoft Entra, debe habilitar

Microsoft Entra Domain Services para su inquilino de Microsoft Entra. Si no es el
administrador del inquilino de Microsoft Entra, póngase en contacto con el
administrador y siga las instrucciones paso a paso para habilitar Microsoft Entra
Domain Services mediante Azure Portal.
Suele tardar unos 15 minutos en completarse una implementación de Microsoft

Entra Domain Services. Confirme que el estado de mantenimiento de Microsoft
Entra Domain Services muestra En ejecución, con la sincronización de hash de
contraseña habilitada, antes de continuar con el paso siguiente.
3. Unión a dominio de una máquina virtual de Azure con Microsoft Entra Domain
Services.
Para acceder a un recurso compartido de archivos de Azure mediante las

credenciales de Microsoft Entra desde una VM, esta debe unirse a un dominio con
Microsoft Entra Domain Services. Para más información sobre cómo unir a un
dominio una máquina virtual, consulte Unión de una máquina virtual de Windows
Server a un dominio administrado. La autenticación de Microsoft Entra Domain
Services a través de SMB con recursos compartido de archivos de Azure solo se
admite en máquinas virtuales de Azure que se ejecutan en versiones del sistema
operativo posteriores a Windows 7 o Windows Server 2008 R2.
７ Nota
Las VM no unidas a un dominio pueden acceder a los recursos compartidos

de archivos de Azure mediante la autenticación de Microsoft Entra Domain
Services solo si la VM tiene conectividad de red no impedida a los
controladores de dominio para Microsoft Entra Domain Services.
Normalmente, esto requiere una VPN de sitio a sitio o de punto a sitio.
4. Seleccione o cree un recurso compartido de archivos.
Seleccione un recurso compartido de archivos nuevo o existente que esté asociado

con la misma suscripción que el inquilino de Microsoft Entra. Para información
acerca de cómo crear un nuevo recurso compartido de archivos, consulte Creación
de un recurso compartido de archivos en Azure Files. Para obtener un rendimiento
óptimo, se recomienda que el recurso compartido de archivos esté en la misma
región que la máquina virtual desde la que vaya a acceder al recurso compartido.
5. Compruebe la conectividad de Azure Files; para ello, monte los recursos

compartidos de archivos de Azure con la clave de su cuenta de almacenamiento.
Para comprobar que el recurso compartido de archivos y de la máquina virtual

están configurados correctamente, intente montar el recurso compartido de
archivos con la clave de la cuenta de almacenamiento. Para más información,
consulte Montaje de un recurso compartido de archivos de Azure y acceso al
recurso compartido en Windows.
La autenticación de Azure Files con Microsoft Entra Domain Services está disponible en
todas las regiones públicas, de Azure Government y de China .
Información general del flujo de trabajo

Antes de habilitar la autenticación de Microsoft Entra Domain Services a través de SMB
para los recursos compartido de archivos de Files, compruebe que los entornos de
Azure Storage y Microsoft Entra ID se han configurado correctamente. Se recomienda
que revise los requisitos previos para asegurarse de que ha completado todos los pasos
necesarios.
Siga estos pasos para conceder acceso a los recursos de Azure Files con las credenciales
de Microsoft Entra:
1. Habilite la autenticación de Microsoft Entra Domain Services a través de SMB para

la cuenta de almacenamiento a fin de registrar dicha cuenta con la
implementación de Microsoft Entra Domain Services asociada.
2. Asigne permisos de nivel de recurso compartido a una identidad de Microsoft
Entra (usuario, grupo o entidad de servicio).
3. Conéctese al recurso compartido de archivos de Azure mediante una clave de
cuenta de almacenamiento y configure listas de control de acceso (ACL) de
Windows para los directorios y los archivos.
4. Monte un recurso compartido de archivos de Azure desde una máquina virtual
unida al dominio.
En el diagrama siguiente se ilustra el flujo de trabajo de un extremo a otro para habilitar

la autenticación de Microsoft Entra Domain Services a través de SMB para Azure Files.
Habilitación de la autenticación de Microsoft

Entra Domain Services para su cuenta
Para habilitar la autenticación de Microsoft Entra Domain Services a través de SMB para
Azure Files, puede establecer una propiedad en las cuentas de almacenamiento
mediante Azure Portal, Azure PowerShell o la CLI de Azure. Al establecer esta propiedad
"une a un dominio" implícitamente la cuenta de almacenamiento con la implementación
de Microsoft Entra Domain Services asociada. La autenticación de Microsoft Entra
Domain Services a través de SMB se habilita entonces para todos los recursos
compartidos de archivos nuevos y existentes de la cuenta de almacenamiento.
Tenga en cuenta que puede habilitar la autenticación de Microsoft Entra Domain

Services a través de SMB solo después de haber implementado correctamente Microsoft
Entra Domain Services en su inquilino de Microsoft Entra. Para más información,
consulte la sección los requisitos previos.
Portal
Para habilitar la autenticación de Microsoft Entra Domain Services a través de SMB

mediante Azure Portal , siga estos pasos:
1. En Azure Portal, vaya a la cuenta de almacenamiento existente o cree una.
2. En la sección Recursos compartidos, seleccione Active Directory: No

configurado.
3. Seleccione Microsoft Entra Domain Services y luego marque la casilla para

habilitar la característica.

Recomendado: uso del cifrado AES-256

De forma predeterminada, la autenticación de Microsoft Entra Domain Services usa el
cifrado Kerberos RC4. Se recomienda configurarlo para usar, en su lugar, el cifrado AES-
256 de Kerberos. Para ello, siga estas instrucciones.
La acción requiere ejecutar una operación en el dominio de Active Directory

administrado por Microsoft Entra Domain Services para acceder a un controlador de
dominio para solicitar un cambio de propiedad en el objeto de dominio. Los siguientes
cmdlets son cmdlets de PowerShell de Windows Server Active Directory, no de Azure
PowerShell. Por este motivo, estos comandos de PowerShell deben ejecutarse en una
máquina cliente unida a un dominio de Microsoft Entra Domain Services.
） Importante

deben ejecutarse en Windows PowerShell 5.1 desde una máquina cliente unida a
un dominio de Microsoft Entra Domain Services. PowerShell 7.x y Azure Cloud Shell
no funcionarán en este escenario.
Inicie sesión en la máquina de cliente unida a un dominio como usuario de Microsoft

Entra Domain Services con los permisos necesarios. Debe tener acceso de escritura al
atributo msDS-SupportedEncryptionTypes del objeto de dominio. Por lo general, los
miembros del grupo Administradores de controlador de dominio de AAD tendrán los
permisos necesarios. Abra una sesión normal (sin privilegios elevados) de PowerShell y
ejecute los comandos siguientes.
PowerShell
# 1. Find the service account in your managed domain that represents the
storage account.
$storageAccountName= “<InsertStorageAccountNameHere>”
$searchFilter = "Name -like '*{0}*'" -f $storageAccountName
$userObject = Get-ADUser -filter $searchFilter
if ($userObject -eq $null)

{
Write-Error "Cannot find AD object for storage
account:$storageAccountName" -ErrorAction Stop
}
# 2. Set the KerberosEncryptionType of the object
Set-ADUser $userObject -KerberosEncryptionType AES256
# 3. Validate that the object now has the expected (AES256) encryption type.
Get-ADUser $userObject -properties KerberosEncryptionType
） Importante

para usar AES-256, debe ejecutar klist purge en el cliente y, a continuación, volver
a montar el recurso compartido de archivos para obtener nuevos vales Kerberos
con AES-256.

compartido
Para acceder a los recursos de Azure Files con la autenticación basada en identidades,
una identidad (usuario, grupo o entidad de servicio) debe tener los permisos necesarios
en el nivel de recurso compartido. Este proceso es similar a especificar los permisos de
recurso compartido de Windows, donde se especifica el tipo de acceso que tiene un
usuario determinado a un recurso compartido de archivos. Las instrucciones de esta
sección muestran cómo asignar permisos de lectura, escritura o eliminación para un
recurso compartido de archivos a una identidad. Se recomienda asignar permisos
declarando acciones y acciones de datos explícitamente en lugar de usar el carácter
comodín (*).
La mayoría de los usuarios deben asignar permisos de nivel de recurso compartido a

usuarios o grupos específicos de Microsoft Entra y, después, configurar listas de control
de acceso de Windows para el control de acceso pormenorizado en el nivel de
directorio y archivo. Sin embargo, como alternativa, puede establecer un permiso de
nivel de recurso compartido predeterminado para permitir el acceso de colaborador,
colaborador con privilegios elevados o lector a todas las identidades autenticadas.
Hay cinco roles integrados de Azure para Azure Files, algunos de los cuales permiten
conceder permisos de nivel de recurso compartido a usuarios y grupos:
El Lector de recursos compartidos de datos de archivos de almacenamiento

permite el acceso de lectura en los recursos compartidos de archivos de Azure a
través de SMB.
El rol Lector con privilegios de datos de archivos de almacenamiento permite el
acceso de lectura en recursos compartidos de archivos de Azure a través de SMB
reemplazando las ACL de Windows existentes.
El rol Colaborador de recursos compartidos de datos de archivos de
almacenamiento permite el acceso de lectura, escritura y eliminación en los
recursos compartidos de archivos de Azure a través de SMB.
El rol Colaborador con privilegios elevados de recursos compartidos de datos de
archivos de almacenamiento permite el acceso de lectura, escritura, eliminación y
modificación de ACL de Windows en los recursos compartidos de archivos de
Azure mediante SMB.
El rol Colaborador con privilegios de datos de archivos de almacenamiento
permite el acceso de lectura, escritura, eliminación y modificación de ACL de
Windows en los recursos compartidos de archivos de Azure mediante SMB
reemplazando las ACL de Windows existentes.
） Importante
El control administrativo total de un recurso compartido de archivos, incluida la

capacidad de tomar posición de un archivo, requiere usar la clave de la cuenta de
almacenamiento. El control administrativo no se admite con las credenciales de
Microsoft Entra.
Puede usar Azure Portal, PowerShell o la CLI de Azure para asignar los roles integrados a
la identidad de Microsoft Entra de un usuario a fin de conceder permisos de nivel de
recurso compartido. Tenga en cuenta que la asignación de roles de Azure de nivel de
recurso compartido puede tardar un tiempo en estar en vigor. Se recomienda usar el
permiso de nivel de recurso compartido para la administración del acceso de alto nivel
para un grupo de AD que represente un grupo de usuarios e identidades y, después,
aprovechar las listas de control de acceso de Windows para el control de acceso
pormenorizado en el nivel de directorio o archivo.
Asignación de un rol de Azure a una identidad de
Microsoft Entra
） Importante
Asigne permisos al declarar explícitamente acciones y acciones de datos en lugar

de usar un carácter comodín (*). Si la definición de rol personalizada de una acción
de datos contiene un carácter comodín, se concede acceso a todas las identidades
asignadas a ese rol para todas las posibles acciones de datos. Esto significa que a
todas esas identidades también se les concederá cualquier nueva acción de datos
agregada a la plataforma. El acceso adicional y los permisos concedidos mediante
nuevas acciones o acciones de datos pueden ser comportamientos no deseados
para los clientes que usan un carácter comodín.
Portal
Para asignar un rol de Azure a una identidad de Microsoft Entra mediante Azure
Portal , siga estos pasos:
1. En Azure Portal, vaya al recurso compartido de archivos o cree un recurso

2. Seleccione Access Control (IAM) .
3. Seleccione Agregar una asignación de roles.
4. En la hoja Agregar asignación de roles, seleccione el rol integrado adecuado
(por ejemplo, Lector o Colaborador de recursos compartidos de SMB de datos
de archivos de almacenamiento) en la lista desplegable Rol. En Asignar acceso
a, deje el valor predeterminado de Usuario, grupo o entidad de servicio de
Microsoft Entra. Seleccione la identidad de Microsoft Entra de destino por
nombre o dirección de correo electrónico.
5. Seleccione Revisar y asignar para completar la asignación de roles.
Configuración de ACL de Windows

Después de asignar los permisos de los recursos compartidos con RBAC, puede asignar
las ACL de Windows a las raíces, los directorios o los archivos. Considere los permisos de
nivel de recurso compartido como el equipo selector de alto nivel que determina si un
usuario puede acceder al recurso compartido, mientras que las listas de control de
acceso de Windows actúan en un nivel más pormenorizado para determinar las
operaciones que puede hacer un usuario en el nivel de directorio o archivo.
Azure Files admite el conjunto completo de permisos básicos y avanzados. Las listas de
control de acceso de Windows se pueden ver y configurar en los directorios y los
archivos de un recurso compartido de archivos de Azure; para ello, monte el recurso
compartido y utilice el Explorador de archivos de Windows o ejecute el comando icacls
o Set-ACL de Windows.
Se admiten los siguientes conjuntos de permisos en el directorio raíz de un recurso

compartido de archivos:
BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Users:(RX)
BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
NT AUTHORITY\Authenticated Users:(OI)(CI)(M)
NT AUTHORITY\SYSTEM:(F)
CREATOR OWNER:(OI)(CI)(IO)(F)
Para más información, consulte Configuración de permisos de nivel de directorio y de

archivo en SMB.
Montaje del recurso compartido de archivos mediante la

clave de la cuenta de almacenamiento
Antes de configurar las ACL de Windows, primero debe montar el recurso compartido
de archivos en la máquina virtual unida a un dominio mediante la clave de la cuenta de
almacenamiento. Para ello, inicie sesión en la máquina virtual unida a un dominio como
usuario de Microsoft Entra, abra un símbolo del sistema de Windows y ejecute el
comando siguiente. Recuerde reemplazar <YourStorageAccountName> , <FileShareName> y
<YourStorageAccountKey> por sus valores propios. Si Z ya está en uso, reemplácelo por
una letra de unidad disponible. Para encontrar la clave de la cuenta de almacenamiento

en Azure Portal, vaya a la cuenta de almacenamiento y seleccione Seguridad y
redes>Claves de acceso, o bien puede usar el cmdlet Get-AzStorageAccountKey de
PowerShell.
Es importante que use el comando net use de Windows para montar el recurso
compartido en esta fase, no PowerShell. Si usa PowerShell para montar el recurso
compartido, este no será visible para el Explorador de archivos de Windows o cmd.exe, y
no podrá configurar las ACL de Windows.
７ Nota
Es posible que vea la ACL de control total ya aplicada a un rol. Normalmente, esto
ya ofrece la posibilidad de asignar permisos. Sin embargo, dado que hay
comprobaciones de acceso en dos niveles (el nivel de recurso compartido y el nivel
de archivo o directorio), esto está restringido. Solo los usuarios que tienen el rol
Colaborador con privilegios elevados de SMB y crean un archivo o directorio
pueden asignar permisos en esos archivos o directorios nuevos sin utilizar la clave
de cuenta de almacenamiento. El resto de la asignación de permisos de archivo o
directorio requiere primero conectarse al recurso compartido con la clave de

/user:localhost\<YourStorageAccountName> <YourStorageAccountKey>
Configuración de ACL de Windows con el Explorador de

archivos de Windows
Una vez que monta el recurso compartido de archivos de Azure, debe configurar las ACL
de Windows. Puede hacerlo en el Explorador de archivos de Windows o con icacls.
Siga estos pasos para utilizar el Explorador de archivos de Windows a fin de conceder
permisos completos para todos los directorios y archivos en el recurso compartido de
archivos, incluido el directorio raíz.
1. Abra el Explorador de archivos de Windows y haga clic con el botón derecho en el

archivo o directorio, y seleccione Propiedades.
2. Seleccione la pestaña Seguridad .
3. Seleccione Editar para cambiar los permisos.
4. Puede cambiar los permisos de los usuarios existentes o seleccionar Agregar para
conceder permisos a usuarios nuevos.
5. En la ventana del símbolo del sistema para agregar nuevos usuarios, escriba el
nombre de usuario de destino al que desea conceder el permiso en el cuadro
Escriba los nombres de objeto que desea seleccionar y seleccione Comprobar
nombres para buscar el nombre UPN completo del usuario de destino.
7. En la pestaña Seguridad, seleccione todos los permisos que desea conceder al
nuevo usuario.
8. Seleccione Aplicar.
Configuración de ACL de Windows con icacls

Utilice el siguiente comando de Windows para conceder permisos completos para todos
los directorios y archivos en el recurso compartido de archivos, incluido el directorio
raíz. No olvide reemplazar los valores del marcador de posición en el ejemplo por los
suyos propios.
icacls <mounted-drive-letter>: /grant <user-email>:(f)
Para más información sobre cómo usar icacls para establecer listas de control de acceso
de Windows, así como sobre los distintos tipos de permisos admitidos,consulte la
referencia de línea de comandos de icacls.

desde una VM unida al dominio
El proceso siguiente comprueba que tanto el recurso compartido de archivos como los
permisos de acceso se han configurado correctamente y que puede acceder a un
recurso compartido de archivos de Azure desde una máquina virtual unida a un
dominio. Tenga en cuenta que la asignación de roles de Azure de nivel de recurso
compartido puede tardar un tiempo en estar en vigor.
Inicie sesión en la máquina virtual unida al dominio con la identidad de Microsoft Entra
a la que se concedieron permisos. Asegúrese de iniciar sesión con las credenciales de
Microsoft Entra. Si la unidad ya está montada con la clave de la cuenta de
almacenamiento, deberá desconectar la unidad o volver a iniciar sesión.
Ejecute el script de PowerShell siguiente o use Azure Portal para montar de manera
persistente el recurso compartido de archivos de Azure y asignarlo a la unidad Z: en
Windows. Si Z ya está en uso, reemplácelo por una letra de unidad disponible. Como se
autenticó, no será necesario que proporcione la clave de cuenta de almacenamiento. El
script comprobará si esta cuenta de almacenamiento es accesible a través del puerto
TCP 445, que es el puerto que SMB usa. Recuerde reemplazar <storage-account-name> y
<file-share-name> por sus valores propios. Para más información, consulte Uso de un
recurso compartido de archivos de Azure con Windows.

Siempre monte los recursos compartidos de archivos de Azure con
file.core.windows.net , incluso si configura un punto de conexión privado para el
recurso compartido.
PowerShell
$connectTestResult = Test-NetConnection -ComputerName <storage-account-

name>.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
cmd.exe /C "cmdkey /add:`"<storage-account-name>.file.core.windows.net`"
/user:`"localhost\<storage-account-name>`""
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<storage-account-
name>.file.core.windows.net\<file-share-name>" -Persist
} else {
Write-Error -Message "Unable to reach the Azure storage account via port
445. Check to make sure your organization or ISP is not blocking port 445,
or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic
over a different port."
}
También puede usar el comando net-use desde una ventana del sistema de Windows
para montar el recurso compartido de archivos. Recuerde reemplazar
<YourStorageAccountName> y <FileShareName> por sus valores propios.

desde una máquina virtual no unida a un
dominio o una máquina virtual unida a un
dominio de AD diferente
Las VM no unidas a un dominio o las VM que se han unido a un dominio diferente al de
la cuenta de almacenamiento pueden acceder a los recursos compartidos de archivos de
Azure mediante la autenticación de Microsoft Entra Domain Services solo si la VM tiene
conectividad de red no impedida a los controladores de dominio para Microsoft Entra
Domain Services, que están ubicados en Azure. Normalmente, esto requiere configurar
una VPN de sitio a sitio o de punto a sitio. El usuario que accede al recurso compartido
de archivos debe tener una identidad y credenciales (una identidad de Microsoft Entra
sincronizada desde Microsoft Entra ID a Microsoft Entra Domain Services) en el dominio
administrado de Microsoft Entra Domain Services.
Para montar un recurso compartido de archivos desde una máquina virtual no unida a
un dominio, el usuario debe:
Proporcionar credenciales explícitas, como

NOMBRE_DEL_DOMINIO\nombre_de_usuario, donde NOMBRE_DEL_DOMINIO es
el dominio de Microsoft Entra Domain Services y el nombre de usuario es el de la
identidad en Microsoft Entra Domain Services o
Use la notación username@domainFQDN, donde domainFQDN es el nombre de
dominio completo.
El uso de uno de estos enfoques permitirá al cliente ponerse en contacto con el

controlador de dominio en el dominio de Microsoft Entra Domain Services para solicitar
y recibir vales de Kerberos.
Por ejemplo:

/user:<DOMAINNAME\username>
or

/user:<username@domainFQDN>
Pasos siguientes
Si desea conceder a otros usuarios acceso al recurso compartido de archivos, siga las
instrucciones que aparecen en Asignación de permisos de nivel de recurso compartido y
Configuración de ACL de Windows.
Para más información sobre la autenticación basada en identidad para Azure Files,
consulte estos recursos:

P+F
Habilitación de la autenticación
Kerberos de Microsoft Entra para
identidades híbridas en Azure Files
Artículo • 21/11/2023
En este artículo, se describe cómo activar y configurar Microsoft Entra ID (anteriormente

Azure AD) para autenticar identidades de usuario híbridas, que son identidades de
AD DS locales que están sincronizadas con Azure AD. Las identidades solo en la nube no
se admiten actualmente.
Esta configuración permite a los usuarios híbridos acceder a recursos compartidos de

archivos de Azure mediante la autenticación Kerberos, mediante Microsoft Entra ID para
emitir los vales de Kerberos necesarios a fin de acceder al recurso compartido de
archivos con el protocolo SMB. Esto significa que los usuarios finales pueden acceder a
los recursos compartidos de archivos de Azure a través de Internet sin necesidad de
tener conectividad de red no impedida a los controladores de dominio desde clientes
unidos a Microsoft Entra híbrido y a Microsoft Entra. Sin embargo, la configuración de
listas de control de acceso de Windows/permisos de nivel de archivo y directorio de un
usuario o grupo requiere tener conectividad de red no impedida al controlador de
dominio local.
Para más información sobre las opciones y consideraciones admitidas, consulte

Información general sobre opciones de autenticación basada en identidades de Azure
Files para el acceso SMB. Para obtener más información, consulte este análisis en
profundidad .
） Importante
Solo se puede usar un método de AD para la autenticación basada en identidades

con Azure Files. Si la autenticación Kerberos de Microsoft Entra de identidades
híbridas no se ajusta a sus requisitos, puede usar una instancia local de Active
Directory Domain Services (AD DS) o Microsoft Entra Domain Services en su
lugar. Los pasos de configuración y los escenarios compatibles de cada método son
distintos.
Se aplica a
Requisitos previos
Antes de habilitar la autenticación Kerberos de Microsoft Entra con SMB en los recursos
compartidos de archivos de Azure, asegúrese de que ha completado los requisitos
previos siguientes.
７ Nota
La cuenta de Azure Storage no se puede autenticar con Microsoft Entra ID y un

segundo método, como AD DS o Microsoft Entra Domain Services. Si ya ha elegido
otro método de AD para la cuenta de almacenamiento, debe deshabilitarlo antes
de habilitar Kerberos de Microsoft Entra.
La funcionalidad de Kerberos de Microsoft Entra para identidades híbridas solo está

disponible en los siguientes sistemas operativos:
Windows 11 Enterprise/Pro de sesión única o múltiple.

Windows 10 Enterprise/Pro de sesión única o múltiple, versiones 2004 o
posteriores con las actualizaciones acumulativas más recientes instaladas,
especialmente KB5007253: versión preliminar de actualización acumulativa 2021-
11 para Windows 10 .
Windows Server, versión 2022 con las actualizaciones acumulativas más recientes
instaladas, especialmente KB5007254: versión preliminar de actualización
acumulativa 2021-11 para la versión 21H2 del sistema operativo del servidor de
Microsoft .
Para obtener información sobre cómo crear y configurar una máquina virtual Windows e
iniciar sesión mediante la autenticación basada en Microsoft Entra ID, consulte Inicio de
sesión en una máquina virtual Windows en Azure mediante Microsoft Entra ID.
Los clientes deben estar unidos a Microsoft Entra o a Microsoft Entra híbrido. No se
admite Kerberos de Microsoft Entra en clientes unidos a Microsoft Entra Domain
Services o unidos solo a AD.
Actualmente, esta característica no admite cuentas de usuario que cree y administre
únicamente en Microsoft Entra ID. Las cuentas de usuario deben ser identidades de
usuario híbridas, lo que significa que también necesitará AD DS y Microsoft Entra
Connect o la sincronización en la nube de Microsoft Entra Connect. Debe crear estas
cuentas en Active Directory y sincronizarlas con Microsoft Entra ID. Para asignar
permisos de control de acceso basado en rol (RBAC) de Azure en el recurso compartido
de archivos de Azure a un grupo de usuarios, debe crear el grupo en Active Directory y
sincronizarlo con Microsoft Entra ID.
Debe deshabilitar la autenticación multifactor (MFA) en la aplicación de Microsoft Entra

que representa la cuenta de almacenamiento.
Con Kerberos de Microsoft Entra, el cifrado de vales de Kerberos siempre es AES-256.

Pero puede establecer el cifrado del canal de SMB que mejor se adapte a sus
necesidades.
Esta característica se admite en las nubes de Azure Public, Azure US Gov y Azure China
21Vianet .
Activación de la autenticación Kerberos de

Microsoft Entra en cuentas de usuario híbridas
La autenticación Kerberos de Microsoft Entra se puede habilitar en Azure Files para
cuentas de usuario híbridas mediante Azure Portal, PowerShell o la CLI de Azure.
Portal
Siga estos pasos para habilitar la autenticación Kerberos de Microsoft Entra

mediante Azure Portal .
1. Inicie sesión en Azure Portal y seleccione la cuenta de almacenamiento para la

que quiere habilitar la autenticación Kerberos de Microsoft Entra.
2. En Almacenamiento de datos, seleccione Recursos compartidos de archivos.
3. Junto a Active Directory, seleccione el estado de configuración (por ejemplo,

No configurado).

4. En Kerberos de Microsoft Entra, seleccione Configurar.
5. Active la casilla Kerberos de Microsoft Entra.
6. Opcional: Si quiere configurar los permisos de directorio y de nivel de archivo

a través de Explorador de archivos de Windows, deberá especificar el nombre
de dominio y el GUID de dominio de la instancia de AD local. Puede obtener
esta información del administrador del dominio o ejecutando el siguiente
cmdlet de PowerShell de Active Directory desde un cliente unido a la instancia
de AD local: Get-ADDomain . El nombre de dominio debe aparecer en la salida
de DNSRoot y el GUID de dominio debe aparecer en ObjectGUID . Si prefiere
configurar los permisos de directorio y de nivel de archivo mediante icacls,
puede omitir este paso. Sin embargo, si quiere usar icacls, el cliente deberá
tener conectividad de red no impedida al AD local.
２ Advertencia
Si ha habilitado previamente la autenticación Kerberos de Microsoft Entra mediante

pasos manuales de versión preliminar limitada para almacenar perfiles de FSLogix
en Azure Files para máquinas virtuales unidas a Microsoft Entra, se establece que la
contraseña de la entidad de servicio de la cuenta de almacenamiento expire cada
seis meses. Una vez que expire la contraseña, los usuarios no podrán obtener vales
de Kerberos para el recurso compartido de archivos. Para mitigarlo, consulte "Error:
la contraseña de la entidad de servicio ha expirado en Microsoft Entra ID" en
Posibles errores cuando se habilita la autenticación Kerberos de Microsoft Entra
para usuarios híbridos.
Concesión de consentimiento del

administrador a la nueva entidad de servicio
Después de habilitar la autenticación Kerberos de Microsoft Entra, deberá conceder de
manera explícita el consentimiento del administrador a la nueva aplicación de Microsoft
Entra que está registrada en el inquilino de Microsoft Entra. Esta entidad de servicio se
genera automáticamente y no se usa para la autorización del recurso compartido de
archivos, por lo que no realice modificaciones en la entidad de servicio que no sean las
documentadas aquí. Si lo hace, podría recibir un error.
Puede configurar los permisos de API desde Azure Portal mediante estos pasos:
1. Abra Microsoft Entra ID.
2. En el panel izquierdo, seleccione Registros de aplicaciones.
3. Seleccione Todas las aplicaciones.
4. Seleccione la aplicación con el nombre [Cuenta de almacenamiento] <your-

storage-account-name> .file.core.windows.net.
5. Seleccione Permisos de API en el panel izquierdo.
6. Seleccione Conceder consentimiento del administrador para [nombre de

directorio] para conceder consentimiento para los tres permisos de API solicitados
(openid, profile y User.Read) para todas las cuentas del directorio.
7. Seleccione Sí para confirmar la acción.
） Importante
Si se conecta a una cuenta de almacenamiento mediante un punto de conexión

privado o un vínculo privado con la autenticación Kerberos de Microsoft Entra,
también deberá agregar el FQDN del vínculo privado a la aplicación de Microsoft
Entra de la cuenta de almacenamiento. Para obtener instrucciones, consulte la
entrada en nuestra guía de solución de problemas.
Deshabilitación de la autenticación multifactor

en la cuenta de almacenamiento
Kerberos de Microsoft Entra no admite el uso de MFA para acceder a recursos
compartidos de archivos de Azure que estén configurados con Kerberos de Microsoft
Entra. Debe excluir la aplicación de Microsoft Entra que representa la cuenta de
almacenamiento de las directivas de acceso condicional de MFA si se aplican a todas las
aplicaciones.
La aplicación de cuenta de almacenamiento debe tener el mismo nombre que la cuenta

de almacenamiento de la lista de exclusión de acceso condicional. Al buscar la
aplicación de cuenta de almacenamiento en la lista de exclusión de acceso condicional,
busque lo siguiente: [Cuenta de almacenamiento] <your-storage-account-
name> .file.core.windows.net.
No olvide reemplazar <your-storage-account-name> por el valor adecuado.
） Importante
Si no excluye las directivas de MFA de la aplicación de cuenta de almacenamiento,

no podrá acceder al recurso compartido. Si intenta asignar el recurso compartido
de archivos mediante net use , se producirá un mensaje de error que indica "Error
del sistema 1327: Las restricciones de cuenta impiden a este usuario iniciar sesión.
Por ejemplo: no se permiten contraseñas en blanco, las horas de inicio de sesión
están limitadas o se aplicó una restricción de directiva".
Para obtener instrucciones sobre cómo deshabilitar MFA, vea lo siguiente:
Incorporación de exclusiones para entidades de servicio de recursos de Azure

Creación de una directiva de acceso condicional
compartido
Cuando habilita el acceso basado en identidades, para cada recurso compartido, puede
establecer los usuarios y grupos que tendrán acceso a ese recurso compartido en
particular. Una vez que a un usuario se le permite acceder a un recurso compartido, las
ACL de Windows (también llamadas permisos NTFS) en archivos y directorios
individuales se encargan de ellos. Esto permite un control específico sobre los permisos,
similar a un recurso compartido SMB en un servidor Windows.
Para establecer permisos de nivel de recurso compartido, siga las instrucciones de

Asignación de permisos de nivel de recurso compartido a una identidad.
Configuración de permisos de directorio y de

nivel de archivo
Una vez implementados los permisos de nivel de recurso compartido, puede asignar
permisos de nivel de directorio o de archivo al usuario o grupo. Para ello debe usarse
un dispositivo con conectividad de red no impedida a un AD local. Para usar el
Explorador de archivos de Windows, el dispositivo también debe estar unido a un
dominio.
Existen dos opciones para configurar los permisos de nivel de directorio y de archivo
con la autenticación Kerberos de Microsoft Entra:
Explorador de archivos de Windows: si elige esta opción, el cliente deberá estar

unido a un dominio de la instancia de AD local.
Utilidad icacls: si elige esta opción, no es necesario que el cliente esté unido a un
dominio, pero necesitará conectividad de red no impedida al AD local.
Para configurar los permisos de los niveles de directorio y de archivo a través del
Explorador de archivos de Windows, también es preciso especificar el nombre de
dominio y el GUID de dominio de la instancia local de AD. Esta información la pueden
proporcionar un administrador de dominio o de cliente unido a una instancia local
de AD. Si prefiere realizar la configuración mediante icacls, este paso no es necesario.
） Importante
Puede establecer ACL de nivel de archivo o directorio para las identidades que no
están sincronizadas con Microsoft Entra ID. Sin embargo, estas ACL no se aplicarán
porque el vale de Kerberos usado para la autenticación o autorización no
contendrá estas identidades no sincronizadas. Para aplicar las ACL establecidas, las
identidades deben estar sincronizadas con Microsoft Entra ID.
 Sugerencia
Si los usuarios unidos a Microsoft Entra híbrido de dos bosques diferentes van a
acceder al recurso compartido, es mejor usar icacls para configurar los permisos de
nivel de directorio y archivo. Esto se debe a que la configuración de ACL de
Explorador de archivos de Windows requiere que el cliente esté unido al dominio
de Active Directory al que está unida la cuenta de almacenamiento.
Para configurar los permisos de directorio y de nivel de archivo, siga las instrucciones de
Configuración de permisos de directorio y de nivel de archivo a través de SMB.
Configuración de los clientes para recuperar

vales de Kerberos
Habilite la funcionalidad de Kerberos de Microsoft Entra en las máquinas cliente desde
las que desee montar o usar recursos compartidos de Azure Files. Debe hacerlo en
todos los clientes en los que se vaya a usar Azure Files.
Utilice uno de estos tres métodos:
Configure este CSP de Policy de Intune y aplíquelo a los clientes:

Kerberos/CloudKerberosTicketRetrievalEnabled se establece en 1
Configure esta directiva de grupo en los clientes: Administrative
Templates\System\Kerberos\Allow retrieving the Azure AD Kerberos Ticket
Granting Ticket during logon
Cree el siguiente valor del Registro en los clientes: reg add

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v
CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1
Los cambios no son instantáneos y requieren una actualización de la directiva o un

reinicio para surtir efecto.
） Importante
Una vez aplicado este cambio, los clientes no podrán conectarse a las cuentas de
almacenamiento configuradas para la integración de AD DS local sin configurar las
asignaciones de dominio de Kerberos. Si desea que los clientes puedan conectarse
a cuentas de almacenamiento configuradas para AD DS, así como a cuentas de
almacenamiento configuradas para Kerberos de Microsoft Entra, siga los pasos
descritos en Configuración de la coexistencia con cuentas de almacenamiento
mediante AD DS local.
Configuración de la coexistencia con cuentas de

almacenamiento mediante AD DS local
Si quiere permitir que las máquinas cliente se conecten a cuentas de almacenamiento
configuradas para AD DS, así como a cuentas de almacenamiento configuradas para
Kerberos de Microsoft Entra, siga estos pasos. Si solo usa Kerberos de Microsoft Entra,
omita esta sección.
Agregue una entrada para cada cuenta de almacenamiento que use la integración de
AD DS local. Use uno de los siguientes tres métodos para configurar las asignaciones de
dominio kerberos. Los cambios no son instantáneos y requieren una actualización de la
directiva o un reinicio para surtir efecto.
Configure esta directiva de Intune CSP y aplíquela a los clientes:

Kerberos/HostToRealm
Template\System\Kerberos\Define host name-to-Kerberos realm mappings
Ejecute el comando de Windows ksetup en los clientes: ksetup /addhosttorealmmap

<hostname> <REALMNAME>
Por ejemplo: ksetup /addhosttorealmmap <your storage account
name>.file.core.windows.net CONTOSO.LOCAL
） Importante
En Kerberos, los nombres de dominio kerberos distinguen mayúsculas de

minúsculas y van en mayúsculas. El nombre del dominio kerberos suele ser el
mismo que el nombre de dominio, en letras mayúsculas.
Deshacer la configuración del cliente para

recuperar vales de Kerberos
Si ya no desea usar una máquina cliente para la autenticación Kerberos de Microsoft
Entra, puede deshabilitar la funcionalidad de Kerberos de Microsoft Entra en esa
máquina. Utilice uno de estos tres métodos:
Configure este CSP de Policy de Intune y aplíquelo a los clientes:

Kerberos/CloudKerberosTicketRetrievalEnabled se establece en 0
Templates\System\Kerberos\Allow retrieving the Azure AD Kerberos Ticket
Granting Ticket during logon
Cree el siguiente valor del Registro en los clientes: reg add

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v
CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 0

Si ha seguido los pasos descritos en Configuración de la coexistencia con cuentas de

almacenamiento mediante AD DS local, como alternativa, puede quitar todos los
nombres de host a las asignaciones de dominio kerberos de la máquina cliente. Utilice
uno de estos tres métodos:
Configure esta directiva de Intune CSP y aplíquela a los clientes:

Kerberos/HostToRealm
Template\System\Kerberos\Define host name-to-Kerberos realm mappings
Ejecute el comando de Windows ksetup en los clientes: ksetup /delhosttorealmmap

<hostname> <realmname>
Por ejemplo: ksetup /delhosttorealmmap <your storage account
name>.file.core.windows.net contoso.local
Puede ver la lista de las asignaciones del nombre de host actual al dominio
kerberos al inspeccionar la clave del Registro
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToReal
m.

） Importante
Una vez aplicado este cambio, los clientes no podrán conectarse a las cuentas de
almacenamiento configuradas para la autenticación Kerberos de Microsoft Entra.
Sin embargo, podrán conectarse a las cuentas de almacenamiento configuradas
para AD DS, sin ninguna configuración adicional.
Deshabilitación de la autenticación de
Microsoft Entra en la cuenta de
almacenamiento
Si quiere usar otro método de autenticación, puede deshabilitar la autenticación de
Microsoft Entra en la cuenta de almacenamiento mediante Azure Portal, Azure
７ Nota
Si deshabilita esta característica, no habrá ninguna configuración de Active

Directory para los recursos compartidos de archivos en la cuenta de
almacenamiento. hasta que habilite uno de los otros orígenes de Active Directory
para restablecer la configuración de Active Directory.
Portal
Siga estos pasos para deshabilitar la autenticación Kerberos de Microsoft Entra en

la cuenta de almacenamiento mediante Azure Portal.
1. Inicie sesión en Azure Portal y seleccione la cuenta de almacenamiento para la

que quiere deshabilitar la autenticación Kerberos de Microsoft Entra.
2. En Almacenamiento de datos, seleccione Recursos compartidos de archivos.
3. Seleccione el estado de configuración junto a Active Directory.
4. En Kerberos de Microsoft Entra, seleccione Configurar.
5. Desactive la casilla Kerberos de Microsoft Entra.
Pasos siguientes
Para obtener más información, vea estos recursos:
Posibles errores cuando se habilita la autenticación Kerberos de Microsoft Entra

para usuarios híbridos
Creación de un contenedor de perfiles con Azure Files y Microsoft Entra ID
P+F
Habilitar la autenticación de Active
Directory sobre SMB para clientes Linux
que acceden a Azure Files
Artículo • 20/10/2023
Para más información sobre las opciones y consideraciones admitidas, consulte

Información general sobre opciones de autenticación basada en identidades de Azure
Files para el acceso SMB.
Azure Files admite la autenticación basada en identidades a través del Bloque de

mensajes del servidor (SMB) para máquinas virtuales (VMs) Linux con el protocolo de
autenticación Kerberos mediante los métodos siguientes:
Windows Active Directory Domain Services (AD DS) local

Para usar la primera opción (AD DS), debe sincronizar AD DS con Microsoft Entra ID
mediante Microsoft Entra Connect.
７ Nota
En este artículo se usa Ubuntu para los pasos de ejemplo. Las configuraciones
similares funcionarán para las máquinas RHEL y SLES, lo que le permite montar
recursos compartidos de archivos de Azure mediante Active Directory.
Se aplica a
Limitaciones del cliente SMB de Linux

No puede usar la autenticación basada en identidades para montar recursos
compartidos de Azure File en clientes Linux en tiempo de arranque mediante entradas
fstab porque el cliente no puede obtener el vale Kerberos lo suficientemente pronto
como para montarse en tiempo de arranque. Sin embargo, puede usar una fstab
entrada y especificar la opción noauto . Esto no montará el recurso compartido en
tiempo de arranque, pero permitirá a un usuario montar convenientemente el recurso
compartido de archivos después de iniciar sesión con un comando de montaje simple
sin todos los parámetros. También puede usar autofs para montar el recurso compartido
tras el acceso.
Prerrequisitos
Antes de habilitar la autenticación de AD sobre SMB para los recursos compartidos de
archivos de Azure, asegúrese de que cumple los siguientes requisitos previos.
Una máquina virtual Linux (Ubuntu 18.04+ o una máquina virtual de RHEL o SLES
equivalente) que se ejecuta en Azure. La máquina virtual debe tener al menos una
interfaz de red en la red virtual que contenga Microsoft Entra Domain Services o
una máquina virtual Linux local con AD DS sincronizado con Microsoft Entra ID.
Credenciales de usuario raíz o usuario en una cuenta de usuario local que tiene
derechos de sudo completos (para esta guía, localadmin).
La máquina virtual Linux no debe haber unido ningún dominio de AD. Si ya forma
parte de un dominio, primero debe dejar ese dominio para poder unirse a este
dominio.
Un inquilino de Microsoft Entra totalmente configurado, con el usuario de dominio
ya configurado.
La instalación del paquete samba no es estrictamente necesaria, pero proporciona

algunas herramientas útiles y trae otros paquetes automáticamente, como samba-common
y smbclient . Ejecute los siguientes comandos para instalarlo. Si se le pide algún valor de
entrada durante la instalación, déjelos en blanco.
Bash
sudo apt update -y

sudo apt install samba winbind libpam-winbind libnss-winbind krb5-config
krb5-user keyutils cifs-utils
La herramienta wbinfo forma parte del conjunto samba. Puede ser útil para fines de
autenticación y depuración, como comprobar si se puede acceder al controlador de
dominio, comprobar a qué dominio está unido una máquina y buscar información sobre
los usuarios.
Asegúrese de que el host de Linux mantiene el tiempo sincronizado con el servidor de
dominio. Consulte la documentación de la distribución de Linux. Para algunas
distribuciones, puede hacerlo mediante systemd-timesyncd . Edite
/etc/systemd/timesyncd.conf con su editor de texto favorito para incluir lo siguiente:
plaintext
[Time]
NTP=onpremaadint.com
FallbackNTP=ntp.ubuntu.com
A continuación, reinicie el servicio:
Bash
sudo systemctl restart systemd-timesyncd.service
Habilitar la autenticación Kerberos de AD

Siga estos pasos para habilitar la autenticación Kerberos de AD. Esta documentación de
Samba puede resultar útil como referencia.
Asegúrese de que el servidor de dominio sea accesible y

detectable
1. Asegúrese de que los servidores DNS proporcionados contienen las direcciones IP
del servidor de dominio.
Bash
systemd-resolve --status
Resultados
Global
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 2 (eth0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 10.0.2.5
10.0.2.4
10.0.0.41
DNS Domain: domain1.contoso.com
2. Si el comando funcionó, omita los pasos siguientes y continúe con la sección

siguiente.
3. Si no funciona, asegúrese de que las direcciones IP del servidor de dominio están

haciendo ping.
Bash
ping 10.0.2.5
Resultados
PING 10.0.2.5 (10.0.2.5) 56(84) bytes of data.

64 bytes from 10.0.2.5: icmp_seq=1 ttl=128 time=0.898 ms
64 bytes from 10.0.2.5: icmp_seq=2 ttl=128 time=0.946 ms
^C
--- 10.0.2.5 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.898/0.922/0.946/0.024 ms
4. Si el ping no funciona, vuelva a los requisitos previos y asegúrese de que la

máquina virtual está en una red virtual que tiene acceso al inquilino de Microsoft
Entra.
5. Si las direcciones IP están haciendo ping pero los servidores DNS no se detectan
automáticamente, puede agregar los servidores DNS manualmente. Edite
/etc/netplan/50-cloud-init.yaml en el editor de texto que prefiera.
plaintext
# This file is generated from information provided by the datasource.

Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
eth0:
dhcp4: true
dhcp4-overrides:
route-metric: 100
dhcp6: false
match:
macaddress: 00:22:48:03:6b:c5
set-name: eth0
nameservers:
addresses: [10.0.2.5, 10.0.2.4]
version: 2
A continuación, aplique los cambios:
Bash
sudo netplan --debug apply
6. Winbind supone que el servidor DHCP mantiene actualizados los registros DNS del
dominio. Sin embargo, esto no es cierto para DHCP de Azure. Para configurar el
cliente para realizar actualizaciones de DDNS, use esta guía para crear un script de
red. Este es un script de ejemplo que reside en /etc/dhcp/dhclient-exit-
hooks.d/ddns-update .
plaintext
#!/bin/sh
# only execute on the primary nic

if [ "$interface" != "eth0" ]
then
return
fi
# When you have a new IP, perform nsupdate

if [ "$reason" = BOUND ] || [ "$reason" = RENEW ] ||
[ "$reason" = REBIND ] || [ "$reason" = REBOOT ]
then
host=`hostname -f`
nsupdatecmds=/var/tmp/nsupdatecmds
echo "update delete $host a" > $nsupdatecmds
echo "update add $host 3600 a $new_ip_address" >> $nsupdatecmds
echo "send" >> $nsupdatecmds
nsupdate $nsupdatecmds
fi
Conectarse a Microsoft Entra Domain Services y

asegúrese de que los servicios se pueden detectar
1. Asegúrese de que puede hacer ping al servidor de dominio por el nombre de
dominio.
Bash
ping contosodomain.contoso.com
Resultados
PING contosodomain.contoso.com (10.0.2.4) 56(84) bytes of data.

64 bytes from pwe-oqarc11l568.internal.cloudapp.net (10.0.2.4): icmp_seq=1
ttl=128 time=1.41 ms
^C
--- contosodomain.contoso.com ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3016ms
rtt min/avg/max/mdev = 0.740/1.026/1.419/0.248 ms
2. Asegúrese de que puede detectar los servicios de Microsoft Entra en la red.
Bash
nslookup
> set type=SRV
> _ldap._tcp.contosodomain.contoso.com.
Resultados
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
_ldap._tcp.contosodomain.contoso.com service = 0 100 389 pwe-

oqarc11l568.contosodomain.contoso.com.
_ldap._tcp.contosodomain.contoso.com service = 0 100 389 hxt4yo--
jb9q529.contosodomain.contoso.com.
Configurar el nombre de host y el nombre de dominio

completo (FQDN)
1. Con el editor de texto, actualice el /etc/hosts archivo con el FQDN final (después
de unir el dominio) y el alias del host. La dirección IP no importa por ahora, ya que
esta línea se usará principalmente para traducir el nombre de host corto a FQDN.
Para obtener más información, consulte Configuración de Samba como miembro
de dominio .
plaintext
127.0.0.1 contosovm.contosodomain.contoso.com contosovm

#cmd=sudo vim /etc/hosts
#then enter this value instead of localhost
"ubuntvm.contosodomain.contoso.com UbuntuVM"
2. Ahora, el nombre de host debe resolverse. Puede omitir la dirección IP a la que

resuelve por ahora. El nombre de host corto debe resolverse en el FQDN.
Bash
getent hosts contosovm
Resultados
127.0.0.1 contosovm.contosodomain.contoso.com contosovm
Bash
dnsdomainname
Resultados
contosodomain.contoso.com
Bash
hostname -f
Resultados
contosovm.contosodomain.contoso.com
７ Nota
Algunas distribuciones requieren que ejecute el hostnamectl comando para que se

actualice el nombre de host -f:
hostnamectl set-hostname contosovm.contosodomain.contoso.com
Configuración de krb5.conf
1. Configure /etc/krb5.conf para que el centro de distribución de claves (KDC) de
Kerberos con el servidor de dominio pueda ser contactado para la autenticación.
Para obtener más información, consulte Documentación de Kerberos MIT . Aquí
tiene un archivo /etc/krb5.conf de muestra.
plaintext
[libdefaults]
default_realm = CONTOSODOMAIN.CONTOSO.COM
dns_lookup_realm = false
dns_lookup_kdc = true
Configuración de smb.conf
1. Identifique la ruta de acceso a smb.conf .
Bash
sudo smbd -b | grep "CONFIGFILE"
Resultados
CONFIGFILE: /etc/samba/smb.conf
2. Cambie la configuración de SMB para que actúe como miembro de dominio. Para
obtener más información, consulte Configuración de Samba como miembro de
dominio . Aquí tiene un archivo smb.conf de muestra.
７ Nota
Este ejemplo es para Microsoft Entra Domain Services, para el que se recomienda
establecer backend = rid al configurar idmap. Es posible que los usuarios de AD
DS locales prefieran elegir un back-end idmap diferente .
plaintext
[global]
workgroup = CONTOSODOMAIN
security = ADS
realm = CONTOSODOMAIN.CONTOSO.COM
winbind refresh tickets = Yes

vfs objects = acl_xattr
map acl inherit = Yes
store dos attributes = Yes
dedicated keytab file = /etc/krb5.keytab

kerberos method = secrets and keytab
winbind use default domain = Yes
load printers = No
printing = bsd
printcap name = /dev/null
disable spoolss = Yes
log file = /var/log/samba/log.%m

log level = 1
idmap config * : backend = tdb
idmap config * : range = 3000-7999
idmap config CONTOSODOMAIN : backend = rid

idmap config CONTOSODOMAIN : range = 10000-999999
template shell = /bin/bash

template homedir = /home/%U
3. Forzar winbind para volver a cargar el archivo de configuración cambiado.
Bash
sudo smbcontrol all reload-config
Unir al dominio
1. Use el comando net ads join para unir el host al dominio de Microsoft Entra
Domain Services. Si el comando produce un error, consulte Solución de problemas
de miembros del dominio samba para resolver el problema.
Bash
sudo net ads join -U contososmbadmin # user - garead
Enter contososmbadmin's password:
Resultados
Using short domain name -- CONTOSODOMAIN

Joined 'CONTOSOVM' to dns domain 'contosodomain.contoso.com'
2. Asegúrese de que el registro DNS existe para este host en el servidor de dominio.
Bash
nslookup contosovm.contosodomain.contoso.com 10.0.2.5
Resultados
Server: 10.0.2.5
Address: 10.0.2.5#53
Name: contosovm.contosodomain.contoso.com
Address: 10.0.0.8
Si los usuarios inician sesión activamente en máquinas cliente o máquinas virtuales y

acceden a los recursos compartidos de archivos de Azure, debe configurar nsswitch.conf
y configurar PAM para winbind. Si el acceso se limitará a las aplicaciones representadas
por una cuenta de usuario o una cuenta de equipo que necesiten autenticación
Kerberos para acceder al recurso compartido de archivos, puede omitir estos pasos.
Configuración de nsswitch.conf
1. Ahora que el host está unido al dominio, debe colocar bibliotecas winbind en los
lugares para buscar al buscar usuarios y grupos. Para ello, actualice las entradas de
grupo y passwd en nsswitch.conf . Use el editor de texto para editar
/etc/nsswitch.conf y agregar las siguientes entradas:
plaintext
passwd: compat systemd winbind

group: compat systemd winbind
2. Habilite el servicio winbind para que se inicie automáticamente al reiniciarse.
Bash
sudo systemctl enable winbind
Resultados
Synchronizing state of winbind.service with SysV service script with

/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable winbind
3. A continuación, reinicie el servicio.
Bash
sudo systemctl restart winbind

sudo systemctl status winbind
Resultados
winbind.service - Samba Winbind Daemon
Loaded: loaded (/lib/systemd/system/winbind.service; enabled; vendor
preset: enabled)
Active: active (running) since Fri 2020-04-24 09:34:31 UTC; 10s ago
Docs: man:winbindd(8)
man:samba(7)
man:smb.conf(5)
Main PID: 27349 (winbindd)
Status: "winbindd: ready to serve connections..."
Tasks: 2 (limit: 4915)
CGroup: /system.slice/winbind.service
├─27349 /usr/sbin/winbindd --foreground --no-process-group
└─27351 /usr/sbin/winbindd --foreground --no-process-group
Apr 24 09:34:31 contosovm systemd[1]: Starting Samba Winbind Daemon...

Apr 24 09:34:31 contosovm winbindd[27349]: [2020/04/24 09:34:31.724211, 0]
../source3/winbindd/winbindd_cache.c:3170(initialize_winbindd_cache)
Apr 24 09:34:31 contosovm winbindd[27349]: initialize_winbindd_cache:
clearing cache and re-creating with version number 2
Apr 24 09:34:31 contosovm winbindd[27349]: [2020/04/24 09:34:31.725486, 0]
../lib/util/become_daemon.c:124(daemon_ready)
Apr 24 09:34:31 contosovm systemd[1]: Started Samba Winbind Daemon.
Apr 24 09:34:31 contosovm winbindd[27349]: STATUS=daemon 'winbindd'
finished starting up and ready to serve connections
4. Asegúrese de que se detectan los usuarios y grupos del dominio.
Bash
getent passwd contososmbadmin
Resultados
contososmbadmin:*:12604:10513::/home/contososmbadmin:/bin/bash
Bash
getent group 'domain users'
Resultados
domain users:x:10513:
Si lo anterior no funciona, compruebe si el controlador de dominio es accesible

mediante la herramienta wbinfo:
Bash
wbinfo --ping-dc
Configuración de PAM para winbind

1. Debe colocar winbind en la pila de autenticación para que los usuarios del dominio
se autentiquen a través de winbind mediante la configuración de PAM (módulo de
autenticación conectable) para winbind. El segundo comando garantiza que el
homedir se crea para un usuario de dominio al iniciar sesión en este sistema.
Bash
sudo pam-auth-update --enable winbind

sudo pam-auth-update --enable mkhomedir
2. Asegúrese de que la configuración de autenticación de PAM tenga los argumentos

siguientes en /etc/pam.d/common-auth :
Bash
grep pam_winbind.so /etc/pam.d/common-auth
Resultados
auth [success=1 default=ignore] pam_winbind.so krb5_auth

krb5_ccache_type=FILE cached_login try_first_pass
3. Ahora debería poder iniciar sesión en este sistema como usuario del dominio, ya
sea a través de ssh, su o cualquier otro medio de autenticación.
Bash
su - contososmbadmin
Password:
Resultados
Creating directory '/home/contososmbadmin'.

contososmbadmin@contosovm:~$ pwd
/home/contososmbadmin
contososmbadmin@contosovm:~$ id
uid=12604(contososmbadmin) gid=10513(domain users) groups=10513(domain
users),10520(group policy creator owners),10572(denied rodc password
replication group),11102(dnsadmins),11104(aad dc
administrators),11164(group-
readwrite),11165(fileshareallaccess),12604(contososmbadmin)
Comprobación de la configuración
Para comprobar que la máquina cliente está unida al dominio, busque el FQDN del
cliente en el controlador de dominio y busque la entrada DNS indicada para este cliente
determinado. En muchos casos, <dnsserver> es el mismo que el nombre de dominio al
que está unido el cliente.
Bash
nslookup <clientname> <dnsserver>
A continuación, use el comando klist para ver los vales en la memoria caché de
Kerberos. Debe haber una entrada que comience con krbtgt y tenga un aspecto similar
al siguiente:
plaintext
krbtgt/CONTOSODOMAIN.CONTOSO.COM@CONTOSODOMAIN.CONTOSO.COM
Si no configuró PAM para winbind, klist es posible que no muestre la entrada del vale.
En este caso, puede autenticar manualmente al usuario para obtener los vales:
Bash
wbinfo -K contososmbadmin
También puede ejecutar el comando como parte de un script:
Bash
wbinfo -K 'contososmbadmin%SUPERSECRETPASSWORD'

Después de habilitar la autenticación Kerberos de AD (o Microsoft Entra ID) y la
máquina virtual Linux unida a un dominio, puede montar el recurso compartido de
archivos.
Para obtener instrucciones de montaje detalladas, consulte Montaje del recurso
compartido de archivos de Azure a petición con montaje.
Use la siguiente opción de montaje adicional con todos los modelos de control de
acceso para habilitar la seguridad de Kerberos: sec=krb5
７ Nota
Esta característica solo admite un modelo de control de acceso aplicado por el

servidor mediante las ACL de NT sin bits de modo. Las herramientas de Linux que
actualizan las ACL de NT son mínimas, así que actualice las ACL a través de
Windows. Los modelos de control de acceso aplicados por el cliente
( modefromsid,idsfromsid ) y el control de acceso traducido por el cliente ( cifsacl )
no se admiten actualmente.
Otras opciones de montaje
Montaje de usuario único frente a multiusuario
En un caso de uso de montaje de usuario único, un único usuario del dominio de AD

accede al punto de montaje y no se comparte con otros usuarios del dominio. Cada
acceso a archivos se produce en el contexto del usuario cuyas credenciales krb5 se
usaron para montar el recurso compartido de archivos. Cualquier usuario del sistema
local que acceda al punto de montaje suplantará a ese usuario.
En un caso de uso de montaje multiusuario, todavía hay un único punto de montaje,

pero varios usuarios de AD pueden acceder a ese mismo punto de montaje. En
escenarios en los que varios usuarios del mismo cliente tendrán acceso al mismo
recurso compartido y el sistema está configurado para Kerberos y montado con
sec=krb5 , considere la posibilidad de usar la opción de montaje multiuser .
Permisos de archivo
Los permisos de archivo son importantes, especialmente si los clientes de Linux y
Windows tendrán acceso al recurso compartido de archivos. Para convertir permisos de
archivo a DACL en archivos, use una opción de montaje predeterminada, como
file_mode=<>,dir_mode=<>. Los permisos de archivo especificados como file_mode y
dir_mode solo se aplican dentro del cliente. El servidor aplica el control de acceso en
función del descriptor de seguridad del archivo o del directorio.
Propiedad del archivo
La propiedad de los archivos es importante, especialmente si los clientes de Linux y
Windows accederán al recurso compartido de archivos. Elija una de las siguientes
opciones de montaje para convertir la propiedad del archivo UID/GID al SID de
propietario o grupo en la DACL del archivo:
Use un valor predeterminado como uid=<>,gid=<>

Configuración de la asignación de UID/GID a través de RFC2307 y Active Directory
(nss_winbind o nss_sssd)
Coherencia de caché de atributos de archivo

El rendimiento es importante, incluso si los atributos de archivo no siempre son
precisos. El valor predeterminado de actimeo es 1 (segundo), lo que significa que los
atributos de archivo se recuperan de nuevo desde el servidor si los atributos
almacenados en caché tienen más de 1 segundo de antigüedad. Aumentar el valor a 60
significa que los atributos se almacenan en caché durante al menos 1 minuto. Para la
mayoría de los casos de uso, se recomienda usar un valor de 30 para esta opción
(actimeo=30).
Para los kernels más recientes, considere la posibilidad de establecer las características
de actimeo de forma más detallada. Puede usar acdirmax para el almacenamiento en
caché de revalidación de entrada de directorio y acregmax para almacenar en caché los
metadatos del archivo, por ejemplo acdirmax=60,acregmax=5.
Pasos siguientes
Para más información sobre cómo montar un recurso compartido de archivos SMB en
Linux, consulte:
Montaje de un recurso compartido de archivos de Azure de SMB en Linux

Elegir cómo autorizar el acceso a los
datos de archivo en Azure Portal
Artículo • 15/11/2023
Cuando se accede a los datos de archivos mediante Azure Portal , este realiza
solicitudes a Azure Files en segundo plano. Estas solicitudes se pueden autorizar
mediante la cuenta de Microsoft Entra o la clave de acceso a la cuenta de
almacenamiento. El portal indica qué método está usando, y le permite alternar entre
ambos si tiene los permisos adecuados.
También puede especificar cómo autorizar una operación de recurso compartido de

archivos individual en Azure Portal. De forma predeterminada, el portal usa el método
que ya esté usando para autorizar todos los recursos compartidos de archivos, pero
tiene la opción de cambiar esta configuración para recursos compartidos de archivos
individuales.
Permisos necesarios para acceder a datos de

archivos
Necesitará permisos específicos según cómo quiera autorizar el acceso a los datos de
archivos en Azure Portal. En la mayoría de los casos, estos permisos se proporcionan a
través del control de acceso basado en roles de Azure (Azure RBAC).
Uso de la cuenta de Microsoft Entra

Para acceder a datos de archivos desde Azure Portal con la cuenta de Microsoft Entra, se
deben cumplir estas dos premisas:
Tiene asignado un rol (ya sea integrado o personalizado) que proporciona acceso
a los datos de archivos.
Tiene asignado como mínimo el rol Lector de Azure Resource Manager, con el
ámbito establecido en el nivel de la cuenta de almacenamiento o en un nivel
superior. El rol Lector concede los permisos más restringidos, pero otro rol de
Azure Resource Manager que conceda acceso a los recursos de administración de
la cuenta de almacenamiento también es aceptable.
El rol Lector de Azure Resource Manager permite a los usuarios ver recursos de la
cuenta de almacenamiento, pero no modificarlos. No proporciona permisos de lectura
en los datos de Azure Storage, sino únicamente en los recursos de administración de la
cuenta. El rol Lector es necesario para que los usuarios puedan navegar a recursos
compartido de archivos en Azure Portal.
Hay dos nuevos roles integrados que tienen los permisos necesarios para acceder a los
datos de archivo con OAuth:
Lector con privilegios de datos de archivos de Storage

Colaborador con privilegios de datos de archivos de Storage
Para obtener información sobre los roles integrados que admiten el acceso a los datos
de archivos, consulte Acceso a recursos compartidos de archivos de Azure mediante
Microsoft Entra ID con OAuth de Azure Files a través de REST.
７ Nota
El rol Colaborador con privilegios de datos de archivos de almacenamiento tiene

permisos para leer, escribir, eliminar y modificar permisos ACL/NTFS en archivos o
directorios de recursos compartidos de archivos de Azure. No se admite la
modificación de ACL o permisos NTFS a través de Azure Portal.
Los roles personalizados pueden admitir diferentes combinaciones de los mismos

permisos que proporcionan los roles integrados. Para obtener más información sobre
cómo crear roles RBAC de Azure personalizados, consulte el artículo sobre roles
personalizados de Azure y la descripción de las definiciones de roles de recursos de
Azure.
Uso de la clave de acceso de la cuenta de

almacenamiento
Para acceder a los datos de archivos con la clave de acceso a la cuenta, debe tener
asignado un rol de Azure que incluya la acción de Azure RBAC
Microsoft.Storage/storageAccounts/listkeys/action. Este rol de Azure puede ser un rol
integrado o personalizado. Los roles integrados que
Microsoft.Storage/storageAccounts/listkeys/action admite son los siguientes,
presentados en orden de permisos mínimos a máximos:
Rol Lector y acceso a los datos

El rol Colaborador de una cuenta de almacenamiento
El rol Colaborador de Azure Resource Manager
El rol Propietario de Azure Resource Manager
Al intentar acceder a los datos de archivos en Azure Portal, este comprueba primero si
tiene asignado un rol con Microsoft.Storage/storageAccounts/listkeys/action. Si se le
ha asignado un rol con esta acción, Azure Portal usa la clave de cuenta de
almacenamiento para tener acceso a los datos de archivos. Si no tiene un rol asignado
con esta acción, el portal intenta acceder a los datos mediante la cuenta de Microsoft
Entra.
） Importante
Cuando una cuenta de almacenamiento está bloqueada con un bloqueo ReadOnly

de Azure Resource Manager, no se permite la operación Crear lista de claves para
esa cuenta de almacenamiento. Crear lista de claves es una operación POST y
todas las operaciones POST se impiden cuando se configura un bloqueo ReadOnly
para la cuenta. Por esta razón, cuando la cuenta está bloqueada con un bloqueo
ReadOnly, los usuarios deben usar las credenciales de Microsoft Entra para acceder
a los datos de archivo en el portal. Para más información sobre el acceso a los
datos de archivos en Azure Portal con Microsoft Entra ID, consulte Uso de la cuenta
de Microsoft Entra.
７ Nota
Los roles clásicos de administrador de suscripciones Administrador de servicios y

Coadministrador equivalen al rol Propietario de Azure Resource Manager. El rol
Propietario engloba todas las acciones, incluida
Microsoft.Storage/storageAccounts/listkeys/action, por lo que un usuario con uno
de estos roles administrativos también puede acceder a datos de archivos con la
clave de cuenta de almacenamiento. Para obtener más información, consulte Roles
de Azure, roles de Microsoft Entra y roles de administrador de suscripción
clásicos .
Especificar cómo autorizar operaciones en un

recurso compartido de archivos específico
Puede cambiar el método de autenticación para recursos compartidos de archivos
individuales. De manera predeterminada, el portal usar el método de autenticación
actual. Para determinar el método de autenticación actual, siga estos pasos.
1. Vaya a la cuenta de almacenamiento en Azure Portal y seleccione Almacenamiento

de datos>Recursos compartidos de archivos en el panel de navegación izquierdo.
2. Seleccione un recurso compartido de archivos.
3. Haga clic en Examinar.
4. El método de autenticación indica si actualmente usa la clave de acceso a la
cuenta de almacenamiento o la cuenta de Microsoft Entra para autenticar y
autorizar las operaciones del recurso compartido de archivos. Si actualmente se
autentica mediante la clave de acceso a la cuenta de almacenamiento, verá Clave
de acceso especificado como método de autenticación, tal como en la siguiente
imagen. Si se autentica mediante la cuenta de Microsoft Entra, verá Cuenta de
usuario de Microsoft Entra especificado en su lugar.
Autentíquese con su cuenta de Microsoft Entra.

Para cambiar mediante la cuenta de Microsoft Entra, seleccione el vínculo resaltado en la
imagen que indica Cambiar a la cuenta de usuario de Microsoft Entra. Si posee los
permisos adecuados a través de los roles de Azure que tiene asignados, podrá
continuar. Sin embargo, si carece de los permisos necesarios, verá un mensaje de error
que indica que no tiene permisos para crear una lista de los datos mediante la cuenta
de usuario con Microsoft Entra ID.
Se requieren dos permisos de RBAC adicionales para usar la cuenta de Microsoft Entra:
Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action
Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/actio
n
La lista no contendrá ningún recurso compartido de archivos si su cuenta de Microsoft

Entra no tiene permisos para verlos.
Autenticación con la clave de acceso de la cuenta de

almacenamiento
Para cambiar mediante la clave de acceso de la cuenta, seleccione el vínculo que indica
Cambiar a clave de acceso. Si tiene acceso a la clave de la cuenta de almacenamiento,
podrá continuar. Sin embargo, si no tiene acceso a la clave de cuenta, verá un mensaje
de error que indica que no tiene permisos para usar la clave de acceso para crear una
lista de los datos.
No aparecen recursos compartidos de archivos en la lista si no tiene acceso a la clave de

acceso de la cuenta de almacenamiento.
El valor predeterminado es la autorización de

Microsoft Entra en Azure Portal
Al crear una cuenta de almacenamiento, puede especificar que Azure Portal realice la
autorización con Microsoft Entra ID de forma predeterminada cuando un usuario vaya a
los datos de archivos. También puede configurar esta opción para una cuenta de
almacenamiento existente. Esta configuración especifica solo el método de autorización
predeterminado. Tenga en cuenta que un usuario puede invalidar esta configuración y
elegir autorizar el acceso a datos con la clave de la cuenta de almacenamiento.
Para especificar que el portal usará la autorización con Microsoft Entra de forma
predeterminada para el acceso a datos al crear una cuenta de almacenamiento, siga
estos pasos:
1. Cree una cuenta de almacenamiento; siga las instrucciones de Creación de una

2. En la pestaña Opciones avanzadas, en la sección Seguridad, seleccione la casilla

situada junto a Autorización predeterminada con Azure Active Directory en
Azure Portal.
3. Seleccione Revisar y crear para ejecutar la validación y crear la cuenta de
almacenamiento.
Para actualizar esta configuración para una cuenta de almacenamiento existente, siga
estos pasos:
1. Vaya a la información general de la cuenta de almacenamiento en Azure Portal.

2. En Configuración, seleccione Configuración.
3. Establezca Autorización predeterminada con Microsoft Entra en Azure Portal en
Activada.
Consulte también
Acceso a recursos compartidos de archivos de Azure mediante Microsoft Entra ID
con OAuth de Azure Files a través de REST
Autorización del acceso a datos en Azure Storage
Habilitación de la eliminación temporal
en recursos compartidos de archivos de
Azure
Artículo • 28/12/2023
Azure Files ofrece la posibilidad de eliminar temporalmente recursos compartidos de

archivos SMB, con el fin de que pueda recuperar fácilmente los datos cuando una
aplicación u otro usuario de la cuenta de almacenamiento los hayan eliminado por
error. Para más información sobre la eliminación temporal, consulte Cómo evitar la
eliminación accidental de recursos compartidos de archivos de Azure.
Se aplica a
ﾉ Expandir tabla
Requisitos previos
Introducción
En las secciones siguientes se muestra cómo habilitar y usar la eliminación temporal
para recursos compartidos de archivos de Azure en una cuenta de almacenamiento
existente:
Portal

2. Vaya a la cuenta de almacenamiento y seleccione Recursos compartidos de
archivos en Almacenamiento de datos.
3. Seleccione Deshabilitado junto a Eliminación temporal. Aparecerá el panel de

Eliminación temporal de la configuración.
4. Seleccione Enabled (Habilitado) para Soft delete for all file shares
(Eliminación temporal para todos los recursos compartidos de archivos).
5. En Período de retención de recursos compartidos de archivos en días, use el

control deslizante para especificar un número entre 1 y 365 días.
6. Seleccione Guardar para confirmar la configuración de retención de datos.
Restauración del recurso compartido de

archivos eliminado temporalmente
Portal
Para restaurar un recurso compartido de archivos eliminado temporalmente:

archivos.
2. En la hoja del recurso compartido de archivos, habilite Show deleted shares
(Mostrar recursos compartidos eliminados) para mostrar los recursos
compartidos que se han eliminado temporalmente.
Se mostrarán los recursos compartidos que se encuentren en estado

Eliminado.
3. Seleccione el recurso compartido y seleccione Recuperar. Esto restaurará el

recurso compartido.
Puede confirmar que el recurso compartido se haya restaurado desde que su

estado cambia a Activo.
Deshabilitación de la eliminación temporal

Si desea dejar de usar la eliminación temporal, siga estas instrucciones. Para eliminar de
forma permanente un recurso compartido de archivos que se ha eliminado
temporalmente, debe recuperarlo, deshabilitar la eliminación temporal y, a continuación,
eliminarlo de nuevo.
Portal

archivos en Almacenamiento de datos.
2. Seleccione Habilitado junto a Eliminación temporal. Aparecerá el panel de

Eliminación temporal de la configuración.
3. Seleccione Disabled (Deshabilitado) para Soft delete for all file shares
(Eliminación temporal para todos los recursos compartidos de archivos).
4. Seleccione Guardar para confirmar la configuración de retención de datos.
Pasos siguientes
Para obtener información sobre otra forma de protección y recuperación de datos,
consulte Introducción a las instantáneas de recursos compartidos de Azure Files.
Cambio en la forma en que se replican
las cuentas de almacenamiento
Artículo • 18/08/2023
Azure Storage siempre almacena varias copias de los datos en la misma zona para que
estén protegidos frente a eventos planeados y no planeados. Por ejemplo, errores
transitorios de hardware, cortes de red o de energía y desastres naturales masivos. La
redundancia garantiza que la cuenta de almacenamiento cumpla el Acuerdo de Nivel de
Servicio (SLA) de Azure Storage , incluso en caso de errores.
En este artículo, aprenderá a cambiar las opciones de replicación de una cuenta de

almacenamiento existente.
Opciones para cambiar el tipo de replicación

Cuatro aspectos de la configuración de redundancia de una cuenta de almacenamiento
determinan cómo se replican los datos y cómo se puede acceder a ellos:
Redundancia local: los datos siempre se replican tres veces dentro de la región
local o primaria (LRS)
Redundancia de zona: si los datos se replican entre diferentes zonas dentro de la
región primaria (LRS frente a ZRS)
Redundancia geográfica: replicación dentro de una sola región "local" o entre una
región primaria y una región secundaria (LRS frente a GRS)
Acceso de lectura (RA): acceso de lectura a la región secundaria cuando se usa
redundancia geográfica (GRS frente a RA-GRS)
Para obtener información general sobre todas las opciones de redundancia, consulte
Redundancia de Azure Storage.
Puede cambiar cómo se replica la cuenta de almacenamiento desde cualquier

configuración de redundancia hasta cualquier otra con algunas limitaciones. Antes de
realizar cambios, revise esas limitaciones junto con los requisitos de tiempo de
inactividad para asegurarse de que tiene un plan que genera el mejor resultado final
dentro de un período de tiempo que se adapte a sus necesidades y que satisfaga los
requisitos de tiempo de actividad.
Hay tres maneras de cambiar la configuración de replicación:
Use Azure Portal, Azure PowerShell o la CLI de Azure para agregar o quitar la
replicación geográfica o el acceso de lectura a la región secundaria.
Realice una conversión para agregar o quitar la redundancia de zona.
Realice una migración manual en escenarios en los que no se admiten las dos
primeras opciones o para asegurarse de que el cambio se completa en un
momento específico.
Si quiere cambiar la redundancia de zona y la replicación geográfica o el acceso de

lectura, se requiere un proceso de dos pasos. La redundancia geográfica y el acceso de
lectura se pueden cambiar al mismo tiempo, pero la redundancia de zona debe
cambiarse por separado. Estos pasos se pueden realizar en cualquier orden.
Tabla de cambios de replicación

En la tabla siguiente se proporciona información general sobre cómo cambiar de
cualquiera de los tipos de replicación a otro.
７ Nota
La migración manual es una opción para cualquier escenario en el que quiera

cambiar la configuración de replicación dentro de las limitaciones para cambiar los
tipos de replicación. Para simplificar la tabla siguiente, la opción de migración
manual se ha omitido.
Conmutación ... a LRS …a GRS/RA-GRS …a ZRS …a GZRS/RA-

6 GZRS 2,6
… desde LRS N/D Uso de Azure Realizar una Cambiar primero a

Portal, conversión2,3,4,5 GRS/RA-GRS1 y,
PowerShell o la luego, realizar una
CLI1,2 conversión a
GZRS/RA-GZRS
3,4,5
… desde Uso del Azure N/D Cambiar primero a Realizar una

GRS/RA-GRS Portal, LRS y, luego, conversión3,5
PowerShell o realizar una
CLI conversión a ZRS
3,5
... desde ZRS Realizar una Cambiar primero N/D Usar Azure Portal,
conversión3 a GZRS/RA- PowerShell o la
GZRS1 y, luego, CLI1
realizar una
conversión a
GRS/RA-GRS3
Conmutación ... a LRS …a GRS/RA-GRS …a ZRS …a GZRS/RA-
6 GZRS 2,6
… desde Cambiar Realizar una Uso del Azure N/D

GZRS/RA- primero a ZRS conversión3 Portal, PowerShell
GZRS y, luego, o CLI
realizar una
conversión a
LRS 3
1
Al agregar redundancia geográfica genera un cargo de salida único.
2
Si la cuenta de almacenamiento contiene blobs en el nivel de archivo, revise las
limitaciones del nivel de acceso antes de cambiar el tipo de redundancia por la
redundancia geográfica o de zona.
3
El tipo de conversión admitido depende del tipo de cuenta de almacenamiento. Para
más información, consulte la tabla de la cuenta de almacenamiento.
4
No se admite la conversión a ZRS o GZRS para una cuenta LRS resultante de una
conmutación por error. Para más información, consulte Conmutación por error y
conmutación por recuperación.
5 La conversión de LRS a ZRS no se admite si la compatibilidad con el protocolo NFSv3
está habilitada para Azure Blob Storage o si la cuenta de almacenamiento contiene
recursos compartidos de Azure Files NFSv4.1.
6 Aunque la habilitación de la redundancia geográfica parezca producirse
instantáneamente, la conmutación por error a la región secundaria no se puede iniciar
hasta que se haya completado la sincronización de datos entre las dos regiones.
Cambio del valor de la replicación

En función del escenario de la tabla de cambios de replicación, use uno de los métodos
siguientes para cambiar la configuración de replicación.
Cambio de la configuración de replicación mediante el

portal, PowerShell o la CLI
En la mayoría de los casos, puede usar la Azure Portal, PowerShell o la CLI de Azure para
cambiar la configuración de replicación con redundancia geográfica o de acceso de
lectura (RA) para una cuenta de almacenamiento. Si va a iniciar una conversión de
redundancia de zona, puede cambiar la configuración desde dentro de la Azure Portal,
pero no desde PowerShell o la CLI de Azure.
El cambio en la forma en que se replica la cuenta de almacenamiento en Azure Portal no

conlleva un tiempo de inactividad para sus aplicaciones, incluidos los cambios que
requieren una conversión.
Portal
Para cambiar la opción de redundancia de la cuenta de almacenamiento en Azure

Portal, siga estos pasos:
1. Vaya a la cuenta de almacenamiento en Azure Portal.
2. En Administración de datos, seleccione Redundancia.
3. Actualice la configuración Redundancia.
Realizar una conversión

Una "conversión" de redundancia es el proceso de cambiar el aspecto de la redundancia
de zona de una cuenta de almacenamiento.
Durante una conversión, no hay pérdida de datos ni es necesario interrumpir la

aplicación.
Hay dos maneras de iniciar una conversión:
Iniciado por el cliente

Soporte técnico solicitado
 Sugerencia
Microsoft recomienda usar, siempre que sea posible, la conversión iniciada por el
cliente en lugar de la conversión solicitada por el soporte técnico. Con la
conversión iniciada por el cliente, puede iniciar y supervisar el progreso de la
solicitud de conversión directamente desde Azure Portal, y no es necesario abrir y
administrar una solicitud de soporte técnico.
Conversión iniciada por el cliente

La conversión iniciada por el cliente agrega una nueva opción para que los clientes
inicien una conversión. Ahora, en lugar de tener que abrir una solicitud de soporte
técnico, los clientes pueden iniciar y supervisar la conversión directamente desde Azure
Portal. Una vez iniciada, la conversión puede tardar hasta 72 horas en comenzar
realmente, pero se eliminan posibles retrasos relacionados con la apertura y
administración de una solicitud de soporte técnico.
７ Nota
No hay ningún Acuerdo de Nivel de Servicio para completar una conversión

iniciada por el cliente.
La conversión iniciada por el cliente solo está disponible desde el Azure Portal, no desde
PowerShell ni la CLI de Azure. Para iniciar la conversión, realice los mismos pasos que se
usan para cambiar otras opciones de configuración de replicación en la Azure Portal tal
y como se describe en Cambio de la configuración de replicación mediante el portal,
PowerShell o la CLI.
La conversión iniciada por el cliente no está disponible en todas las regiones. Consulte
las limitaciones de la región para más información.
Supervisión del progreso de la conversión iniciada por el cliente
El estado de la conversión iniciada por el cliente se muestra en la página Redundancy

de la cuenta de almacenamiento:

A medida que se evalúa y procesa la solicitud de conversión, el estado debe avanzar por
la lista que se muestra en la tabla siguiente:
Status Explicación
Enviado para La solicitud de conversión se envió correctamente para su

conversión procesamiento.
En curso1 Se ha iniciado la conversión real.
Completado La conversión se ha completado correctamente.

-o- -o-
Error2 Error de conversión.
1
Una vez iniciada, la conversión puede tardar hasta 72 horas en comenzar realmente. Si
la conversión no especifica el estado "En curso" en un plazo de 96 horas después de
iniciar la solicitud, envíe una solicitud de soporte técnico a Microsoft para determinar el
motivo.
2
Si se produce un error en la conversión, envíe una solicitud de soporte técnico a
Microsoft para determinar el motivo.
７ Nota
Aunque Microsoft se encarga de su solicitud de conversión sin demora, no hay

garantía de cuándo se completará. Si necesita que sus datos se conviertan antes de
una fecha determinada, se recomienda realizar una migración manual.
Por lo general, cuantos más datos tenga en su cuenta, más tiempo tardará en
replicar esos datos en otras zonas de la región.
Conversión solicitada por soporte técnico
Los clientes todavía pueden solicitar una conversión abriendo una solicitud de soporte
técnico con Microsoft.
 Sugerencia
Si necesita convertir más de una cuenta de almacenamiento, cree una incidencia de

soporte única y especifique los nombres de las cuentas a convertir en la pestaña
Detalles adicionales.
Siga estos pasos para solicitar una conversión de Microsoft:
1. En Azure Portal, vaya a la cuenta de almacenamiento que quiere convertir.
2. En Soporte técnico y solución de problemas, elija Nueva solicitud de soporte

técnico.
3. Complete la pestaña Descripción del problema según la información de su cuenta:
Resumen: (texto descriptivo).

Tipo de problema: seleccione Técnico.
Suscripción: Seleccione la suscripción en la lista desplegable.
Servicio: seleccione Mis servicios y después Administración de cuentas de
almacenamiento para el Tipo de servicio.
Recurso: seleccione una cuenta de almacenamiento para convertir. Si
necesita especificar varias cuentas de almacenamiento, puede hacerlo en la
pestaña Detalles adicionales.
Tipo de problema: elija Migración de datos.
Subtipo de problema: elija Migrate to ZRS, GZRS, or RA-GZRS (Migrar a
ZRS, GZRS o RA-GZRS).

4. Seleccione Next (Siguiente). Es posible que la pestaña Solución recomendada se

muestre brevemente antes de cambiar a la página Soluciones. En la página
Soluciones, puede comprobar si las cuentas de almacenamiento son aptas para la
conversión:
Tipo de replicación de destino: (elija la opción deseada en la lista

desplegable).
Cuentas de almacenamiento de: (escriba un nombre de cuenta de
almacenamiento único o una lista de cuentas separadas por punto y coma).
Seleccione Submit (Enviar).

5. Realice la acción adecuada si los resultados indican que la cuenta de

almacenamiento no es apta para la conversión. Si es apta, seleccione Volver a la
solicitud de soporte técnico.
6. Seleccione Next (Siguiente). Si tiene más de una cuenta de almacenamiento para

migrar, en la pestaña Detalles, especifique el nombre de cada cuenta separado por
punto y coma.

7. Rellene la información adicional requerida en la pestaña Detalles adicionales y, a
continuación, seleccione Revisar y crear para revisar y enviar su incidencia de
soporte técnico. Un responsable de soporte técnico se pondrá en contacto con
usted para proporcionarle la asistencia que necesite.
Migración manual
Una migración manual proporciona más flexibilidad y control que una conversión.
Puede usar esta opción si necesita mover los datos en una fecha determinada o si la
conversión no se admite en su escenario. La migración manual también es útil al mover
una cuenta de almacenamiento a otra región. Consulte Mover una cuenta de Azure
Storage a otra región para obtener más detalles.
La migración manual debe realizarse en los siguientes casos:
Quiere migrar la cuenta de almacenamiento a otra región.

La cuenta de almacenamiento es una cuenta de blob en bloques.
La cuenta de almacenamiento incluye datos en el nivel de archivo y no se desea
rehidratar los datos.
） Importante
Una migración manual puede provocar tiempos de inactividad de la aplicación. Si

su aplicación requiere alta disponibilidad, Microsoft también ofrece una opción de
conversión. Una conversión es una migración in situ sin tiempo de inactividad.
Con una migración manual, copia los datos de la cuenta de almacenamiento existente
en una nueva cuenta de almacenamiento. Para realizar una migración manual, puede
usar una de las siguientes opciones:
Copie los datos mediante una herramienta existente como AzCopy, una de las
bibliotecas cliente de Azure Storage o una herramienta de terceros de confianza.
Si conoce Hadoop o HDInsight, puede asociar tanto la cuenta de almacenamiento
de origen como la de destino a su clúster. Después, realice un paralelismo del
proceso de copia de datos con una herramienta como DistCp.
Para obtener instrucciones más detalladas sobre cómo realizar una migración manual,
consulte Traslado de una cuenta de Azure Storage a otra región.
Limitaciones para cambiar los tipos de

replicación
Las limitaciones se aplican a algunos escenarios de cambio de replicación en función de:
Región
Conflictos de características
Tipo de cuenta de almacenamiento
Nivel de acceso
Compatibilidad con protocolos
Conmutación por error y conmutación por recuperación
Region
Asegúrese de que la región donde se encuentra la cuenta de almacenamiento admite
toda la configuración de replicación deseada. Por ejemplo, si va a convertir la cuenta en
con redundancia de zona (ZRS, GZRS o RA-GZRS), asegúrese de que la cuenta de
almacenamiento está en una región que la admita. Consulte las listas de regiones
admitidas para almacenamiento con redundancia de zona y almacenamiento con
redundancia de zona geográfica.
） Importante
La conversión iniciada por el cliente de LRS a ZRS está disponible en todas las
regiones públicas que admiten ZRS, excepto en las siguientes:
(Europa) Oeste de Europa

(Europa) Sur de Reino Unido
(Norteamérica) Centro de Canadá
(Norteamérica) Este de EE. UU.
(Norteamérica) Este de EE. UU. 2
La conversión iniciada por el cliente de cuentas de ZRS existentes a LRS está

disponible en todas las regiones públicas.
Conflictos de características
Algunas características de la cuenta de almacenamiento no son compatibles con otras
características o operaciones. Por ejemplo, la capacidad de conmutar por error a la
región secundaria es la característica clave de redundancia geográfica, pero otras
características no son compatibles con la conmutación por error. Para obtener más
información sobre las características y los servicios que no se admiten con la
conmutación por error, consulte Características y servicios no admitidos. La conversión
de una cuenta a GRS, GZRS o RA-GZRS podría bloquearse si se habilita una
característica en conflicto o podría ser necesario deshabilitar la característica más
adelante antes de iniciar una conmutación por error.
Tipo de cuenta de almacenamiento

Al planear cambiar la configuración de replicación, tenga en cuenta las siguientes
limitaciones relacionadas con el tipo de cuenta de almacenamiento.
Algunos tipos de cuenta de almacenamiento solo admiten determinadas

configuraciones de redundancia, lo que afecta a si se pueden convertir o migrar y, si es
así, cómo. Para más información sobre los tipos de cuenta de almacenamiento de Azure
y las opciones de redundancia admitidas, consulte la introducción a la cuenta de
almacenamiento.
En la tabla siguiente se proporciona información general sobre las opciones de

redundancia disponibles para los tipos de cuenta de almacenamiento y si se admiten la
conversión y la migración manual:
Tipo de cuenta de Admite Admite Admite la Admite la Admite la

almacenamiento LRS ZRS conversión conversión migración
(En el (por solicitud manual
portal) de soporte
técnico)
De uso general ✅ ✅ ✅ ✅ ✅
estándar, v2
Recursos compartidos ✅ ✅ ✅1 ✅
de archivos Prémium
Blobs en bloques ✅ ✅ ✅
Premium
Blob en páginas ✅
Premium
Discos administrados2 ✅ ✅ ✅ ✅
3
De uso general, ✅ ✅
estándar, v1
ZRS clásico 4 ✅
(disponible en cuentas
estándar de uso general v1)
1
La conversión de recursos compartidos de archivos prémium solo está disponible
cuando se abre una solicitud de soporte técnico; actualmente no se admite la
conversión iniciada por el cliente.
2 Los discos administrados están disponibles para LRS y ZRS, aunque los discos ZRS
tienen algunas limitaciones. Si un disco LRS es regional (sin zona especificada), se puede
convertir cambiando la SKU. Si un disco LRS es zonal, solo se puede migrar
manualmente siguiendo el proceso de Migración de los discos administrados. Puede
almacenar instantáneas e imágenes de discos administrados SSD estándar en un
almacenamiento HDD estándar y elegir entre las opciones LRS y ZRS . Para más
información sobre la integración con conjuntos de disponibilidad, consulte Introducción
a los discos administrados de Azure.
3 Si la cuenta de almacenamiento es v1, deberá actualizarla a v2 antes de realizar una
conversión. Para información sobre cómo actualizar la cuenta v1, consulte Actualización
a una cuenta de almacenamiento de uso general v2.
4 Las cuentas de almacenamiento clásicas de ZRS han quedado en desuso. Para obtener
información sobre la conversión de cuentas de ZRS Classic, consulte Conversión de
cuentas de ZRS Classic.
Conversión de cuentas ZRS Classic
） Importante
Las cuentas de ZRS Classic han quedado en desuso el 31 de marzo de 2021. Los
clientes ya no pueden crear cuentas ZRS Classic. Si todavía tiene algunas, debe
actualizarlas a cuentas de uso general v2.
ZRS clásico solo estaba disponible para blobs en bloques de cuentas de

almacenamiento de uso general V1 (GPv1). Para más información sobre las cuentas de
almacenamiento, vea Introducción a las cuentas de Azure Storage.
Las cuentas de ZRS Classic replican los datos de forma asíncrona entre los centros de
datos de una o dos regiones. Los datos replicados no estaban disponibles a menos que
Microsoft iniciara una conmutación por error al secundario. Una cuenta de ZRS clásico
no puede convertirse a o desde LRS, GRS o RA-GRS. Las cuentas de ZRS clásico no
admiten ni las métricas ni el registro.
Para cambiar ZRS Classic a otro tipo de replicación, use uno de los métodos siguientes:
Actualizarlo a ZRS primero

Migración manual de los datos directamente a otro tipo de replicación
Para actualizar su cuenta de almacenamiento ZRS Classic a ZRS, utilice el Azure Portal,
PowerShell o la CLI de Azure en las regiones donde ZRS está disponible:
Portal
Para actualizar a ZRS en Azure Portal, vaya a las opciones de Configuración de la

cuenta y elija Actualizar:
Para migrar manualmente los datos de la cuenta de ZRS Classic a otro tipo de
replicación, siga los pasos para realizar una migración manual.
Si desea migrar sus datos a una cuenta de almacenamiento redundante por zonas
situada en una región diferente a la cuenta de origen, debe realizar una migración
manual. Para más detalles, consulte Mover una cuenta de Azure Storage a otra región.
Nivel de acceso
Asegúrese de que la opción de replicación deseada admite el nivel de acceso que se usa
actualmente en la cuenta de almacenamiento. Por ejemplo, las cuentas de
almacenamiento ZRS, GZRS y RA-GZRS no admiten actualmente el nivel de archivo. Vea
Niveles de acceso frecuente, esporádico y de archivo para los datos de blobs para
obtener más detalles. Para convertir una cuenta LRS, GRS o RA-GRS en una que admita
redundancia de zona, mueva primero los blobs archivados a una cuenta de
almacenamiento que admita blobs en el nivel de archivo. A continuación, convierta la
cuenta de origen en ZRS, GZRS y RA-GZRS.
Para cambiar una cuenta de almacenamiento LRS que contiene blobs en el nivel de
archivo a GRS o RA-GRS, primero debe rehidratar todos los blobs archivados al nivel de
acceso frecuente o esporádico o realizar una migración manual.
 Sugerencia
Microsoft recomienda no cambiar la configuración de redundancia de una cuenta

de almacenamiento que contenga blobs archivados si es posible, ya que las
operaciones de rehidratación pueden ser costosas y lentas. Pero si debe cambiarla,
una migración manual puede ahorrarle el gasto de rehidratación.
Compatibilidad con protocolos

No se admite la conversión de la cuenta de almacenamiento a redundancia de zona
(ZRS, GZRS o RA-GZRS) si se cumple alguna de las siguientes condiciones:
La compatibilidad con el protocolo NFSv3 está habilitada para Azure Blob Storage.
La cuenta de almacenamiento contiene recursos compartidos de Azure
Files NFSv4.1.
Conmutación por error y conmutación por recuperación

Después de una conmutación por error de la cuenta a la región secundaria, es posible
iniciar una conmutación por recuperación desde la nueva región primaria a la nueva
región secundaria con PowerShell o CLI de Azure (versión 2.30.0 o posterior). Para más
información, consulte Precaución al conmutar por recuperación en la región primaria
original.
Si realizó una conmutación por error de la cuenta GRS o RA-GRS, la cuenta es

redundante localmente (LRS) en la nueva región primaria después de la conmutación
por error. No se admite la migración a ZRS o GZRS de una cuenta LRS que resulte de
una conmutación por error. Esto se cumple incluso en el caso de las denominadas
operaciones de conmutación por recuperación. Por ejemplo, si realiza la conmutación
por error de una cuenta de RA-GRS a LRS en la región secundaria y, luego, la configura
de nuevo como RA-GRS, será LRS en la nueva región secundaria (la primaria original). Si
luego realiza otra conmutación por error de la cuenta para volver a la región primaria
original, será de nuevo LRS en esta. En este caso, no se puede realizar una conversión a
ZRS, GZRS o RA-GZRS en la región primaria. En su lugar, tendrá que realizar una
migración manual para agregar redundancia de zona.
Requisitos de tiempo de inactividad

Durante una conversión, puede acceder a los datos de su cuenta de almacenamiento sin
pérdida de durabilidad o disponibilidad. El Acuerdo de Nivel de Servicio de Azure
Storage se mantiene durante el proceso de migración y no hay pérdida de datos
asociada a una conversión. Los puntos de conexión de servicio, las claves de acceso, las
firmas de acceso compartido y otras opciones de la cuenta permanecen inalteradas
después de la migración.
Si decide realizar una migración manual, se requiere tiempo de inactividad, pero tiene
más control sobre el tiempo del proceso de migración.
Tiempo y frecuencia
Si inicia la conversión de una redundancia de zona desde Azure Portal, el proceso puede
tardar hasta 72 horas en comenzar. Puede tardar más tiempo en iniciarse si solicita una
conversión abriendo una solicitud de soporte técnico. Si la conversión iniciada por el
cliente no especifica el estado "En curso" en un plazo de 96 horas después de iniciar la
solicitud, envíe una solicitud de soporte técnico a Microsoft para determinar el motivo.
Para supervisar el progreso de una conversión iniciada por el cliente, consulte
Supervisión del progreso de la conversión iniciada por el cliente.
No hay ningún Acuerdo de Nivel de Servicio para completar una conversión. Si necesita
más control sobre cuándo comienza y finaliza una conversión, considere la posibilidad
de realizar una migración manual. Por lo general, cuantos más datos tenga en su cuenta,
más tiempo tardará en replicar esos datos en otras zonas de la región.
Después de una conversión de redundancia de zona, debe esperar al menos 72 horas

antes de volver a cambiar la configuración de redundancia de la cuenta de
almacenamiento. La suspensión temporal permite que los procesos en segundo plano
se completen antes de realizar otro cambio, lo que garantiza la coherencia y la
integridad de la cuenta. Por ejemplo, pasar de LRS a GZRS es un proceso de 2 pasos.
Debe agregar redundancia de zona en una operación y, a continuación, agregar
redundancia geográfica en un segundo. Después de pasar de LRS a ZRS, debe esperar al
menos 72 horas antes de pasar de ZRS a GZRS.
Costos asociados a la modificación de la forma
en que se replican los datos
Si se ordenan de la más económica a la más costosa, las ofertas de redundancia de
Azure Storage son LRS, ZRS, GRS, RA-GRS, GZRS y RA-GZRS.
Los costos asociados al cambio de cómo se replican los datos en la cuenta de

almacenamiento dependen de los aspectos de la configuración de redundancia que
cambie. Una combinación de precios de almacenamiento de datos y ancho de banda de
salida determinan el costo de realizar un cambio. Para más información sobre precios,
consulte la página de precios de Azure Storage .
Si agrega redundancia de zona en la región primaria, no hay ningún costo inicial

asociado a realizar esa conversión, pero el costo de almacenamiento de datos continuo
será mayor debido a la replicación adicional y al espacio de almacenamiento necesario.
Si agrega redundancia geográfica, incurrirá en un cargo de ancho de banda de salida en

el momento del cambio porque toda la cuenta de almacenamiento se replica en la
región secundaria. Todas las escrituras posteriores en la región primaria también
incurren en cargos de ancho de banda de salida para replicar la escritura en la región
secundaria.
Si quita la redundancia geográfica (cambia de GRS a LRS), no hay ningún costo por
realizar el cambio, pero los datos replicados se eliminan de la ubicación secundaria.
） Importante
Si quita el acceso de lectura a la región secundaria (RA) (cambia de RA-GRS a GRS

o LRS), esa cuenta se factura como RA-GRS durante 30 días más después de la
fecha de conversión.
Consulte también
Redundancia de Azure Storage
Traslado de una cuenta de Azure Storage a otra región
almacenamiento
Comprobación de la propiedad Hora de
la última sincronización de una cuenta
de almacenamiento
Artículo • 02/08/2023
Cuando se configura una cuenta de almacenamiento, se puede definir que los datos se
copien en una región secundaria que se encuentra a cientos de kilómetros de la región
primaria. La replicación geográfica proporciona durabilidad para los datos en caso de
que se produzca una interrupción importante en la región primaria, como un desastre
natural. Si, además, habilita el acceso de lectura a la región secundaria, los datos
seguirán disponibles para las operaciones de lectura si la región primaria deja de estar
disponible. Puede diseñar la aplicación para que cambie sin problemas a la lectura
desde la región secundaria si la región primaria no responde.
Tanto el almacenamiento con redundancia geográfica (GRS) como el almacenamiento

con redundancia de zona geográfica (GZRS) replican los datos de forma asincrónica en
una región secundaria. Para obtener acceso de lectura a la región secundaria, habilite el
almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) o el
almacenamiento con redundancia de zona geográfica con acceso de lectura (RA-GZRS).
Para obtener más información sobre las diversas opciones de redundancia que se
ofrecen en Azure Storage, consulte Redundancia de Azure Storage.
En este artículo se describe cómo comprobar la propiedad Hora de la última

sincronización de la cuenta de almacenamiento para que pueda evaluar cualquier
discrepancia entre las regiones primaria y secundaria.
Acerca de la propiedad Hora de la última

sincronización
Dado que la replicación geográfica es asincrónica, es posible que los datos escritos en la
región primaria no se hayan escrito aún en la región secundaria en el momento en que
se produce un apagón. La propiedad Last Sync Time indica la hora más reciente en que
se garantiza que los datos de la región primaria se escribieron en la secundaria. Para las
cuentas que tienen un espacio de nombres jerárquico, la misma propiedad Hora de
última sincronización también se aplica a los metadatos administrados por el espacio
de nombres jerárquico, incluidas las ACL. Todos los datos y metadatos escritos antes de
la hora de la última sincronización están disponibles en la región secundaria, mientras
que es posible que los datos y metadatos escritos después de la hora de la última
sincronización no se hayan escrito en la secundaria y pueden haberse perdido. Use esta
propiedad si se produce una interrupción para calcular la cantidad de datos perdidos
que puede haber al iniciar la conmutación por error de una cuenta.
La propiedad Hora de la última sincronización es un valor de fecha y hora GMT.
Obtención de la propiedad Hora de la última

sincronización
Puede usar PowerShell o la CLI de Azure para recuperar el valor de la propiedad Hora
de la última sincronización.
PowerShell
Para obtener la hora de la última sincronización de la cuenta de almacenamiento

con PowerShell, instale la versión 1.11.0 o posterior del módulo Az.Storage .A
continuación, compruebe la propiedad GeoReplicationStats.LastSyncTime de la
cuenta de almacenamiento. Recuerde reemplazar los valores de marcador de
posición por los propios:
PowerShell
$lastSyncTime = $(Get-AzStorageAccount -ResourceGroupName <resource-

group> `
-Name <storage-account> `
-IncludeGeoReplicationStats).GeoReplicationStats.LastSyncTime
Consulte también
Redundancia de Azure Storage
Cambio de la opción de redundancia para una cuenta de almacenamiento
Inicio de una conmutación por error de
Artículo • 20/10/2023
Si, por cualquier motivo, el punto de conexión principal de la cuenta de almacenamiento

con redundancia geográfica deja de estar disponible, puede iniciar una conmutación por
error de la cuenta. Una conmutación por error de la cuenta actualiza el punto de
conexión secundario para convertirlo en el punto de conexión principal de la cuenta de
almacenamiento. Una vez finalizada la conmutación por error, los clientes pueden
empezar a escribir en la nueva región primaria. La conmutación por error forzada le
permite mantener una alta disponibilidad para sus aplicaciones.
En este artículo se muestra cómo iniciar una conmutación por error de la cuenta de
almacenamiento mediante Azure Portal, PowerShell o la CLI de Azure. Para más
información sobre la conmutación por error de la cuenta, consulte Recuperación ante
desastres y conmutación por error de la cuenta de almacenamiento.
２ Advertencia
Una conmutación por error de la cuenta tiene normalmente como resultado la

pérdida de datos. Para comprender las implicaciones de una conmutación por error
de una cuenta y prepararse para la pérdida de datos, revise Pérdida de datos e
incoherencias.
７ Nota

Prerrequisitos
Para poder realizar una conmutación por error de su cuenta de almacenamiento,
asegúrese de lo siguiente:
＂ La cuenta de almacenamiento está configurada para la replicación geográfica (GRS,

GZRS, RA-GRS o RA-GZRS). Para más información sobre la redundancia de Azure
Storage, consulte Redundancia de Azure Storage.
＂ El tipo de la cuenta de almacenamiento admite la conmutación por error iniciada
por el cliente. Consulte Tipos de cuenta de almacenamiento admitidos.
＂ La cuenta de almacenamiento no tiene ninguna característica o servicios habilitados
que no sean compatibles con la conmutación por error de la cuenta. Consulte
Características y servicios no admitidos para obtener una lista detallada.
Inicio de la conmutación por error

Puede iniciar una conmutación por error de cuenta desde Azure Portal, PowerShell o la
CLI de Azure.
７ Nota

Portal
Para iniciar una conmutación por error de la cuenta desde Azure Portal, siga estos
pasos:
1. Vaya a la cuenta de almacenamiento.
2. En Configuración, seleccione Replicación geográfica. En la imagen siguiente

se muestra el estado de la replicación geográfica y de la conmutación por
error de una cuenta de almacenamiento.
3. Compruebe que la cuenta de almacenamiento está configurada para el
almacenamiento con redundancia geográfica (GRS) o el almacenamiento con
redundancia geográfica con acceso de lectura (RA-GRS). Si no es así,
seleccione Configuración en Configuración para actualizar su cuenta a fin de
que tenga redundancia geográfica.
4. La propiedad Hora de la última sincronización indica a qué distancia está la

región secundaria de la primaria. El valor de Hora de la última sincronización
proporciona una estimación del alcance de la pérdida de datos que
experimentará una vez finalizada la conmutación por error. Para más
información sobre cómo comprobar la propiedad Hora de la última
actualización, consulte Comprobación de la propiedad Hora de la última
sincronización de una cuenta de almacenamiento.
5. Seleccione Preparar la conmutación por error.
6. Revise el cuadro de diálogo de confirmación. Cuando esté listo, escriba Sí para

confirmar e iniciar la conmutación por error.
Implicaciones importantes de la conmutación
por error de la cuenta
Cuando se inicia una conmutación por error de la cuenta de almacenamiento, se
actualizan los registros DNS del punto de conexión secundario para que pase a ser el
punto de conexión principal. Asegúrese de comprender el posible efecto para la cuenta
de almacenamiento antes de iniciar una conmutación por error.
Para calcular el alcance de la posible pérdida de datos antes de iniciar una conmutación
por error, compruebe la propiedad Hora de la última sincronización. Para más
información sobre cómo comprobar la propiedad Hora de la última actualización,
consulte Comprobación de la propiedad Hora de la última sincronización de una cuenta
de almacenamiento.
El tiempo que se tarda en realizar la conmutación por error después del inicio puede
variar, aunque por lo general tarda menos de una hora.
Después de la conmutación por error, el tipo de cuenta de almacenamiento se convierte
automáticamente en almacenamiento con redundancia local (LRS) en la nueva región
primaria. Puede volver a habilitar el almacenamiento con redundancia geográfica (GRS)
o el almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) para
la cuenta. Tenga en cuenta que la conversión de LRS a GRS o a RA-GRS supone un costo
adicional. El costo se debe a los cargos de salida de red para volver a replicar los datos
en la nueva región secundaria. Para más información, consulte Detalles de precios de
ancho de banda .
Después de volver a habilitar GRS para la cuenta de almacenamiento, Microsoft

comienza a replicar los datos de la cuenta en la nueva región secundaria. El tiempo de
replicación depende de muchos factores, entre otros:
El número y el tamaño de los objetos en la cuenta de almacenamiento. Muchos

objetos pequeños pueden tardar más de menos objetos más grandes.
Los recursos disponibles para la replicación en segundo plano, como CPU,
memoria, disco y capacidad WAN. El tráfico en directo tiene prioridad sobre la
replicación geográfica.
Si usa Blob Storage, el número de instantáneas por blob.
Si usa Table Storage, la estrategia de creación de particiones de datos. El proceso
de replicación no se puede escalar más allá del número de claves de partición que
se usan.
Pasos siguientes
Recuperación ante desastres y conmutación por error de la cuenta de
almacenamiento
almacenamiento
Tutorial: Creación de una aplicación de alta disponibilidad con Blob Storage
Copia de seguridad de recursos
Artículo • 19/03/2023
En este artículo se describe cómo realizar copias de seguridad de recursos compartidos

de archivos de Azure desde Azure Portal.
La copia de seguridad de recursos compartidos de archivos de Azure es una solución de

copia de seguridad nativa basada en la nube que protege los datos en la nube y elimina
las sobrecargas de mantenimiento adicionales implicadas en las soluciones de copia de
seguridad locales. El servicio Azure Backup se integra completamente con Azure File
Sync y permite centralizar los datos de recursos compartidos de archivos, así como las
copias de seguridad. Esta solución sencilla, confiable y segura le permite configurar la
protección de los recursos compartidos de archivos de su empresa en unos cuantos
pasos fáciles con la garantía de poder recuperar los datos en caso de eliminación
accidental.
Más información sobre la solución de copia de seguridad basada en instantáneas de

recursos compartidos de archivos de Azure.
Requisitos previos
Asegúrese de que el recurso compartido de archivos se encuentra en uno de los
tipos de cuenta de almacenamiento admitidos.
Identifique o cree un almacén de Recovery Services en la misma región y
suscripción que la cuenta de almacenamiento que hospeda el recurso compartido
de archivos.
En caso de tener un acceso restringido a la cuenta de almacenamiento, compruebe
la configuración del firewall de la cuenta de almacenamiento para asegurarse de
que se concede la excepción "Permitir que los servicios de Azure de la lista de
servicios de confianza accedan a esta cuenta de almacenamiento". Puede consultar
este vínculo para ver los pasos para conceder una excepción.
Creación de un almacén de Recovery Services

Un almacén de Recovery Services es una entidad de administración que almacena los
puntos de recuperación creados a lo largo del tiempo y proporciona una interfaz para
realizar operaciones relacionadas con la copia de seguridad. Entre dichas operaciones se
incluye realizar copias de seguridad a petición, realizar restauraciones y crear directivas
de copia de seguridad.
Para crear un almacén de Recovery Services:
2. Busque Centro de copias de seguridad y vaya al panel Centro de copias de

seguridad.
3. En el panel de información general, seleccione Almacén.
4. Seleccione Almacén de Recovery Services>Continuar.

5. En el panel del almacén de Recovery Services, escriba los valores siguientes:
Suscripción: seleccione la suscripción que vaya a usar. Si es miembro de una

sola suscripción, verá solo ese nombre. Si no está seguro de la suscripción
que debe usar, seleccione la opción predeterminada. Solo hay varias
opciones si la cuenta profesional o educativa está asociada a más de una
suscripción de Azure.
Grupo de recursos: Use un grupo de recursos existente o cree uno. Para ver
la lista de los grupos de recursos disponibles en una suscripción, seleccione
Usar existente y, a continuación, un recurso de la lista desplegable. Para crear
un grupo de recursos, seleccione Crear nuevo y escriba un nombre. Para más
información sobre los grupos de recursos, consulte Información general de
Azure Resource Manager.
Nombre del almacén: escriba un nombre descriptivo para identificar el

almacén. El nombre debe ser único para la suscripción de Azure. Especifique
un nombre que tenga entre 2 y 50 caracteres. El nombre debe comenzar por
una letra y consta solo de letras, números y guiones.
Región: seleccione la región geográfica del almacén. Si quiere crear un

almacén para proteger cualquier origen de datos, el almacén debe estar en la
misma región que el origen de datos.
） Importante
Si no está seguro de la ubicación del origen de datos, cierre la ventana.

Vaya a la lista de recursos en el portal. Si tiene orígenes de datos en
varias regiones, cree un almacén de Recovery Services para cada una de
ellas. Cree el almacén en la primera ubicación, antes de crear un almacén
en otra ubicación. No es preciso especificar cuentas de almacenamiento
para almacenar los datos de la copia de seguridad. Tanto el almacén de
Recovery Services como Azure Backup lo controlan automáticamente.
6. Después de especificar los valores, seleccione Revisar y crear.
7. Para terminar de crear el almacén de Recovery Services, seleccione Crear.
La creación del almacén de Recovery Services puede tardar unos minutos.

Supervise las notificaciones de estado en el área de notificaciones de la parte
superior derecha. Tras crear el almacén, este aparece en la lista de almacenes de
Recovery Services. Si el almacén no aparece, seleccione Actualizar.
７ Nota
Azure Backup ahora admite los almacenes inmutables que ayudan a garantizar que
los puntos de recuperación creados no se pueden eliminar antes de su expiración,
según la directiva de copia de seguridad. Puedes hacer irreversible la inmutabilidad
para ofrecer la máxima protección a los datos de copia de seguridad datos contra
diversas amenazas, incluidos los ataques de ransomware y los actores
malintencionados. Más información.
Configuración de la copia de seguridad

Selección de un punto de entrada
Centro de copia de seguridad
Para configurar la copia de seguridad de varios recursos compartidos de archivos

desde el Centro de copia de seguridad, siga estos pasos:
1. En Azure Portal , vaya al Centro de copia de seguridad y seleccione +Copia

de seguridad.

2. Seleccione Azure Files (Azure Storage) como tipo de origen de datos, elija el
almacén con el que quiere proteger los recursos compartidos de archivos y,
luego, haga clic en Continuar.
3. Haga clic en Seleccionar para seleccionar la cuenta de almacenamiento que

contiene los recursos compartidos de archivos de los que se va a realizar una
copia de seguridad.
El panel Seleccionar cuenta de almacenamiento se abre a la derecha y

enumera un conjunto de cuentas de almacenamiento admitidas que se han
detectado. Estas cuentas están asociadas a este almacén o se encuentran en la
misma región que el almacén, pero aún no están asociadas a ningún almacén
de Recovery Services.
4. En la lista de cuentas de almacenamiento detectadas, seleccione una cuenta y

seleccione Aceptar.

７ Nota
Si una cuenta de almacenamiento está presente en una región diferente a

la del almacén, no existirá en la lista de cuentas de almacenamiento
detectadas.
5. El siguiente paso consiste en seleccionar los recursos compartidos de archivos

de los que quiere realizar copias de seguridad. Seleccione el botón Agregar
de la sección Recursos compartidos de archivos para la copia de seguridad.
6. Se abre a la derecha el panel de contexto Seleccionar los recursos

compartidos de archivos. Azure busca en la cuenta de almacenamiento los
recursos compartidos de archivos de los que se puede realizar una copia de
seguridad. Si recientemente ha agregado recursos compartidos de archivos y
no los ve en la lista, espere un poco para que aparezcan.
7. En la lista Seleccionar los recursos compartidos de archivos, seleccione uno o

varios recursos compartidos de archivos de los que quiera realizar una copia
de seguridad. Seleccione Aceptar.
8. Para elegir una directiva de copia de seguridad para el recurso compartido de

archivos, tiene tres opciones:
Elija la directiva predeterminada.

Esta opción permite habilitar la copia de seguridad diaria que se
conservará durante 30 días. Si no tiene una directiva de copia de
seguridad existente en el almacén, se abre el panel de copia de
seguridad con la configuración de directivas predeterminada. Si quiere
elegir la configuración predeterminada, puede seleccionar directamente
Habilitar copia de seguridad.
Creación de una nueva directiva
a. Para crear una directiva de copia de seguridad para el recurso

compartido de archivos, seleccione el texto del vínculo situado debajo
de la lista desplegable de la sección Directiva de copia de seguridad.

b. Siga los pasos 3 a 7 de la sección Creación de una nueva directiva.
c. Después de definir todos los atributos de la directiva, seleccione

Aceptar.
Elija una de las directivas de copia de seguridad existentes
Para elegir una de las directivas de copia de seguridad existentes para

configurar la protección, seleccione la directiva que desee en la lista
desplegable Directiva de copia de seguridad.
9. Seleccione Habilitar copia de seguridad para empezar a proteger el recurso

Después de establecer una directiva de copia de seguridad, se realiza una
instantánea de los recursos compartidos de archivos a la hora programada. El punto
de recuperación también se conserva durante el período elegido.
Ejecutar un trabajo de copia de seguridad a

petición.
En ocasiones querrá generar una instantánea de copia de seguridad o un punto de
recuperación fuera de las horas programadas en la directiva de copia de seguridad. Un
motivo habitual para generar una copia de seguridad a petición es justo después de
haber configurado la directiva de copia de seguridad. Según la programación de la
directiva de copia de seguridad, pueden transcurrir horas y días hasta que se toma una
instantánea. Para proteger los datos hasta que se aplique la directiva de copia de
seguridad, inicie una copia de seguridad a petición. La creación de una copia de
seguridad a petición se suele exigir antes de realizar cambios planeados en los recursos
Selección de un punto de entrada
Centro de copia de seguridad
Para ejecutar una copia de seguridad a petición, siga estos pasos:
1. Vaya al Centro de copia de seguridad y seleccione Instancias de Backup en el

menú.
Filtre por Azure Files (Azure Storage) como tipo de origen de datos.
2. Seleccione el elemento para el que desea ejecutar un trabajo de copia de

seguridad a petición.
3. En el menú Copia de seguridad, seleccione Realizar copia de seguridad

ahora. Como se trata de un trabajo de copia de seguridad a petición, no hay
ninguna directiva de retención asociada con el punto de recuperación.
4. Aparece el panel Realizar copia de seguridad ahora. Especifique el último día

que quiere conservar el punto de recuperación. Las copias de seguridad a
petición pueden tener un período de retención máximo de 10 años.
5. Seleccione Aceptar para confirmar la ejecución del trabajo de copia de
seguridad a petición.
6. Supervise las notificaciones del portal para realizar un seguimiento de la

finalización de la ejecución del trabajo de copia de seguridad.
Para supervisar el progreso del trabajo en el panel del Centro de copias de

seguridad, seleccione Centro de copias de seguridad ->Trabajos de copia de
seguridad ->En curso.
Procedimientos recomendados
No elimine las instantáneas que crea Azure Backup. La eliminación de instantáneas
puede provocar la pérdida de puntos de recuperación o errores de restauración.
No quite el bloqueo realizado en la cuenta de almacenamiento mediante Azure

Backup. Si elimina el bloqueo, la cuenta de almacenamiento será propensa a la
eliminación accidental y, si ocurre, perderá las instantáneas o copias de seguridad.
Pasos siguientes
Obtenga información sobre cómo:
Restauración de recursos compartidos de archivos de Azure

Administración de copias de seguridad de recursos compartidos de archivos de
Azure
Copia de seguridad de recursos
compartidos de archivos de Azure con
la CLI de Azure
Artículo • 09/04/2023
La CLI de Azure es la forma de usar la línea de comandos para administrar los recursos
de Azure. Es una herramienta excelente para personalizar la automatización del uso de
los recursos de Azure. En este artículo se detalla cómo realizar una copia de seguridad
de los recursos compartidos de archivos de Azure con la CLI de Azure. Estos pasos
también se pueden realizar desde Azure PowerShell o Azure Portal.
Al final de este tutorial, habrá aprendido a realizar las siguientes operaciones mediante
la CLI de Azure:

Habilitación de la copia de seguridad de los recursos compartidos de archivos de
Azure
Desencadenamiento de una copia de seguridad a petición para recursos
compartidos de archivos
Prerrequisitos
Use el entorno de Bash en Azure Cloud Shell. Para más información, consulte Inicio
rápido para Bash en Azure Cloud Shell.
Si prefiere ejecutar comandos de referencia de la CLI localmente, instale la CLI de

Azure. Si utiliza Windows o macOS, considere la posibilidad de ejecutar la CLI de
Azure en un contenedor Docker. Para más información, vea Ejecución de la CLI de
Azure en un contenedor de Docker.
Si usa una instalación local, inicie sesión en la CLI de Azure mediante el

comando az login. Siga los pasos que se muestran en el terminal para
completar el proceso de autenticación. Para ver otras opciones de inicio de
sesión, consulte Inicio de sesión con la CLI de Azure.
En caso de que se le solicite, instale las extensiones de la CLI de Azure la

primera vez que la use. Para más información sobre las extensiones, consulte
Uso de extensiones con la CLI de Azure.
Ejecute az version para buscar cuál es la versión y las bibliotecas dependientes
que están instaladas. Para realizar la actualización a la versión más reciente,
ejecute az upgrade.
Este tutorial requiere la versión 2.0.18 de la CLI de Azure o cualquier versión

posterior. Si usa Azure Cloud Shell, ya está instalada la versión más reciente.

Un almacén de Recovery Services es una entidad que proporciona funcionalidad de
administración y una vista consolidada de todos los elementos de copia de seguridad.
Cuando se ejecuta el trabajo de copia de seguridad para un recurso protegido, crea un
punto de recuperación en el almacén de Recovery Services. Posteriormente, se puede
usar uno de estos puntos de recuperación para restaurar los datos a un momento dado
en el tiempo.
Siga estos pasos para crear un almacén de Recovery Services:
1. Un almacén se coloca en un grupo de recursos. Si no tiene un grupo de recursos,

cree uno con az group create. En este tutorial, se creará el nuevo grupo de
recursos azurefiles en la región Este de EE. UU.
Azure CLI
az group create --name AzureFiles --location eastus --output table
Resultados
Location Name
---------- ----------
eastus AzureFiles
2. Use el cmdlet az backup vault create para crear el almacén. Especifique para el
almacén la misma ubicación del grupo de recursos.
En el ejemplo siguiente se crea un almacén de Recovery Services denominado

azurefilesvault en la región del este de EE. UU.
Azure CLI
az backup vault create --resource-group azurefiles --name

azurefilesvault --location eastus --output table
Resultados
Location Name ResourceGroup

---------- ---------------- ---------------
eastus azurefilesvault azurefiles
Habilitación de la copia de seguridad de los

En esta sección se supone que ya tiene un recurso compartido de archivos de Azure
para el que desea configurar la copia de seguridad. Si no lo tiene, cree un recurso
compartido de archivos de Azure mediante el comando az storage share create.
Para habilitar la copia de seguridad de recursos compartidos de archivos, debe crear una
directiva de protección que defina cuándo se ejecuta un trabajo de copia de seguridad y
durante cuánto tiempo se almacenan los puntos de recuperación. Puede crear una
directiva de copia de seguridad mediante el cmdlet az backup policy create.
En el ejemplo siguiente se usa el cmdlet az backup protection enable-for-azurefileshare

para habilitar la copia de seguridad para el recurso compartido de archivos azurefiles en
la cuenta de almacenamiento afsaccount mediante la directiva de copia de seguridad
schedule 1.
Azure CLI
az backup protection enable-for-azurefileshare --vault-name azurefilesvault

--resource-group azurefiles --policy-name schedule1 --storage-account
afsaccount --azure-file-share azurefiles --output table
Resultados
Name ResourceGroup
------------------------------------ ---------------
0caa93f4-460b-4328-ac1d-8293521dd928 azurefiles
El atributo Name de la salida corresponde al nombre del trabajo creado por el servicio
de copia de seguridad para la operación de habilitación de copia de seguridad. Para
realizar el seguimiento del estado del trabajo, use el cmdlet az backup job show.
Desencadenamiento de una copia de seguridad

a petición para recursos compartidos de
archivos
Si desea desencadenar una copia de seguridad a petición para el recurso compartido de
archivos en lugar de esperar a que la directiva de copia de seguridad ejecute el trabajo a
la hora programada, use el cmdlet az backup protection backup-now.
Debe definir los parámetros siguientes para desencadenar una copia de seguridad a
petición:
--container-name es el nombre de la cuenta de almacenamiento que hospeda el

recurso compartido de archivos. Para recuperar el nombre o nombre descriptivo
del contenedor, use el comando az backup container list.
--item-name es el nombre del recurso compartido de archivos para el que desea
desencadenar una copia de seguridad a petición. Para recuperar el nombre o
nombre descriptivo del elemento de copia de seguridad, use el comando az
backup item list.
--retain-until especifica la fecha hasta la que desea conservar el punto de
recuperación. El valor debe establecerse en formato de hora UTC (dd-mm-aaaa).
En el ejemplo siguiente se desencadena una copia de seguridad a petición para el

recurso compartido de archivos azuresfiles en la cuenta de almacenamiento afsaccount
con retención hasta el 20-01-2020.
Azure CLI
az backup protection backup-now --vault-name azurefilesvault --resource-

group azurefiles --container-name
"StorageContainer;Storage;AzureFiles;afsaccount" --item-name
"AzureFileShare;azurefiles" --retain-until 20-01-2020 --output table
Resultados
Name ResourceGroup
------------------------------------ ---------------
9f026b4f-295b-4fb8-aae0-4f058124cb12 azurefiles
El atributo Name de la salida corresponde al nombre del trabajo creado por el servicio
de copia de seguridad para la operación de "copia de seguridad a petición". Para
realizar el seguimiento del estado de un trabajo, use el cmdlet az backup job show.
Pasos siguientes
Más información sobre cómo restaurar recursos compartidos de archivos de Azure
con la CLI
Más información sobre cómo administrar copias de seguridad de recursos
compartidos de archivos de Azure con la CLI
Copia de seguridad de un recurso
compartido de archivos de Azure
mediante PowerShell
Artículo • 11/05/2023
En este artículo se describe cómo usar Azure PowerShell para realizar copias de
seguridad de un recurso compartido de archivos de Azure Files mediante el almacén de
Recovery Services de Azure Backup.
En este artículo se explica lo siguiente:
＂ Configure PowerShell y registre el proveedor de Recovery Services.

＂ Cree un almacén de Recovery Services.
＂ Configurar la copia de seguridad de un recurso compartido de archivos de Azure.
＂ Ejecutar un trabajo de copia de seguridad.
Antes de comenzar
Más información sobre los almacenes de Recovery Services.
Revise la referencia de cmdlet de Az.RecoveryServices en la biblioteca de Azure.
Revise la siguiente jerarquía de objetos de PowerShell para Recovery Services:
Configurar PowerShell
７ Nota

７ Nota
Azure PowerShell actualmente no admite directivas de copia de seguridad con

programación por horas. Use Azure Portal para sacar provecho de esta
característica. Más información
Configure PowerShell como sigue:
1. Descargue la versión más reciente de Azure PowerShell.
７ Nota
La versión mínima de PowerShell necesaria para realizar la copia de seguridad

de recursos compartidos de archivos de Azure es Az.RecoveryServices 2.6.0. Si
usa la versión más reciente, o al menos la versión mínima, evitará tener
problemas con los scripts existentes. Instale la versión mínima mediante el
siguiente comando de PowerShell:
Azure PowerShell
Install-module -Name Az.RecoveryServices -RequiredVersion 2.6.0
2. Busque los cmdlets de PowerShell de Azure Backup con este comando:
Azure PowerShell
Get-Command *azrecoveryservices*
3. Revise los alias y cmdlets de Azure Backup, Azure Site Recovery y el almacén de
Recovery Services. Este es un ejemplo de lo que puede ver. No es la lista completa
de los cmdlets.
4. Inicie sesión en su cuenta de Azure mediante el cmdlet Connect-AzAccount.
5. En la página web que aparece, se le pedirá que escriba las credenciales de su

cuenta.
Como alternativa, puede incluir las credenciales de la cuenta como un parámetro

en el cmdlet Connect-AzAccount mediante -Credential.
Si es un asociado de CSP que trabaja en nombre de un inquilino, especifique el
cliente como inquilino. Use su id. de inquilino o el nombre de dominio principal
del inquilino. Por ejemplo, Connect-AzAccount -Tenant "fabrikam.com" .
6. Debe asociar la suscripción que quiere usar con la cuenta, ya que una cuenta
puede tener varias suscripciones:
Azure PowerShell
Select-AzSubscription -SubscriptionName $SubscriptionName
7. Si usa Azure Backup por primera vez, use el cmdlet Register-AzResourceProvider

para registrar el proveedor de Azure Recovery Services con la suscripción:
Azure PowerShell
Register-AzResourceProvider -ProviderNamespace
"Microsoft.RecoveryServices"
8. Compruebe que los proveedores se han registrado correctamente:
Azure PowerShell
Get-AzResourceProvider -ProviderNamespace "Microsoft.RecoveryServices"
9. En la salida del comando, compruebe que RegistrationState cambia a Registered.

En caso contrario, vuelva a ejecutar el cmdlet Register-AzResourceProvider.

El almacén de Recovery Services es un recurso de Resource Manager, por lo que deberá
colocarlo en un grupo de recursos. Puede usar un grupo de recursos existente o crear
uno mediante el cmdlet New-AzResourceGroup. Al crear un grupo de recursos,
especifique el nombre y la ubicación del mismo.
Siga estos pasos para crear un almacén de Recovery Services:
1. Si no tiene un grupo de recursos, cree uno con el cmdlet New-AzResourceGroup.

En el ejemplo, se crea un grupo de recursos en la región Oeste de EE. UU:
Azure PowerShell
New-AzResourceGroup -Name "test-rg" -Location "West US"

2. Use el cmdlet New-AzRecoveryServicesVault para crear el almacén. Especifique la
misma ubicación para el almacén que usó en el grupo de recursos.
Azure PowerShell
New-AzRecoveryServicesVault -Name "testvault" -ResourceGroupName "test-

rg" -Location "West US"
Visualización de los almacenes de una suscripción

Para ver todos los almacenes de la suscripción, use Get-AzRecoveryServicesVault:
Azure PowerShell
Get-AzRecoveryServicesVault
La salida será similar a la siguiente. Tenga en cuenta que la salida proporciona el grupo
de recursos y la ubicación asociados.
Azure PowerShell
Name : Contoso-vault
ID : /subscriptions/1234
Type : Microsoft.RecoveryServices/vaults
Location : WestUS
ResourceGroupName : Contoso-docs-rg
SubscriptionId : 1234-567f-8910-abc
Properties :
Microsoft.Azure.Commands.RecoveryServices.ARSVaultProperties
Establecer el contexto de almacén

Almacene el objeto de almacén en una variable y establezca el contexto de almacén.
Muchos de los cmdlets de Azure Backup requieren el objeto de almacén de Recovery

Services como una entrada, por lo que es conveniente almacenar el objeto de almacén
en una variable.
El contexto de almacén es el tipo de los datos protegidos en el almacén. Establézcalo

mediante Set-AzRecoveryServicesVaultContext. Una vez que se haya establecido el
contexto, se aplica a todos los cmdlets posteriores.
En el ejemplo siguiente se establece el contexto del almacén de testvault:

Azure PowerShell
Get-AzRecoveryServicesVault -Name "testvault" | Set-

AzRecoveryServicesVaultContext
Recuperación del identificador del almacén

Tenemos previsto dejar de usar la configuración del contexto de almacén según las
directrices de Azure PowerShell. En su lugar, puede almacenar o recuperar el
identificador del almacén y pasarlo a los comandos pertinentes. Por lo tanto, si no ha
establecido el contexto de almacén o quiere especificar el comando que se va a ejecutar
para un determinado almacén, pase el id. de almacén como -vaultID a todos los
comandos pertinentes de la manera siguiente:
Azure PowerShell
$vaultID = Get-AzRecoveryServicesVault -ResourceGroupName "Contoso-docs-rg"

-Name "testvault" | select -ExpandProperty ID
New-AzRecoveryServicesBackupProtectionPolicy -Name "NewAFSPolicy" -
WorkloadType "AzureFiles" -RetentionPolicy $retPol -SchedulePolicy $schPol -
VaultID $vaultID
Configuración de una directiva de copia de

seguridad
Una directiva de copia de seguridad especifica la programación de las copias de
seguridad y cuánto tiempo se deben mantener los puntos de recuperación de copia de
seguridad.
Una directiva de copia de seguridad está asociada con al menos una directiva de
retención. Una directiva de retención define el tiempo que se conserva un punto de
recuperación antes de que se elimine. Puede configurar copias de seguridad con
retención diaria, semanal, mensual o anual. Con la directiva de varias copias de
seguridad, también puede configurar la retención por hora de las copias de seguridad.
Elección de un tipo de directiva:
Directiva de copia de seguridad diaria
Estos son algunos cmdlets para las directivas de copia de seguridad:

Consulte la retención de la directiva de copia de seguridad predeterminada
mediante Get-AzRecoveryServicesBackupRetentionPolicyObject.
Consulte la programación de la directiva de copia de seguridad
predeterminada mediante Get-
AzRecoveryServicesBackupSchedulePolicyObject.
Cree una directiva de copia de seguridad mediante New
AzRecoveryServicesBackupProtectionPolicy. Especifique los objetos de
directiva de retención y programación como entradas.
De forma predeterminada, se define una hora de inicio en el objeto de directiva de

programación. Use el siguiente ejemplo para cambiar la hora de inicio a la hora de
inicio deseada. La hora de inicio deseada debe ser la hora universal coordinada
(UTC). En el ejemplo siguiente se supone que la hora de inicio deseada es 01:00 UTC
para las copias de seguridad diarias.
Azure PowerShell
$schPol = Get-AzRecoveryServicesBackupSchedulePolicyObject -WorkloadType

"AzureFiles"
$UtcTime = Get-Date -Date "2019-03-20 01:30:00Z"
$UtcTime = $UtcTime.ToUniversalTime()
$schpol.ScheduleRunTimes[0] = $UtcTime
） Importante
Solo tiene que proporcionar la hora de inicio en múltiplos de 30 minutos. En el

ejemplo anterior, solo puede ser "01:00:00" o "02:30:00". La hora de inicio no
puede ser "01:15:00".
En el ejemplo siguiente se almacenan la directiva de programación y la directiva de

retención en variables. Después usa estas variables como parámetros para una
nueva directiva (NewAFSPolicy). NewAFSPolicy realiza una copia de seguridad
diaria y la conserva durante 30 días.
Azure PowerShell
$schPol = Get-AzRecoveryServicesBackupSchedulePolicyObject -WorkloadType

"AzureFiles"
$retPol = Get-AzRecoveryServicesBackupRetentionPolicyObject -
WorkloadType "AzureFiles"
New-AzRecoveryServicesBackupProtectionPolicy -Name "NewAFSPolicy" -
WorkloadType "AzureFiles" -RetentionPolicy $retPol -SchedulePolicy
$schPol
La salida será similar a la siguiente:
Azure PowerShell
Name WorkloadType BackupManagementType BackupTime

DaysOfWeek
---- ------------ -------------------- ----------
----------
NewAFSPolicy AzureFiles AzureStorage
10/24/2019 1:30:00 AM
Habilitación de la copia de seguridad

Una vez que haya definido la directiva de copia de seguridad, puede habilitar la
protección para el recurso compartido de archivos de Azure con esta directiva.
Recuperación de una directiva de copia de seguridad

Recupere el objeto de directiva pertinente mediante Get-
AzRecoveryServicesBackupProtectionPolicy. Use este cmdlet para obtener una directiva
específica o para ver las directivas asociadas a un tipo de carga de trabajo.
Recuperación de una directiva para un tipo de carga de trabajo

En el ejemplo siguiente se recuperan las directivas para el tipo de carga de trabajo
AzureFiles:
Azure PowerShell
Get-AzRecoveryServicesBackupProtectionPolicy -WorkloadType "AzureFiles"
La salida será similar a la siguiente:
Azure PowerShell
Name WorkloadType BackupManagementType BackupTime

DaysOfWeek
---- ------------ -------------------- ----------
----------
dailyafs AzureFiles AzureStorage 1/10/2018
12:30:00 AM
７ Nota
La zona horaria del campo BackupTime en PowerShell es UTC. Cuando el tiempo

de copia de seguridad se muestra en Azure Portal, la hora se ajusta a la zona
horaria local.
Recuperación de una directiva específica
La directiva siguiente recupera la directiva de copia de seguridad llamada dailyafs:
Azure PowerShell
$afsPol = Get-AzRecoveryServicesBackupProtectionPolicy -Name "dailyafs"
Habilitación de la protección y aplicación de la directiva

Habilite la protección mediante Enable-AzRecoveryServicesBackupProtection. Una vez
que la directiva se ha asociado al almacén, las copias de seguridad se desencadenan
según la programación de la directiva.
En el ejemplo siguiente se habilita la protección para el recurso compartido de archivos

de Azure testAzureFS, en la cuenta de almacenamiento testStorageAcct, con la directiva
dailyafs:
Azure PowerShell
Enable-AzRecoveryServicesBackupProtection -StorageAccountName
"testStorageAcct" -Name "testAzureFS" -Policy $afsPol
El comando espera hasta que el trabajo de protección configurado termina y

proporciona una salida similar, tal como se muestra en el siguiente ejemplo:
Símbolo del sistema de Windows
WorkloadName Operation Status StartTime

EndTime JobID
------------ --------- ------ ---------
------- -----
testAzureFS ConfigureBackup Completed 11/12/2018
2:15:26 PM 11/12/2018 2:16:11 PM ec7d4f1d-40bd-46a4-9edb-
3193c41f6bf6
Para más información sobre cómo obtener una lista de recursos compartidos de
archivos para una cuenta de almacenamiento, consulte este artículo.
Aviso importante: Identificación del elemento

de copia de seguridad
En esta sección se describe un cambio importante en las copias de seguridad de
recursos compartidos de archivos de Azure en el proceso de preparación para la
disponibilidad general.
Al habilitar la copia de seguridad los recursos compartidos de archivos de Azure, el

usuario proporciona al cliente el nombre del recurso compartido de archivos como
nombre de la entidad; una vez hecho esto, se crea un elemento de copia de seguridad.
El nombre del elemento de copia de seguridad es un identificador único que crea el
servicio Azure Backup. Normalmente, el identificador es el nombre descriptivo del
usuario. De todos modos, para controlar el escenario de eliminación temporal, donde se
puede eliminar un recurso compartido de archivos y crear otro con el mismo nombre, la
identidad única del recurso compartido de archivos de Azure ahora es un id.
Para conocer el id. único de cada elemento, ejecute el comando Get-

AzRecoveryServicesBackupItem con los filtros correspondientes para
backupManagementType y WorkloadType para obtener todos los elementos
pertinentes. A continuación, observe el campo del nombre en la respuesta o el objeto
de PowerShell devuelto.
Siempre se recomienda realizar una lista de los elementos y luego recuperar su nombre
único del campo del nombre de la respuesta. Use este valor para filtrar los elementos
con el parámetro Name. De lo contrario, use el parámetro FriendlyName para recuperar
el elemento con su id.
） Importante
Asegúrese de que PowerShell se actualice a la versión mínima

(AZ.RecoveryServices 2.6.0) para las copias de seguridad de recursos compartidos
de archivos de Azure. Con esta versión, el filtro friendlyName está disponible para
el comando Get-AzRecoveryServicesBackupItem.
Pase el nombre del recurso compartido de archivos de Azure al parámetro

friendlyName. Si pasa el nombre del recurso compartido de archivos de Azure al
parámetro Name, esta versión genera la advertencia de pasar este nombre al
parámetro friendlyName.
Si no instala esta versión mínima pueden producirse errores en los scripts
existentes. Instale la versión mínima de PowerShell mediante el siguiente comando:
Azure PowerShell
Install-module -Name Az.RecoveryServices -RequiredVersion 2.6.0

a petición
Use Backup-AzRecoveryServicesBackupItem para ejecutar una copia de seguridad a
petición para un recurso compartido de archivos protegido de Azure:
1. Recupere la cuenta de almacenamiento del contenedor del almacén que contenga

los datos de copia de seguridad mediante Get-
AzRecoveryServicesBackupContainer.
2. Para iniciar un trabajo de copia de seguridad, obtenga información sobre el
recurso compartido de archivos de Azure mediante Get-
AzRecoveryServicesBackupItem.
3. Ejecute una copia de seguridad a petición mediante Backup-
AzRecoveryServicesBackupItem.
Ejecute la copia de seguridad a petición de la manera siguiente:
Azure PowerShell
$afsContainer = Get-AzRecoveryServicesBackupContainer -FriendlyName

"testStorageAcct" -ContainerType AzureStorage
$afsBkpItem = Get-AzRecoveryServicesBackupItem -Container $afsContainer -
WorkloadType "AzureFiles" -FriendlyName "testAzureFS"
$job = Backup-AzRecoveryServicesBackupItem -Item $afsBkpItem
El comando devuelve un trabajo con un id. del cual se puede realizar un seguimiento, tal
como se indica en el ejemplo siguiente:
Azure PowerShell

EndTime JobID
------------ --------- ------ ---------
------- -----
testAzureFS Backup Completed 11/12/2018
2:42:07 PM 11/12/2018 2:42:11 PM 8bdfe3ab-9bf7-4be6-83d6-
37ff1ca13ab6
Las instantáneas del recurso compartido de archivos de Azure se usan mientras se

realizan las copias de seguridad. Normalmente, el trabajo finaliza en el momento en que
el comando devuelve este resultado.
Pasos siguientes
Obtenga información sobre cómo realizar copias de seguridad de archivos de
Azure Files en Azure Portal.
Consulte el script de ejemplo en GitHub para usar un runbook de Azure
Automation para programar copias de seguridad.
Copia de seguridad de un recurso
compartido de archivos de Azure con
Azure Backup mediante API REST
Artículo • 01/06/2023
En este artículo se describe cómo hacer una copia de seguridad de un recurso

compartido de archivos con Azure Backup mediante la API REST.
En este artículo se da por sentado que ya ha creado un almacén de Recovery Services y

una directiva para configurar la copia de seguridad del recurso compartido de archivos.
Si aún no lo hecho, consulte los tutoriales de API REST para crear un almacén y crear
una directiva.
En este artículo, usaremos los siguientes recursos:
Almacén de Recovery Services: azurefilesvault
Directiva:schedule1
Grupo de recursos: azurefiles
Cuenta de almacenamiento: testvault2
Recurso compartido de archivos: testshare
Configuración de la copia de seguridad para un

recurso compartido de archivos de Azure sin
protección con API REST
Detección de cuentas de almacenamiento con recursos

compartidos de archivos de Azure sin protección
El almacén debe detectar todas las cuentas de almacenamiento de Azure de la
suscripción que tengan recursos compartidos de archivos de los que se pueda realizar
una copia de seguridad en el almacén de Recovery Services. Esta acción se desencadena
con la operación de actualización. Se trata de una operación POST asincrónica que
garantiza que el almacén obtiene la lista más reciente de todos los recursos
compartidos de archivos sin protección de Azure de la suscripción actual y los
"almacena en caché". Una vez que el recurso compartido de archivos se almacena en
caché, Recovery Services puede acceder a este y protegerlo.
HTTP
POST
https://management.azure.com/Subscriptions/{subscriptionId}/resourceGroups/{
vaultresourceGroupname}/providers/Microsoft.RecoveryServices/vaults/{vaultNa
me}/backupFabrics/{fabricName}/refreshContainers?api-version=2016-12-
01&$filter={$filter}
El URI de POST tiene los parámetros {subscriptionId} , {vaultName} ,

{vaultresourceGroupName} y {fabricName} . En nuestro ejemplo, el valor de los distintos
parámetros será el siguiente:
{fabricName} es Azure
{vaultName} es azurefilesvault
{vaultresourceGroupName} es azurefiles
$filter=backupManagementType eq 'AzureStorage'
Como todos los parámetros necesarios se proporcionan en el URI, no hay necesidad de

tener un cuerpo de solicitud independiente.
HTTP
POST https://management.azure.com/Subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/azurefiles/providers/Microsoft.RecoveryServices/
vaults/azurefilesvault/backupFabrics/Azure/refreshContainers?api-
version=2016-12-01&$filter=backupManagementType eq 'AzureStorage'
Respuestas para la operación de actualización
La operación 'refresh' es una operación asincrónica. Significa que esta operación crea
otra que tiene que ser seguida por separado.
Devuelve las dos respuestas: 202 (Aceptado) cuando se crea otra operación y 200
(Correcto) cuando se completa dicha operación.
Respuestas de ejemplo para la operación de actualización
Una vez que se envía la solicitud POST, se devuelve una respuesta 202 (Accepted).
HTTP
HTTP/1.1 202 Accepted

'Pragma': 'no-cache'
'Expires': '-1'
'Location': ‘https://management.azure.com/Subscriptions/00000000-0000-0000-
0000-000000000000/ResourceGroups
/azurefiles/providers/Microsoft.RecoveryServices/vaults/azurefilesvault/back
upFabrics/Azure/operationResults/
cca47745-12d2-42f9-b3a4-75335f18fdf6?api-version=2016-12-01’
'Retry-After': '60'
'X-Content-Type-Options': 'nosniff'
'x-ms-request-id': '6cc12ceb-90a2-430d-a1ec-9b6b6fdea92b'
'x-ms-client-request-id': ‘3da383a5-d66d-4b7c-982a-bc8d94798d61,3da383a5-
d66d-4b7c-982a-bc8d94798d61’
'Strict-Transport-Security': 'max-age=31536000; includeSubDomains'
'X-Powered-By': 'ASP.NET'
'x-ms-ratelimit-remaining-subscription-reads': '11996'
'x-ms-correlation-request-id': '6cc12ceb-90a2-430d-a1ec-9b6b6fdea92b'
'x-ms-routing-request-id': CENTRALUSEUAP:20200203T091326Z:6cc12ceb-90a2-
430d-a1ec-9b6b6fdea92b'
'Date': 'Mon, 03 Feb 2020 09:13:25 GMT'
Realice el seguimiento de la operación resultante con el encabezado "Location"

(ubicación) y un simple comando GET.
HTTP
GET https://management.azure.com/Subscriptions/00000000-0000-0000-0000-
vaults/azurefilesvault/backupFabrics/Azure/operationResults/cca47745-12d2-
42f9-b3a4-75335f18fdf6?api-version=2016-12-01
Una vez que se detectan todas las cuentas de Azure Storage, el comando GET devuelve
una respuesta 204 (Sin contenido). El almacén ahora puede detectar cualquier cuenta de
almacenamiento con recursos compartidos de archivos de los que se puede realizar una
copia de seguridad dentro de la suscripción.
HTTP
HTTP/1.1 200 NoContent

Cache-Control : no-cache
Pragma : no-cache
X-Content-Type-Options : nosniff
x-ms-request-id : d9bdb266-8349-4dbd-9688-de52f07648b2
x-ms-client-request-id : 3da383a5-d66d-4b7c-982a-bc8d94798d61,3da383a5-
d66d-4b7c-982a-bc8d94798d61
Strict-Transport-Security : max-age=31536000; includeSubDomains
X-Powered-By : ASP.NET
x-ms-ratelimit-remaining-subscription-reads: 11933
x-ms-correlation-request-id : d9bdb266-8349-4dbd-9688-de52f07648b2
x-ms-routing-request-id : CENTRALUSEUAP:20200127T105304Z:d9bdb266-8349-
4dbd-9688-de52f07648b2
Date : Mon, 27 Jan 2020 10:53:04 GMT
Obtenga una lista de cuentas de almacenamiento con

recursos compartidos de archivos de los que se puede
realizar una copia de seguridad con el almacén de
Recovery Services
Para confirmar que se ha realizado el "almacenamiento en caché", enumere todas las
cuentas de almacenamiento de la suscripción con recursos compartidos de archivos de
los que se pueda realizar una copia de seguridad con el almacén de Recovery Services. A
continuación, busque la cuenta de almacenamiento deseada en la respuesta. Esto se
hace mediante la operación GET ProtectableContainers.
HTTP
vaults/azurefilesvault/backupFabrics/Azure/protectableContainers?api-
version=2016-12-01&$filter=backupManagementType eq 'AzureStorage'
El identificador URI de GET tiene todos los parámetros necesarios. No se necesita

ningún cuerpo de solicitud adicional.
Ejemplo de cuerpo de respuesta:
JSON
"value": [
{
"id": "/Subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/azurefiles/providers
/Microsoft.RecoveryServices/vaults/azurefilesvault/backupFabrics/Azure/
protectableContainers/StorageContainer;Storage;AzureFiles;testvault2",
"name": "StorageContainer;Storage;AzureFiles;testvault2",
"type":
"Microsoft.RecoveryServices/vaults/backupFabrics/protectableContainers",
"properties": {
"friendlyName": "testvault2",
"backupManagementType": "AzureStorage",
"protectableContainerType": "StorageContainer",
"healthStatus": "Healthy",
"containerId": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/
AzureFiles/providers/Microsoft.Storage/storageAccounts/testvault2"
}
}
Dado que podemos encontrar la cuenta de almacenamiento testvault2 en el cuerpo de

la respuesta con el nombre descriptivo, la operación de actualización anterior se realizó
correctamente. Ahora, el almacén de Recovery Services puede detectar correctamente
las cuentas de almacenamiento con recursos compartidos de archivos sin protección en
la misma suscripción.
Registro de la cuenta de almacenamiento con el almacén

de Recovery Services
Este paso solo es necesario si no registró la cuenta de almacenamiento con el almacén
anteriormente. Puede registrar el almacén mediante la operación ProtectionContainers-
Register.
HTTP
PUT
resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{vaultName}/b
ackupFabrics/{fabricName}/protectionContainers/{containerName}?api-
version=2016-12-01
Defina las variables de los URI como se indica a continuación:
{resourceGroupName}: azurefiles
{fabricName}: Azure
{vaultName}: azurefilesvault
{containerName}: es el atributo de nombre del cuerpo de la respuesta de la
operación GET ProtectableContainers. En nuestro ejemplo, es
StorageContainer;Storage;AzureFiles;testvault2
７ Nota
Tome siempre el atributo de nombre de la respuesta y rellénelo en esta solicitud.

No cree ni codifique de forma rígida el formato del nombre de contenedor. Si lo
crea o codifica de forma rígida, se producirá un error en la llamada API si el
formato contenedor-nombre cambia en el futuro.
HTTP
PUT https://management.azure.com/Subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/AzureFiles/providers/Microsoft.RecoveryServices/
vaults/azurefilesvault/backupFabrics/Azure/protectionContainers/StorageConta
iner;Storage;AzureFiles;testvault2?api-version=2016-12-01
La creación del cuerpo de la solicitud se lleva a cabo como se indica a continuación:
JSON
"properties": {
"containerType": "StorageContainer",
"sourceResourceId": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/AzureFiles/providers/Microsoft.Storage/storageAc
counts/testvault2",
"resourceGroup": "AzureFiles",
"backupManagementType": "AzureStorage"
}
}
Para obtener una lista completa de las definiciones del cuerpo de la solicitud y otros
detalles, consulte ProtectionContainers-Register.
Se trata de una operación asincrónica y devuelve dos respuestas: "202 Aceptado"

cuando se acepta la operación y "200 Correcto" cuando se completa la operación. Para
realizar un seguimiento del estado de la operación, use el encabezado de ubicación
para obtener el estado más reciente de la operación.
HTTP
iner;Storage;AzureFiles;testvault2/operationresults/1a3c8ee7-e0e5-43ed-b8b3-
73cc992b6db9?api-version=2016-12-01
Ejemplo de cuerpo de respuesta cuando se completa la operación:
JSON
{
vaults/azurefilesvault/backupFabrics/Azure/
protectionContainers/StorageContainer;Storage;AzureFiles;testvault2",
"name": "StorageContainer;Storage;AzureFiles;testvault2",
"properties": {
counts/testvault2",
"protectedItemCount": 0,
"registrationStatus": "Registered",
"healthStatus": "Healthy",
"containerType": "StorageContainer",
"protectableObjectType": "StorageContainer"
}
}
Puede comprobar si el registro se realizó correctamente a partir del valor del parámetro
registrationstatus en el cuerpo de la respuesta. En nuestro caso, muestra el estado
registrado para testvault2, por lo que la operación de registro se realizó correctamente.
Consultar todos los recursos compartidos de archivos sin

protección en una cuenta de almacenamiento
Puede consultar los elementos que se pueden proteger de una cuenta de
almacenamiento mediante la operación Protection Containers-Inquire. Es una operación
asincrónica y se debe realizar un seguimiento de los resultados mediante el encabezado
de ubicación.
HTTP
POST
ackupFabrics/{fabricName}/protectionContainers/{containerName}/inquire?api-
version=2016-12-01
Defina las variables de los URI anteriores como se indica a continuación:
{fabricName}: Azure
{containerName}: consulte el atributo de nombre del cuerpo de la respuesta de la
operación GET ProtectableContainers. En nuestro ejemplo, es
StorageContainer;Storage;AzureFiles;testvault2
HTTP
https://management.azure.com/Subscriptions/00000000-0000-0000-0000-
iner;Storage;AzureFiles;testvault2/inquire?api-version=2016-12-01
Una vez que la solicitud se realiza correctamente, devuelve el código de estado

"Correcto".
HTTP
Pragma : no-cache
X-Content-Type-Options: nosniff
x-ms-request-id : 68727f1e-b8cf-4bf1-bf92-8e03a9d96c46
x-ms-client-request-id : 3da383a5-d66d-4b7c-982a-bc8d94798d61,3da383a5-
d66d-4b7c-982a-bc8d94798d61
Strict-Transport-Security: max-age=31536000; includeSubDomains
Server : Microsoft-IIS/10.0
X-Powered-B : ASP.NET
x-ms-ratelimit-remaining-subscription-reads: 11932
x-ms-correlation-request-id : 68727f1e-b8cf-4bf1-bf92-8e03a9d96c46
x-ms-routing-request-id : CENTRALUSEUAP:20200127T105305Z:68727f1e-b8cf-
4bf1-bf92-8e03a9d96c46
Date : Mon, 27 Jan 2020 10:53:05 GMT
Seleccione el recurso compartido de archivos del que
quiere hacer una copia de seguridad
Puede enumerar todos los elementos que se pueden proteger en la suscripción y buscar
el recurso compartido de archivos que se va a incluir en la copia de seguridad mediante
la operación GET backupprotectableItems.
HTTP
GET
ackupProtectableItems?api-version=2016-12-01&$filter={$filter}
Construya el URI de la forma siguiente:
{$filter}: backupManagementType eq 'AzureStorage'
HTTP
vaults/azurefilesvault/backupProtectableItems?$filter=backupManagementType
eq 'AzureStorage'&api-version=2016-12-01
Respuesta de ejemplo:
JSON
Status Code:200
{
"value": [
{
vaults/azurefilesvault/backupFabrics/Azure/protectionContainers/storageconta
iner;storage;azurefiles;afaccount1/protectableItems/azurefileshare;azurefile
s1",
"name": "azurefileshare;azurefiles1",
"type":
"Microsoft.RecoveryServices/vaults/backupFabrics/protectionContainers/protec
tableItems",
"properties": {
"parentContainerFabricId": "/subscriptions/00000000-0000-
0000-0000-
counts/afaccount1",
"parentContainerFriendlyName": "afaccount1",
"azureFileShareType": "XSMB",
"workloadType": "AzureFileShare",
"protectableItemType": "AzureFileShare",
"friendlyName": "azurefiles1",
"protectionState": "NotProtected"
}
},
{
iner;storage;azurefiles;afsaccount/protectableItems/azurefileshare;afsresour
ce",
"name": "azurefileshare;afsresource",
"type":
tableItems",
"properties": {
0000-0000-
counts/afsaccount",
"parentContainerFriendlyName": "afsaccount",
"friendlyName": "afsresource",
}
},
{
iner;storage;azurefiles;testvault2/protectableItems/azurefileshare;testshare
",
"name": "azurefileshare;testshare",
"type":
tableItems",
"properties": {
0000-0000-
counts/testvault2",
"parentContainerFriendlyName": "testvault2",
"friendlyName": "testshare",
}
}
]
}
La respuesta contiene la lista de todos los recursos compartidos de archivos sin

protección e incluye toda la información que requiere Azure Recovery Services para
configurar la copia de seguridad.
Habilitación de la copia de seguridad para el recurso

Una vez que el recurso compartido de archivos correspondiente esté "identificado" con
el nombre descriptivo, seleccione la directiva para la protección. Para más información
acerca de las directivas existentes en el almacén, consulte el artículo sobre la API de
enumeración de directivas. A continuación, seleccione la directiva pertinente haciendo
referencia al nombre de la directiva. Para crear las directivas, consulte el tutorial sobre la
creación de directivas.
La habilitación de la protección es una operación asincrónica PUT que crea un

"elemento protegido".
HTTP
PUT
vaultresourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{vaultNa
me}/backupFabrics/{fabricName}/protectionContainers/{containerName}/protecte
dItems/{protectedItemName}?api-version=2019-05-13
Establezca las variables containername y protecteditemname mediante el atributo ID

en el cuerpo de respuesta de la operación GET backupprotectableitems.
En nuestro ejemplo, el identificador del recurso compartido de archivos que queremos

proteger es el siguiente:
Resultados
"/Subscriptions/00000000-0000-0000-0000-
iner;storage;azurefiles;testvault2/protectableItems/azurefileshare;testshare
{containername}: storagecontainer;storage;azurefiles;testvault2
{protectedItemName}: azurefileshare;azurefiles
También puede hacer referencia al atributo name del contenedor de protección y las
respuestas de los elementos que se pueden proteger.
７ Nota
Tome siempre el atributo de nombre de la respuesta y rellénelo en esta solicitud.

No cree ni codifique de forma rígida el formato del nombre de contenedor, ni el
formato del nombre del elemento protegido. Si lo crea o codifica de forma rígida,
se producirá un error en la llamada API si el formato contenedor-nombre o el
formato del nombre del elemento protegido cambia en el futuro.
HTTP
PUT https://management.azure.com/Subscriptions/00000000-0000-0000-0000-
iner;Storage;AzureFiles;testvault2/protectedItems/azurefileshare;testshare?
api-version=2016-12-01
Crear un cuerpo de la solicitud:
El cuerpo de solicitud siguiente define las propiedades necesarias para crear un

elemento protegido.
JSON
{
"properties": {
"protectedItemType": "AzureFileShareProtectedItem",
counts/testvault2",
"policyId": "/Subscriptions/00000000-0000-0000-0000-
vaults/azurefilesvault/backupPolicies/schedule1"
}
}
sourceResourceId es parentcontainerFabricID en respuesta a GET

backupprotectableItems.
Respuesta de ejemplo
La creación de un elemento protegido es una operación asincrónica que crea otra

operación de la que es necesario realizar un seguimiento. Devuelve las dos respuestas:
202 (Aceptado) cuando se crea otra operación y 200 (Correcto) cuando se completa
dicha operación.
Una vez enviada la solicitud PUT para la creación o actualización de elementos

protegidos, la respuesta inicial es 202 (Aceptado) con un encabezado de ubicación.
HTTP
HTTP/1.1 202 Accepted

Pragma : no-cache
Location : https://management.azure.com/Subscriptions/00000000-0000-0000-
0000-
iner;Storage;AzureFiles;testvault2/protectedItems/azurefileshare;testshare/o
perationResults/c3a52d1d-0853-4211-8141-477c65740264?api-version=2016-12-01
Retry-Afte : 60
Azure-AsyncOperation : https://management.azure.com/Subscriptions/00000000-
0000-0000-0000-
iner;Storage;AzureFiles;testvault2/protectedItems/azurefileshare;testshare/o
perationResults/c3a52d1d-0853-4211-8141-477c65740264?api-version=2016-12-01
X-Content-Type-Options : nosniff
x-ms-request-id : b55527fa-f473-4f09-b169-9cc3a7a39065
x-ms-client-request-id: 3da383a5-d66d-4b7c-982a-bc8d94798d61,3da383a5-d66d-
4b7c-982a-bc8d94798d61
Strict-Transport-Security : max-age=31536000; includeSubDomains
X-Powered-By : ASP.NET
x-ms-ratelimit-remaining-subscription-writes: 1198
x-ms-correlation-request-id : b55527fa-f473-4f09-b169-9cc3a7a39065
x-ms-routing-request-id : CENTRALUSEUAP:20200127T105412Z:b55527fa-f473-
4f09-b169-9cc3a7a39065
Date : Mon, 27 Jan 2020 10:54:12 GMT
A continuación, realice un seguimiento de la operación resultante con el encabezado de

ubicación o el encabezado Azure-AsyncOperation y un comando GET.
HTTP
vaults/azurefilesvault/backupOperations/c3a52d1d-0853-4211-8141-
477c65740264?api-version=2016-12-01
Una vez completada la operación, devuelve 200 (OK) con el contenido del elemento
protegido en el cuerpo de respuesta.
Ejemplo de cuerpo de respuesta:
JSON
{
"id": "c3a52d1d-0853-4211-8141-477c65740264",
"name": "c3a52d1d-0853-4211-8141-477c65740264",
"status": "Succeeded",
"startTime": "2020-02-03T18:10:48.296012Z",
"endTime": "2020-02-03T18:10:48.296012Z",
"properties": {
"objectType": "OperationStatusJobExtendedInfo",
"jobId": "e2ca2cf4-2eb9-4d4b-b16a-8e592d2a658b"
}
}
Así se confirma que la protección está habilitada para el recurso compartido de archivos
y la primera copia de seguridad se desencadenará según la programación de la
directiva.

a petición para recursos compartidos de
archivos
Una vez que un recurso compartido de archivos de Azure está configurado para la copia
de seguridad, las copias de seguridad se realizan según la programación de la directiva.
Puede esperar a la primera copia de seguridad programada o desencadenar una copia
de seguridad a petición en cualquier momento.
Desencadenar una copia de seguridad a petición es una operación POST.
HTTP
POST
ackupFabrics/{fabricName}/protectionContainers/{containerName}/protectedItem
s/{protectedItemName}/backup?api-version=2016-12-01
{containerName} y {protectedItemName} se han creado anteriormente al habilitar la

copia de seguridad. En nuestro ejemplo, esto se traduce en:
HTTP
POST https://management.azure.com/subscriptions/00000000-0000-0000-0000-
iner;storage;azurefiles;testvault2/protectedItems/AzureFileShare;testshare/b
ackup?api-version=2017-07-01
Creación del cuerpo de la solicitud

Para desencadenar una copia de seguridad a petición, los siguientes son los
componentes del cuerpo de la solicitud.
Nombre Tipo Descripción
Propiedades AzurefilesharebackupReques Propiedades de BackupRequestResource
detalles, consulte el documento de la API REST sobre desencadenar copias de seguridad
de los elementos protegidos.
Ejemplo de cuerpo de la solicitud
JSON
"properties":{
"objectType":"AzureFileShareBackupRequest",
"recoveryPointExpiryTimeInUTC":"2020-03-07T18:29:59.000Z"
}
Respuestas a la operación de copia de seguridad a

petición
Desencadenar una copia de seguridad a petición es una operación asincrónica. Significa
que esta operación crea otra que tiene que ser seguida por separado.
Respuestas de ejemplo a la operación de copia de
seguridad a petición
Una vez enviada la solicitud POST para una copia de seguridad a petición, la respuesta
inicial es 202 (Accepted) con un encabezado de ubicación o Azure-async-header.
HTTP
'Cache-Control': 'no-cache'
'Expires': '-1'
'Location': https://management.azure.com/subscriptions/00000000-0000-0000-
0000-
iner;storage;azurefiles;testvault2/protectedItems/AzureFileShare;testshare/o
perationResults/dc62d524-427a-4093-968d-e951c0a0726e?api-version=2017-07-01
'Retry-After': '60'
'Azure-AsyncOperation': https://management.azure.com/subscriptions/00000000-
0000-0000-0000-
perationsStatus/dc62d524-427a-4093-968d-e951c0a0726e?api-version=2017-07-01
'x-ms-request-id': '2e03b8d4-66b1-48cf-8094-aa8bff57e8fb'
'x-ms-client-request-id': 'a644712a-4895-11ea-ba57-0a580af42708, a644712a-
4895-11ea-ba57-0a580af42708'
'x-ms-ratelimit-remaining-subscription-writes': '1199'
'x-ms-correlation-request-id': '2e03b8d4-66b1-48cf-8094-aa8bff57e8fb'
'x-ms-routing-request-id': 'WESTEUROPE:20200206T040339Z:2e03b8d4-66b1-48cf-
8094-aa8bff57e8fb'
'Date': 'Thu, 06 Feb 2020 04:03:38 GMT'
'Content-Length': '0'

HTTP
vaults/azurefilesvault/backupOperations/dc62d524-427a-4093-968d-
e951c0a0726e?api-version=2016-12-01
Una vez completada la operación, devuelve 200 (OK) con el identificador del trabajo de
copia de seguridad resultante en el cuerpo de respuesta.
Muestra de cuerpo de respuesta
JSON
{
"id": "dc62d524-427a-4093-968d-e951c0a0726e",
"name": "dc62d524-427a-4093-968d-e951c0a0726e",
"startTime": "2020-02-06T11:06:02.1327954Z",
"endTime": "2020-02-06T11:06:02.1327954Z",
"properties": {
"jobId": "39282261-cb52-43f5-9dd0-ffaf66beeaef"
}
}
Puesto que el trabajo de copia de seguridad es una operación de larga duración, se

debe seguir como se explica en el documento sobre la supervisión de trabajos con API
REST.
Pasos siguientes
Más información sobre cómo restaurar recursos compartidos de archivos de Azure
mediante la API REST.
Restauración de recursos compartidos
de archivos de Azure
Artículo • 01/06/2023
En este artículo se explica cómo usar Azure Portal para restaurar un recurso compartido
de archivos completo o archivos específicos desde un punto de restauración creado por
Azure Backup.
Selección del recurso compartido de archivos

que se va a restaurar
Para seleccionar el recurso compartido, siga estos pasos:
1. En Azure Portal , vaya al Centro de copias de seguridad y haga clic en Restaurar.
2. Seleccione Azure Files (Azure Storage) como tipo de origen de datos, elija el
recurso compartido de archivos que desea restaurar y, a continuación, haga clic en
Continuar.
Restauración de recursos compartidos de Azure
En esta sección se describe cómo restaurar:
Recurso compartido de Azure completo

Archivos o carpetas individuales
Seleccione una opción de restauración
Recuperación del recurso compartido completo
Puede usar esta opción para restaurar el recurso compartido de archivos completo
en la ubicación original o en otra alternativa.
1. Después de seleccionar Continuar en el paso anterior, se abre el panel

Restaurar. Para seleccionar el punto de restauración que quiere usar para
realizar la operación de restauración, elija el texto del vínculo Seleccionar
debajo del cuadro de texto Punto de restauración.
2. El panel de contexto Seleccionar punto de restauración se abre a la derecha y
muestra los puntos de restauración disponibles para el recurso compartido de
archivos seleccionado. Seleccione el punto de restauración que desee usar
para la operación de restauración y seleccione Aceptar.
７ Nota
De forma predeterminada, el panel Seleccionar punto de restauración

muestra los puntos de restauración de los últimos 30 días. Si desea
examinar los puntos de restauración que se crearon durante un período
de tiempo específico, proporcione el intervalo. Para ello, elija la Fecha de
inicio y la Fecha de finalización y seleccione el botón Actualizar.
3. El siguiente paso consiste en elegir la ubicación de restauración. En la sección

Destino de la recuperación, especifique dónde o cómo restaurar los datos.
Seleccione una de las dos opciones siguientes mediante el botón de
alternancia:
Ubicación original: restaure el recurso compartido de archivos completo

en la misma ubicación que el origen inicial.
Ubicación alternativa: restaure el recurso compartido de archivos
completo en una ubicación alternativa y mantenga el recurso
compartido de archivos original como está.
Restauración en la ubicación original (recurso

compartido completo)
1. Seleccione Ubicación original como Destino de recuperación y seleccione si
prefiere omitir o sobrescribir cuando haya conflictos; para ello, elija la opción
adecuada de la lista desplegable En caso de conflictos.
2. Seleccione Restaurar para iniciar la operación de restauración.
Restauración en una ubicación alternativa (recurso

compartido completo)
1. Seleccione Ubicación alternativa como Destino de recuperación.
2. Seleccione la cuenta de almacenamiento de destino en la que desea restaurar

el contenido del que se ha realizado una copia de seguridad, en la lista
desplegable Cuenta de almacenamiento.
3. En la lista desplegable Seleccionar recurso compartido de archivos, se

muestran los recursos compartidos de archivos presentes en la cuenta de
almacenamiento seleccionada en el paso 2. Seleccione el recurso compartido
de archivos en el que desea restaurar el contenido de la copia de seguridad.
4. En el cuadro Nombre de la carpeta, especifique el nombre de la carpeta que
desea crear en el recurso compartido de archivos de destino con el contenido
restaurado.
5. Seleccione si desea omitir o sobrescribir si hay conflictos.
6. Después de escribir los valores adecuados en todos los cuadros, seleccione

Restaurar para iniciar la operación de restauración.
Seguimiento de una operación de restauración

Una vez que se desencadene la operación de restauración, el servicio de copia de
seguridad crea un trabajo para realizar su seguimiento. Azure Backup muestra las
notificaciones sobre el trabajo en el portal. Para ver las operaciones del trabajo,
seleccione el hipervínculo notificaciones.
También puede supervisar el progreso de la restauración desde el almacén de Recovery

Services:
1. Vaya al Centro de copias de seguridad y haga clic en Trabajos de copia de

seguridad en el menú.
2. Filtre por los trabajos para el tipo de origen de datos y el estado del trabajo
necesarios.
3. Seleccione el nombre de la carga de trabajo correspondiente a su recurso

compartido de archivos para ver más detalles sobre la restauración, como Datos
transferidos o Número de archivos restaurados.
７ Nota
Las carpetas se restaurarán con permisos originales si hay al menos un archivo

presente en ellas.
Los puntos finales de cualquier ruta de acceso de directorio pueden provocar
errores en la restauración.
Pasos siguientes
Más información sobre cómo administrar copias de seguridad de recursos
de archivos de Azure con la CLI de Azure
Artículo • 09/04/2023
los recursos de Azure. En este artículo se explica cómo restaurar un recurso compartido
de archivos completo o archivos específicos desde un punto de restauración creado por
Azure Backup mediante la CLI de Azure. Estos pasos también se pueden llevar a cabo
con Azure PowerShell o en Azure Portal.
Al acabar este tutorial, habrá aprendido cómo realizar las siguientes operaciones con la
CLI de Azure:
Visualización de los puntos de restauración de un recurso compartido de archivos

de Azure con copia de seguridad.
Restauración de un recurso compartido de archivos de Azure completo.
Restauración de archivos o carpetas individuales.
７ Nota
Azure Backup admite ahora la restauración de varios archivos o carpetas en la

ubicación original o alternativa mediante la CLI de Azure. Consulte la sección
Restauración de varios archivos o carpetas en una ubicación original o alternativa
de este documento para obtener más información.
Prerrequisitos
En este artículo se presupone que ya tiene un recurso compartido de archivos de Azure
con una copia de seguridad hecha con Azure Backup. Si no la tiene, consulte Copia de
seguridad de recursos compartidos de archivos de Azure con la CLI para configurar la
copia de seguridad para los recursos compartidos de archivos. En este artículo, se
usarán los siguientes recursos:
Recurso compartido Cuenta de Region Detalles

de archivos almacenamiento
azurefiles afsaccount EastUS Copia de seguridad de origen hecha

con Azure Backup
Recurso compartido Cuenta de Region Detalles
de archivos almacenamiento
azurefiles1 afaccount1 EastUS Origen de destino para la recuperación

de ubicación alternativa
Puede usar una estructura similar para los recursos compartidos de archivos para probar
los distintos tipos de restauraciones que se explican en este artículo.
Preparación del entorno para la CLI de Azure





ejecute az upgrade.

Captura de puntos de recuperación para el

Use el cmdlet az backup recoverypoint list para enumerar todos los puntos de
recuperación del recurso compartido de archivos del que se ha realizado una copia de
seguridad.
En el ejemplo siguiente se captura la lista de puntos de recuperación del recurso

compartido de archivos azurefiles en la cuenta de almacenamiento afsaccount.
Azure CLI
az backup recoverypoint list --vault-name azurefilesvault --resource-group

azurefiles --container-name "StorageContainer;Storage;AzureFiles;afsaccount"
--backup-management-type azurestorage --item-name
"AzureFileShare;azurefiles" --workload-type azurefileshare --out table
También puede ejecutar el cmdlet anterior con el nombre descriptivo del contenedor y
el elemento proporcionando los dos parámetros adicionales siguientes:
--backup-management-type: azurestorage
--workload-type: azurefileshare
Azure CLI
az backup recoverypoint list --vault-name azurefilesvault --resource-group

azurefiles --container-name afsaccount --backup-management-type azurestorage
--item-name azurefiles --workload-type azurefileshare --out table
El conjunto de resultados es una lista de puntos de recuperación con detalles de tiempo

y coherencia de cada punto de restauración.
Resultados
Name Time Consistency

------------------ ------------------------- --------------------
932887541532871865 2020-01-05T07:08:23+00:00 FileSystemConsistent
El atributo Name de la salida corresponde al nombre del punto de recuperación que se

puede utilizar como valor para el parámetro --rp-name en las operaciones de
recuperación.
Recuperación de recursos compartidos

completos mediante la CLI de Azure
Puede usar esta opción para restaurar el recurso compartido de archivos completo en la
ubicación original o en otra alternativa.
Defina los parámetros siguientes para realizar operaciones de restauración:
--container-name: nombre de la cuenta de almacenamiento que hospeda el

recurso compartido de archivos original del que se ha realizado una copia de
seguridad. Para recuperar el nombre o nombre descriptivo del contenedor, use el
comando az backup container list.
--item-name: nombre del recurso compartido de archivos original del que se ha
realizado una copia de seguridad que se desea usar para la operación de
restauración. Para recuperar el nombre o nombre descriptivo del elemento de
copia de seguridad, use el comando az backup item list.
Restauración de un recurso compartido completo en la

ubicación original
Al realizar la restauración en una ubicación original, no es necesario especificar
parámetros de destino. Solo debe proporcionarse un valor para Resolve Conflict
(Resolver conflicto).
En el ejemplo siguiente se usa el cmdlet az backup restore restore-azurefileshare con el

modo de restauración establecido en originallocation para restaurar el recurso
compartido de archivos azurefiles en la ubicación original. Use el punto de recuperación
932883129628959823 obtenido con Captura de puntos de recuperación para el recurso
Azure CLI
az backup restore restore-azurefileshare --vault-name azurefilesvault --

resource-group azurefiles --rp-name 932887541532871865 --container-name
"AzureFileShare;azurefiles" --restore-mode originallocation --resolve-
conflict overwrite --out table
Resultados
Name ResourceGroup
------------------------------------ ---------------
6a27cc23-9283-4310-9c27-dcfb81b7b4bb azurefiles
El atributo Name de la salida se corresponde con el nombre del trabajo creado por el
servicio de copia de seguridad para la operación de restauración. Para realizar el
seguimiento del estado del trabajo, use el cmdlet az backup job show.
Restauración del recurso compartido completo en una
ubicación alternativa
Use esta opción para restaurar el recurso compartido de archivos en una ubicación
alternativa y mantener el original tal cual. Especifique los parámetros siguientes para la
recuperación en una ubicación alternativa:
--target-storage-account: La cuenta de almacenamiento en la que se restaura el

contenido de la copia de seguridad. La cuenta de almacenamiento de destino
debe estar en la misma ubicación que el almacén.
--target-file-share: recurso compartido de archivos de la cuenta de
almacenamiento de destino en la que se restaura el contenido de la copia de
seguridad.
--target-folder: La carpeta del recurso compartido de archivos en la que se
restauran los datos. Si el contenido de la copia de seguridad debe restaurarse en
una carpeta raíz, asigne los valores de la carpeta de destino como una cadena
vacía.
--resolve-conflict: Instrucción en caso de conflicto con los datos restaurados.
Acepta Overwrite o Skip.
En el ejemplo siguiente se usa az backup restore restore-azurefileshare con el modo de

restauración en alternatelocation para restaurar el recurso compartido de archivos
azurefiles de la cuenta de almacenamiento afsaccount en el recurso compartido de
archivos azurefiles1" de la cuenta de almacenamiento afaccount1.
Azure CLI
az backup restore restore-azurefileshare --vault-name azurefilesvault --

"AzureFileShare;azurefiles" --restore-mode alternatelocation --target-
storage-account afaccount1 --target-file-share azurefiles1 --target-folder
restoredata --resolve-conflict overwrite --out table
Resultados
Name ResourceGroup
------------------------------------ ---------------
babeb61c-d73d-4b91-9830-b8bfa83c349a azurefiles
Recuperación a nivel de elemento
Puede usar esta opción para restaurar archivos o carpetas en la ubicación original o en
otra alternativa.
Defina los parámetros siguientes para realizar operaciones de restauración:
--container-name: nombre de la cuenta de almacenamiento que hospeda el

recurso compartido de archivos original del que se ha realizado una copia de
seguridad. Para recuperar el nombre o nombre descriptivo del contenedor, use el
comando az backup container list.
--item-name: nombre del recurso compartido de archivos original del que se ha
realizado una copia de seguridad que se desea usar para la operación de
restauración. Para recuperar el nombre o nombre descriptivo del elemento de
copia de seguridad, use el comando az backup item list.
Especifique los parámetros siguientes para los elementos que desea recuperar:
SourceFilePath: La ruta de acceso absoluta del archivo que se va a restaurar en el

recurso compartido de archivos, como una cadena. Esta ruta de acceso es la misma
que se usa en los comandos az storage file download o az storage file show de la
CLI.
SourceFileType: elija si se ha seleccionado un directorio o un archivo. Admite
Directory o File.
ResolveConflict: Instrucción en caso de conflicto con los datos restaurados. Acepta
Overwrite o Skip.
Restauración de archivos o carpetas individuales en la

ubicación original
Use el cmdlet az backup restore restore-azurefiles con el modo de restauración
establecido en originallocation para restaurar archivos o carpetas en su ubicación
original.
En el ejemplo siguiente se restaura el archivo RestoreTest.txt en la ubicación original: el

recurso compartido de archivos azurefiles.
Azure CLI
az backup restore restore-azurefiles --vault-name azurefilesvault --

"AzureFileShare;azurefiles" --restore-mode originallocation --source-file-
type file --source-file-path "Restore/RestoreTest.txt" --resolve-conflict
overwrite --out table
Resultados
Name ResourceGroup
------------------------------------ ---------------
df4d9024-0dcb-4edc-bf8c-0a3d18a25319 azurefiles
Restauración de archivos o carpetas individuales en una

Para restaurar archivos o carpetas específicos en una ubicación alternativa, use el cmdlet
az backup restore restore-azurefiles con el modo de restauración establecido en
alternatelocation y especifique los parámetros de destino siguientes:
--target-storage-account: La cuenta de almacenamiento en la que se restaura el

contenido de la copia de seguridad. La cuenta de almacenamiento de destino
--target-file-share: recurso compartido de archivos de la cuenta de
seguridad.
--target-folder: La carpeta del recurso compartido de archivos en la que se
restauran los datos. Si el contenido de la copia de seguridad debe restaurarse en
una carpeta raíz, asigne el valor de la carpeta de destino como cadena vacía.
En el ejemplo siguiente se restaura el archivo RestoreTest.txt presente al principio en el

recurso compartido de archivos azurefiles en una ubicación alternativa: la carpeta
restoredata del recurso compartido de archivos azurefiles1 hospedado en la cuenta de
almacenamiento afaccount1.
Azure CLI

"AzureFileShare;azurefiles" --restore-mode alternatelocation --target-
storage-account afaccount1 --target-file-share azurefiles1 --target-folder
restoredata --resolve-conflict overwrite --source-file-type file --source-
file-path "Restore/RestoreTest.txt" --out table
Resultados
Name ResourceGroup
------------------------------------ ---------------
df4d9024-0dcb-4edc-bf8c-0a3d18a25319 azurefiles
Restauración de varios archivos o carpetas en

una ubicación original o alternativa
Para realizar la restauración de varios elementos, pase el valor para el parámetro source-
file-path como rutas separadas por espacios de todos los archivos o carpetas que
quiera restaurar.
En el ejemplo siguiente se restauran los archivos Restore.txt y AFS testing Report.docx a

su ubicación original.
Azure CLI

"AzureFileShare;azurefiles" --restore-mode originallocation --source-file-
type file --source-file-path "Restore Test.txt" "AFS Testing Report.docx" --
resolve-conflict overwrite --out table
El resultado será similar al siguiente:
Resultados
Name ResourceGroup
------------------------------------ ---------------
649b0c14-4a94-4945-995a-19e2aace0305 azurefiles
Si quiere restaurar varios archivos en una ubicación alternativa, use el comando anterior
y especifique parámetros relacionados con el destino, tal y como se describe en la
sección Restauración de archivos o carpetas individuales en una ubicación alternativa.
Pasos siguientes
Obtenga más información sobre la Administración de copias de seguridad de recursos
compartidos de archivos de Azure con la CLI de Azure.
Restauración de Azure Files con
PowerShell
Artículo • 01/06/2023
En este artículo se explica cómo restaurar un recurso compartido de archivos completo,

o archivos específicos, desde un punto de restauración creado por el servicio Azure
Backup mediante Azure PowerShell.
Puede restaurar un recurso compartido de archivos al completo o archivos específicos

de dicho recurso compartido. La restauración puede llevarse a cabo en la ubicación
original o en una ubicación alternativa.
２ Advertencia
Asegúrese de que la versión de PowerShell se actualice a la versión mínima de

"Az.RecoveryServices 2.6.0" para las copias de seguridad de AFS. Para más
información, consulte la sección que describe el requisito de este cambio.
７ Nota
Azure Backup admite ahora la restauración de varios archivos o carpetas en la

ubicación original o alternativa mediante PowerShell. Consulte esta sección del
documento para más información sobre cómo hacerlo.
Captura de puntos de recuperación

Use Get-AzRecoveryServicesBackupRecoveryPoint para enumerar todos los puntos de
recuperación del elemento del que se ha realizado la copia de seguridad.
En el script siguiente:
La variable $rpes una matriz de puntos de recuperación para el elemento de copia

de seguridad seleccionado de los últimos siete días.
La matriz se ordena en orden inverso de tiempo con el punto de recuperación más
reciente en el índice 0.
Use la indexación de matrices de PowerShell estándar para seleccionar el punto de
recuperación.
En el ejemplo, $rp[0] selecciona el último punto de recuperación.
PowerShell
$vault = Get-AzRecoveryServicesVault -ResourceGroupName "azurefiles" -Name

"azurefilesvault"
$Container = Get-AzRecoveryServicesBackupContainer -ContainerType
AzureStorage -Status Registered -FriendlyName "afsaccount" -VaultId
$vault.ID
$BackupItem = Get-AzRecoveryServicesBackupItem -Container $Container -
WorkloadType AzureFiles -VaultId $vault.ID -FriendlyName "azurefiles"
$startDate = (Get-Date).AddDays(-7)
$endDate = Get-Date
$rp = Get-AzRecoveryServicesBackupRecoveryPoint -Item $BackupItem -VaultId
$vault.ID -StartDate $startdate.ToUniversalTime() -EndDate
$enddate.ToUniversalTime()
$rp[0] | fl
La salida será similar a la siguiente.
PowerShell
FileShareSnapshotUri :
https://testStorageAcct.file.core.windows.net/testAzureFS?
sharesnapshot=2018-11-20T00:31:04.00000
00Z
RecoveryPointType : FileSystemConsistent
RecoveryPointTime : 11/20/2018 12:31:05 AM
RecoveryPointId : 86593702401459
ItemName : testAzureFS
Id : /Subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/testVaultRG/providers/Micros
oft.RecoveryServices/vaults/testVault/backupFabrics/Azure/protectionContaine
rs/StorageContainer;storage;teststorageRG;testStorageAcct/protectedItems/Azu
reFileShare;testAzureFS/recoveryPoints/86593702401462
WorkloadType : AzureFiles
ContainerName : storage;teststorageRG;testStorageAcct
ContainerType : AzureStorage
BackupManagementType : AzureStorage
Una vez seleccionado el punto de recuperación adecuado, restaure el recurso

compartido de archivos o el archivo en la ubicación original o en una ubicación
alternativa.
Restauración de un recurso compartido de

archivos de Azure en una ubicación alternativa
Use Restore-AzRecoveryServicesBackupItem para restaurar en el punto de recuperación
seleccionado. Especifique estos parámetros para identificar la ubicación alternativa:
TargetStorageAccountName: La cuenta de almacenamiento en la que se restaura
el contenido de la copia de seguridad. La cuenta de almacenamiento de destino
TargetFileShareName: Los recursos compartidos de archivos de la cuenta de
seguridad.
TargetFolder: La carpeta del recurso compartido de archivos en la que se restauran
los datos. Si el contenido de la copia de seguridad debe restaurarse en una carpeta
raíz, asigne los valores de la carpeta de destino como una cadena vacía.
Overwrite o Skip.
Ejecute el cmdlet con los parámetros de la manera siguiente:
PowerShell
Restore-AzRecoveryServicesBackupItem -RecoveryPoint $rp[0] -

TargetStorageAccountName "TargetStorageAcct" -TargetFileShareName "DestAFS"
-TargetFolder "testAzureFS_restored" -ResolveConflict Overwrite
El comando devuelve un trabajo con un identificador del cual se puede realizar un

seguimiento, como se indica en el ejemplo siguiente.
PowerShell

EndTime JobID
------------ --------- ------ ---------
------- -----
testAzureFS Restore InProgress 12/10/2018
9:56:38 AM 9fd34525-6c46-496e-980a-
3740ccb2ad75
Restauración de un archivo de Azure en una

Use Restore-AzRecoveryServicesBackupItem para restaurar en el punto de recuperación
seleccionado. Especifique estos parámetros para identificar la ubicación alternativa y
para identificar de forma única el archivo que quiere restaurar.
TargetStorageAccountName: La cuenta de almacenamiento en la que se restaura

el contenido de la copia de seguridad. La cuenta de almacenamiento de destino
TargetFileShareName: Los recursos compartidos de archivos de la cuenta de
seguridad.
TargetFolder: La carpeta del recurso compartido de archivos en la que se restauran
los datos. Si el contenido de la copia de seguridad debe restaurarse en una carpeta
raíz, asigne los valores de la carpeta de destino como una cadena vacía.
SourceFilePath: La ruta de acceso absoluta del archivo que se va a restaurar en el
recurso compartido de archivos, como una cadena. Esta ruta de acceso es la misma
ruta utilizada en el cmdlet de PowerShell Get-AzStorageFile.
SourceFileType: Indica si se ha seleccionado un directorio o un archivo. Admite
Directory o File.
Overwrite o Skip.
Los parámetros adicionales (SourceFilePath y SourceFileType) solo están relacionadas

con el archivo individual que quiere restaurar.
PowerShell
Restore-AzRecoveryServicesBackupItem -RecoveryPoint $rp[0] -

TargetStorageAccountName "TargetStorageAcct" -TargetFileShareName "DestAFS"
-TargetFolder "testAzureFS_restored" -SourceFileType File -SourceFilePath
"TestDir/TestDoc.docx" -ResolveConflict Overwrite
Este comando devuelve un trabajo con un identificador del cual se puede realizar un
seguimiento, como se indica en la sección anterior.
Restauración de archivos y recursos

compartidos de archivos de Azure en la
ubicación original
Al restaurar en una ubicación original, no es necesario especificar parámetros
relacionados con el destino. Solo debe proporcionarse ResolveConflict.
Sobrescribir un recurso compartido de archivos de Azure

PowerShell
Restore-AzRecoveryServicesBackupItem -RecoveryPoint $rp[0] -ResolveConflict

Overwrite
Sobrescribir un archivo de Azure
PowerShell
Restore-AzRecoveryServicesBackupItem -RecoveryPoint $rp[0] -SourceFileType

File -SourceFilePath "TestDir/TestDoc.docx" -ResolveConflict Overwrite
Restauración de varios archivos o carpetas en

una ubicación original o alternativa
Utilice el comando Restore-AzRecoveryServicesBackupItem pasando la ruta de acceso
de todos los archivos o carpetas que desea restaurar como valor para el parámetro
MultipleSourceFilePath.
Restauración de varios archivos

En el siguiente script, se intenta restaurar los archivos FileSharePage.png y MyTestFile.txt.
PowerShell

"azurefilesvault"

$vault.ID

$RP = Get-AzRecoveryServicesBackupRecoveryPoint -Item $BackupItem -VaultId

$vault.ID
$files = ("FileSharePage.png", "MyTestFile.txt")
Restore-AzRecoveryServicesBackupItem -RecoveryPoint $RP[0] -

MultipleSourceFilePath $files -SourceFileType File -ResolveConflict
Overwrite -VaultId $vault.ID -VaultLocation $vault.Location
Restauración de varios directorios

En el siguiente script, se intenta restaurar los directorios zrs1_restore y Restore.
PowerShell
"azurefilesvault"

$vault.ID

$RP = Get-AzRecoveryServicesBackupRecoveryPoint -Item $BackupItem -VaultId

$vault.ID
$files = ("Restore","zrs1_restore")
Restore-AzRecoveryServicesBackupItem -RecoveryPoint $RP[0] -

MultipleSourceFilePath $files -SourceFileType Directory -ResolveConflict
Overwrite -VaultId $vault.ID -VaultLocation $vault.Location
El resultado será similar al siguiente:
Resultados

EndTime JobID
------------ --------- ------ ---------
------- -----
azurefiles Restore InProgress 4/5/2020 8:01:24 AM
cd36abc3-0242-44b1-9964-0a9102b74d57
Si desea restaurar varios archivos o carpetas en una ubicación alternativa, utilice los
scripts anteriores especificando los valores de parámetros relacionados con la ubicación
de destino, tal como se ha explicado anteriormente en Restauración de un archivo de
Azure en una ubicación alternativa.
Pasos siguientes
Aprenda a restaurar Azure Files en Azure Portal.
de archivos de Azure con la API REST
Artículo • 01/06/2023
En este artículo se explica cómo restaurar un recurso compartido de archivos completo

o archivos específicos desde un punto de restauración creado por Azure Backup
mediante API REST.
Al acabar este tutorial, habrá aprendido cómo realizar las siguientes operaciones con
API REST:
Visualización de los puntos de restauración de un recurso compartido de archivos

de Azure con copia de seguridad.
Restauración de un recurso compartido de archivos de Azure completo.
Restauración de archivos o carpetas individuales.
Prerrequisitos
Damos por sentado que ya tiene un recurso compartido de archivos que quiere
restaurar. Si no es así, consulte Copia de seguridad de recurso compartido de archivos
de Azure con API REST para aprender a crear uno.
En este artículo, usaremos los siguientes recursos:

Cuenta de almacenamiento: afsaccount
Recurso compartido de archivos: azurefiles
Captura de ContainerName y
ProtectedItemName
Para la mayoría de las llamadas API relacionadas con la restauración, debe pasar valores
para los parámetros de URI {containerName} y {protectedItemName}. Use el atributo ID
en el cuerpo de respuesta de la operación GET backupprotectableitems para recuperar
los valores de estos parámetros. En nuestro ejemplo, el identificador del recurso
compartido de archivos que queremos proteger es el siguiente:
"/Subscriptions/ef4ab5a7-c2c0-4304-af80-
af49f48af3d1/resourceGroups/azurefiles/providers/Microsoft.RecoveryServices/vaults/
azurefilesvault/backupFabrics/Azure/protectionContainers/storagecontainer;storage;a
zurefiles;afsaccount/protectableItems/azurefileshare;azurefiles
Por lo tanto, los valores se convierten de la siguiente manera:
{containername}: storagecontainer;storage;azurefiles;afsaccount
Captura de puntos de recuperación para el

recurso compartido de archivos de Azure con
copia de seguridad
Para restaurar los archivos o recursos compartidos de archivos con copia de seguridad,
seleccione primero un punto de recuperación para realizar la operación de restauración.
Se pueden enumerar los puntos de recuperación disponibles de un elemento con copia
de seguridad mediante la llamada API REST para obtener la lista e puntos de
recuperación. Es una operación GET con todos los valores pertinentes.
HTTP
GET
s/{protectedItemName}/recoveryPoints?api-version=2019-05-13&$filter=
{$filter}
Establezca los valores de URI de la manera siguiente:
{fabricName}: Azure
{containername}: storagecontainer;storage;azurefiles;afsaccount
{ResourceGroupName}: azurefiles
El identificador URI de GET tiene todos los parámetros necesarios. No es necesario otro
cuerpo de solicitud.
HTTP
GET https://management.azure.com/Subscriptions/ef4ab5a7-c2c0-4304-af80-
af49f48af3d1/resourceGroups/azurefiles/providers/Microsoft.RecoveryServices/
iner;storage;azurefiles;afsaccount/protectedItems/AzureFileShare;azurefiles/
recoveryPoints?api-version=2019-05-13
Respuesta de ejemplo para la captura de puntos de

recuperación
Una vez que se emita el identificador URI de GET, se devuelve una respuesta 200:
HTTP
HTTP/1.1" 200 None

'Transfer-Encoding': 'chunked'
'Content-Type': 'application/json'
'Content-Encoding': 'gzip'
'Expires': '-1'
'Vary': 'Accept-Encoding'
'x-ms-request-id': 'd68d7951-7d97-4c49-9a2d-7fbaab55233a'
'x-ms-client-request-id': '4edb5a58-47ea-11ea-a27a-0a580af41908, 4edb5a58-
47ea-11ea-a27a-0a580af41908'
'Server': 'Microsoft-IIS/10.0'
'x-ms-correlation-request-id': 'd68d7951-7d97-4c49-9a2d-7fbaab55233a'
'x-ms-routing-request-id': 'WESTEUROPE:20200205T073708Z:d68d7951-7d97-4c49-
9a2d-7fbaab55233a'
'Date': 'Wed, 05 Feb 2020 07:37:08 GMT'
{
“value”:[
{
"eTag": null,
"id": "/Subscriptions/ef4ab5a7-c2c0-4304-af80-
recoveryPoints/932881138555802864",
"location": null,
"name": "932881138555802864",
"properties": {
"fileShareSnapshotUri":
"https://afsaccount.file.core.windows.net/azurefiles?sharesnapshot=2020-02-
04T08:01:35.0000000Z",
"objectType": "AzureFileShareRecoveryPoint",
"recoveryPointSizeInGb": 1,
"recoveryPointTime": "2020-02-04T08:01:35+00:00",
"recoveryPointType": "FileSystemConsistent"
},
"resourceGroup": "azurefiles",
"tags": null,
"type":
tedItems/recoveryPoints"
},
{
"eTag": null,
"location": null,
"name": "932878582606969225",
"properties": {
03T08:05:30.0000000Z",
},
"tags": null,
"type":
},
{
"eTag": null,
"location": null,
"name": "932890167574511261",
"properties": {
02T08:03:50.0000000Z",
},
"tags": null,
"type":
},
El punto de recuperación se identifica con el campo {name} en la respuesta anterior.
Recuperación de recursos compartidos

completos mediante API REST
Use esta opción de restauración para restaurar el recurso compartido de archivos
completo en la ubicación original o en otra alternativa. Desencadenar la restauración es
una solicitud POST y puede realizar esta operación mediante API REST para
desencadenar la restauración.
HTTP
POST
s/{protectedItemName}/recoveryPoints/{recoveryPointId}/restore?api-
version=2019-05-13
Los valores {containerName} y {protectedItemName} son los que se establecen aquí y

recoveryPointID es el campo {name} del punto de recuperación mencionado
anteriormente.
HTTP
POST https://management.azure.com/Subscriptions/ef4ab5a7-c2c0-4304-af80-
iner;storage;azurefiles;afsaccount/protectedItems/AzureFileShare%3Bazurefile
s/recoveryPoints/932886657837421071/restore?api-version=2019-05-13'

Para desencadenar una restauración para un recurso compartido de archivos, a
continuación se incluyen los componentes del cuerpo de la solicitud:
Propiedades AzureFileShareRestoreRequest Propiedades de RestoreRequestResource

detalles, consulte el documento de API REST para desencadenar la restauración.
Restauración en una ubicación original
Ejemplo de cuerpo de la solicitud para efectuar la restauración en

la ubicación original
El cuerpo de solicitud siguiente define las propiedades necesarias para desencadenar
una restauración del recurso compartido de archivos de Azure:
JSON
{
"properties":{
"objectType":"AzureFileShareRestoreRequest",
"recoveryType":"OriginalLocation",
"sourceResourceId":"/subscriptions/ef4ab5a7-c2c0-4304-af80-
af49f48af3d1/resourceGroups/AzureFiles/providers/Microsoft.Storage/storageAc
counts/afsaccount",
"copyOptions":"Overwrite",
"restoreRequestType":"FullShareRestore"
}
}
Restauración a una ubicación alternativa

Especifique los parámetros siguientes para la recuperación en una ubicación alternativa:
targetResourceId: La cuenta de almacenamiento en la que se restaura el contenido

de la copia de seguridad. La cuenta de almacenamiento de destino debe estar en
la misma ubicación que el almacén.
name: recurso compartido de archivos de la cuenta de almacenamiento de destino
en la que se restaura el contenido de la copia de seguridad.
targetFolderPath: La carpeta del recurso compartido de archivos en la que se
restauran los datos.
Ejemplo de cuerpo de la solicitud para efectuar la restauración en

una ubicación alternativa
El siguiente cuerpo de la solicitud restaura el recurso compartido de archivos azurefiles

de la cuenta de almacenamiento afsaccount en el recurso compartido de archivos
azurefiles1 de la cuenta de almacenamiento afaccount1.
JSON
{
"properties":{
"recoveryType":"AlternateLocation",
counts/afsaccount",
"restoreRequestType":"FullShareRestore",
"restoreFileSpecs":[
{
"targetFolderPath":"restoredata"
}
],
"targetDetails":{
"name":"azurefiles1",
"targetResourceId":"/subscriptions/ef4ab5a7-c2c0-4304-af80-
counts/afaccount1"
}
}
}
Response
La activación de una operación de restauración es una operación asincrónica. Esta
operación crea otra operación de la que se debe hacer un seguimiento por separado.
Ejemplo de respuesta
Una vez enviado el URI de POST para desencadenar una restauración, la respuesta inicial
es 202 (Aceptado) con un encabezado de ubicación o Azure-async-header.
HTTP
HTTP/1.1" 202
'Expires': '-1'
'Location': 'https://management.azure.com/Subscriptions/ef4ab5a7-c2c0-4304-
af80-
operationResults/68ccfbc1-a64f-4b29-b955-314b5790cfa9?api-version=2019-05-
13'
'Retry-After': '60'
'Azure-AsyncOperation':
'https://management.azure.com/Subscriptions/ef4ab5a7-c2c0-4304-af80-
operationsStatus/68ccfbc1-a64f-4b29-b955-314b5790cfa9?api-version=2019-05-
13'
'x-ms-request-id': '2426777d-c5ec-44b6-a324-384f8947460c'
'x-ms-client-request-id': '3c743096-47eb-11ea-ae90-0a580af41908, 3c743096-
47eb-11ea-ae90-0a580af41908'
'x-ms-correlation-request-id': '2426777d-c5ec-44b6-a324-384f8947460c'
'x-ms-routing-request-id': 'WESTEUROPE:20200205T074347Z:2426777d-c5ec-44b6-
a324-384f8947460c'
'Date': 'Wed, 05 Feb 2020 07:43:47 GMT'

HTTP
vaults/azurefilesvault/backupOperations/68ccfbc1-a64f-4b29-b955-
314b5790cfa9?api-version=2016-12-01
Una vez completada la operación, devuelve 200 (OK) con el identificador del trabajo de
restauración resultante en el cuerpo de respuesta.
HTTP
HTTP/1.1" 200
'Expires': '-1'
'x-ms-request-id': '41ee89b2-3be4-40d8-8ff6-f5592c2571e3'
'x-ms-client-request-id': '3c743096-47eb-11ea-ae90-0a580af41908, 3c743096-
47eb-11ea-ae90-0a580af41908'
'Server': 'Microsoft-IIS/10.0'
'x-ms-correlation-request-id': '41ee89b2-3be4-40d8-8ff6-f5592c2571e3'
'x-ms-routing-request-id': 'WESTEUROPE:20200205T074348Z:41ee89b2-3be4-40d8-
8ff6-f5592c2571e3'
'Date': 'Wed, 05 Feb 2020 07:43:47 GMT'
{
vaults/azurefilesvault/backupJobs/a7e97e42-4e54-4d4b-b449-26fcf946f42c",
"location": null,
"name": "a7e97e42-4e54-4d4b-b449-26fcf946f42c",
"properties": {
"actionsInfo": [
"Cancellable"
],
"activityId": "3c743096-47eb-11ea-ae90-0a580af41908",
"duration": "0:00:01.863098",
"endTime": null,
"entityFriendlyName": "azurefiles",
"errorDetails": null,
"extendedInfo": {
"dynamicErrorMessage": null,
"propertyBag": {},
"tasksList": []
},
"jobType": "AzureStorageJob",
"operation": "Restore",
"startTime": "2020-02-05T07:43:47.144961+00:00",
"status": "InProgress",
"storageAccountName": "afsaccount",
"storageAccountVersion": "Storage"
},
"tags": null,
"type": "Microsoft.RecoveryServices/vaults/backupJobs"
}
En la recuperación de ubicación alternativa, el cuerpo de la respuesta será similar al

siguiente:
HTTP
{
vaults/azurefilesvault/backupJobs/7e0ee41e-6e31-4728-a25c-98ff6b777641",
"location": null,
"name": "7e0ee41e-6e31-4728-a25c-98ff6b777641",
"properties": {
"actionsInfo": [
"Cancellable"
],
"activityId": "6077be6e-483a-11ea-a915-0a580af4ad72",
"duration": "0:00:02.171965",
"endTime": null,
"extendedInfo": {
"dynamicErrorMessage": null,
"propertyBag": {
"Data Transferred (in MB)": "0",
"Job Type": "Recover to an alternate file share",
"Number Of Failed Files": "0",
"Number Of Restored Files": "0",
"Number Of Skipped Files": "0",
"RestoreDestination": "afaccount1/azurefiles1/restoredata",
"Source File Share Name": "azurefiles",
"Source Storage Account Name": "afsaccount",
"Target File Share Name": "azurefiles1",
"Target Storage Account Name": "afaccount1"
},
"tasksList": []
},
"operation": "Restore",
"startTime": "2020-02-05T17:10:18.106532+00:00",
"status": "InProgress",
"storageAccountVersion": "ClassicCompute"
},
"tags": null,
}
Puesto que el trabajo de copia de seguridad es una operación de larga duración, se

debe seguir como se explica en el documento sobre la supervisión de trabajos con API
REST.
Recuperación de nivel de elemento mediante

API REST
Puede usar esta opción para restaurar archivos o carpetas en la ubicación original o en
otra alternativa.
HTTP
POST
s/{protectedItemName}/recoveryPoints/{recoveryPointId}/restore?api-
version=2019-05-13
Los valores {containerName} y {protectedItemName} son los que se establecen aquí y

recoveryPointID es el campo {name} del punto de recuperación mencionado
anteriormente.
HTTP
POST https://management.azure.com/Subscriptions/ef4ab5a7-c2c0-4304-af80-
iner;storage;azurefiles;afsaccount/protectedItems/AzureFileShare%3Bazurefile
s/recoveryPoints/932886657837421071/restore?api-version=2019-05-13'
Creación del cuerpo de la solicitud para la recuperación

de nivel de elemento mediante la API de REST
Para desencadenar una restauración para un recurso compartido de archivos, a
continuación se incluyen los componentes del cuerpo de la solicitud:
Propiedades AzureFileShareRestoreRequest Propiedades de RestoreRequestResource
detalles, consulte el documento de API REST para desencadenar la restauración.
Restauración en la ubicación original para la recuperación

de nivel de elemento mediante la API de REST
El siguiente cuerpo de solicitud es para restaurar el archivo Restoretest.txt en el recurso
compartido de archivos azurefiles de la cuenta de almacenamiento afsaccount.
JSON
{
"properties":{
"recoveryType":"OriginalLocation",
{
"fileSpecType":"File",
"path":"RestoreTest.txt",
"targetFolderPath":null
}
],
"restoreRequestType":"ItemLevelRestore",
af49f48af3d1/resourceGroups/azurefiles/providers/Microsoft.storage/storageAc
counts/afsaccount",
"targetDetails":null
}
}
Restauración en una ubicación alternativa para la

recuperación de nivel de elemento mediante la API de
REST
El siguiente cuerpo de la solicitud es para restaurar el archivo Restoretest.txt en el
recurso compartido de archivos azurefiles de la cuenta de almacenamiento afsaccount
en la carpeta restoredata del recurso compartido de archivos azurefiles1 de la cuenta de
almacenamiento afaccount1.
JSON
{
"properties":{
"recoveryType":"AlternateLocation",
counts/afsaccount",
"restoreRequestType":"ItemLevelRestore",
{
"path":"Restore/RestoreTest.txt",
"fileSpecType":"File",
"targetFolderPath":"restoredata"
}
],
"targetDetails":{
"name":"azurefiles1",
"targetResourceId":"/subscriptions/ef4ab5a7-c2c0-4304-af80-
counts/afaccount1"
}
}
}
La respuesta debe controlarse de la misma manera que se explicó anteriormente para

las restauraciones de recursos compartidos completos.
Pasos siguientes
Obtenga información sobre cómo administrar copias de seguridad de recursos
compartidos de archivos de Azure mediante API REST.
Administración de copias de seguridad
de recursos compartidos de archivos de
Azure
Artículo • 01/06/2023
En este artículo se describen las tareas comunes para administrar y supervisar los
recursos compartidos de archivos de Azure de los que Azure Backup realiza una copia
de seguridad. Aprenderá a realizar tareas de administración en el Centro de copias de
seguridad.
Supervisión de trabajos
Al desencadenar operaciones de copia de seguridad o restauración, el servicio de copia
de seguridad crea un trabajo para realizar un seguimiento. Puede supervisar el progreso
de todos los trabajos en la página Backup Jobs (Trabajos de copia de seguridad).
Para abrir la página Backup Jobs (Trabajos de copia de seguridad), siga estos pasos:
1. Vaya a Centro de copias de seguridad y seleccione Trabajos de copia de

seguridad en la sección Supervisión.
En el panel Trabajos de copia de seguridad, se muestra el estado de todos los

trabajos.
2. Seleccione Azure Files (Azure Storage) como el tipo de origen de datos y

seleccione cualquier fila para ver los detalles del trabajo concreto.

７ Nota
Puesto que no se transfiere ningún dato al almacén, los datos transferidos

en MB son 0 en el caso de los trabajos de copia de seguridad
correspondientes a Azure Files.
Supervisión mediante informes de Azure

Backup
Azure Backup proporciona una solución de informes que usa registros de Azure Monitor
y libros de Azure. Estos recursos le ayudan a obtener mejores conclusiones sobre las
copias de seguridad. Puede aprovechar estos informes para obtener visibilidad de los
elementos de copia de seguridad de Azure Files, los trabajos en el nivel de elemento y
los detalles de las directivas activas. Con la característica Informe de correo electrónico
disponible en los informes de Backup, puede crear tareas automatizadas para recibir
informes periódicos por correo electrónico. Aprenda a configurar y ver los informes de
Azure Backup.
Creación de una nueva directiva

Puede crear una directiva para realizar una copia de seguridad de los recursos
compartidos de archivos de Azure desde la sección Directivas de copia de seguridad
del Centro de copias de seguridad. Todas las directivas que se crean al configurar la
copia de seguridad de los recursos compartidos de archivos se muestran con Tipo de
directiva establecido en Recurso compartido de archivos de Azure.
Para crear una nueva directiva de copia de seguridad, siga estos pasos:
1. En el panel Directivas de copia de seguridad del Centro de copias de seguridad,

seleccione +Agregar.

2. Seleccione Azure Files (Azure Storage) como tipo de origen de datos, seleccione
el almacén en el que se debe crear la directiva y, a continuación, haga clic en
Continuar.
3. Cuando se abra el panel Directiva de copia de seguridad de Recurso compartido

de archivos de Azure, especifique el nombre de la directiva.
4. En Programación de copia de seguridad, seleccione una frecuencia adecuada para

las copias de seguridad: Diaria o Cada hora.
Diaria: desencadena una copia de seguridad al día. Para la frecuencia diaria,
seleccione los valores adecuados para:
Hora: marca de tiempo en la que se debe desencadenar el trabajo de
copia de seguridad.
Zona horaria: zona horaria correspondiente del trabajo de copia de
seguridad.
Cada hora: desencadena varias copias de seguridad al día. Para la frecuencia

de cada hora, seleccione los valores adecuados para:
Programación: intervalo de tiempo (en horas) entre las copias de
seguridad consecutivas.
Hora de inicio: hora a la que se debe desencadenar el primer trabajo de
copia de seguridad del día.
Duración: representa la ventana de copia de seguridad (en horas), es decir,
el intervalo de tiempo en el que se deben desencadenar los trabajos de
copia de seguridad según la programación seleccionada.
Zona horaria: zona horaria correspondiente del trabajo de copia de
seguridad.
Por ejemplo, tiene el requisito de RPO (objetivo de punto de recuperación)

de 4 horas y el horario de trabajo es de 9 a. m. a 9 p. m. Para cumplir estos
requisitos, la configuración de la programación de copia de seguridad sería:
Programación: cada 4 horas
Hora de inicio: 9 a. m.
Duración: 12 horas
En función de la selección, los detalles del trabajo de copia de seguridad (las

marcas de tiempo en las que se desencadenaría el trabajo de copia de
seguridad) se muestran en la hoja de la directiva de copia de seguridad.
5. En Duración de retención, especifique los valores de retención adecuados para las

copias de seguridad, etiquetados como diaria, semanal, mensual o anual.
6. Después de definir todos los atributos de la directiva, haga clic en Crear.
Visualización de directiva
Para ver las directivas de copia de seguridad existentes:
1. Vaya a Centro de copias de seguridad y seleccione Directivas de copia de

seguridad en la sección Administrar.
Aparecen todas las directivas de copia de seguridad configuradas en el almacén.


2. Para ver directivas específicas de Azure Files (Azure Storage) , seleccione Recurso
compartido de archivos de Azure como el tipo de origen de datos.
Modificación de directivas
Puede modificar una directiva de copia de seguridad para cambiar la frecuencia de las
copias de seguridad o la duración de retención.
Para modificar una directiva:
1. Vaya a Centro de copias de seguridad y seleccione Directivas de copia de

seguridad en la sección Administrar.
Aparecen todas las directivas de copia de seguridad configuradas en los

almacenes.

2. Para ver las directivas específicas de un recurso compartido de archivos de Azure,
seleccione Azure Files (Azure Storage) como el tipo de origen de datos.
Haga clic en la directiva que desea actualizar.
3. Se abrirá el panel Programación. Edite la Programación de copia de seguridad y

la Duración de retención según sea necesario y seleccione Guardar.
Verá el mensaje Actualización en curso en el panel. Una vez que se actualicen

correctamente los cambios en la directiva, verá el mensaje La directiva de copia de
seguridad se actualizó correctamente.
Detención de la protección en un recurso

Hay dos maneras de dejar de proteger recursos compartidos de archivos de Azure:
Detener todos los trabajos futuros de copia de seguridad y eliminar todos los
puntos de recuperación.
Detener todos los trabajos futuros de copia de seguridad pero dejar los puntos de
recuperación.
Puede que dejar los puntos de recuperación en el almacenamiento conlleve un costo

asociado, dado que las instantáneas subyacentes creadas por Azure Backup se
conservarán. La ventaja de dejarlos es que puede restaurar el recurso compartido de
archivos más adelante. Para más información sobre el costo de dejar los puntos de
recuperación, consulte la información sobre precios . Si opta por eliminar todos los
puntos de recuperación, no podrá restaurar el recurso compartido de archivos.
Para dejar de proteger recursos compartidos de archivos de Azure, siga estos pasos:
1. Vaya al Centro de copias de seguridad, seleccione Instancias de copia de

seguridad en el menú y, después, seleccione Azure Files (Azure Storage) como el
tipo de origen de datos.
2. Seleccione el elemento de copia de seguridad para el que desea detener la

protección.
3. Seleccione la opción Detener copia de seguridad.
4. En el panel Detener copia de seguridad, seleccione Retener datos de copia de

seguridad o Eliminar datos de la copia de seguridad. Luego, seleccione Detener
copia de seguridad.
Reanudación de la protección en un recurso
Si seleccionó la opción Retener datos de copia de seguridad al detener la protección
del recurso compartido de archivos, es posible reanudar la protección. Si seleccionó la
opción Eliminar datos de la copia de seguridad, no se puede reanudar la protección del
Para reanudar la protección del recurso compartido de archivos de Azure:
1. Vaya al Centro de copias de seguridad, seleccione Instancias de copia de

seguridad en el menú y, después, seleccione Azure Files (Azure Storage) como el
tipo de origen de datos.

2. Seleccione el elemento de copia de seguridad para el que desea reanudar la

protección.
3. Seleccione la opción Reanudar copia de seguridad.
4. Se abrirá el panel Directiva de copia de seguridad. Seleccione la directiva que

desee para reanudar la copia de seguridad.
5. Después de seleccionar una directiva de copia de seguridad, seleccione Guardar.
Verá el mensaje Actualización en curso en el portal. Después de que la copia de

seguridad se reanude correctamente, verá el mensaje La directiva de copia de
seguridad del recurso compartido de archivos de Azure protegido se actualizó
correctamente.
Eliminación de datos de copia de seguridad
Puede eliminar la copia de seguridad de un recurso compartido de archivos durante el
trabajo Detener copia de seguridad o en cualquier momento después de detener la
protección. Podría ser conveniente esperar días o semanas antes de eliminar los puntos
de recuperación. Al eliminar datos de copia de seguridad, no se pueden elegir los
puntos de recuperación específicos que se van a eliminar. Si decide eliminar los datos
de copia de seguridad, se eliminarán todos los puntos de recuperación asociados con el
En el procedimiento siguiente se presupone que se ha detenido la protección del

Para eliminar los datos de copia de seguridad del recurso compartido de archivos de
Azure:
1. Una vez detenido el trabajo de copia de seguridad, dispondrá de las opciones

Reanudar copia de seguridad y Eliminar datos de la copia de seguridad en el
panel Elemento de copia de seguridad. Seleccione la opción Eliminar datos de la
copia de seguridad.
2. Se abrirá el panel Eliminar datos de la copia de seguridad. Escriba el nombre del

recurso compartido de archivos para confirmar la eliminación. Opcionalmente,
puede proporcionar más información en los cuadros Motivo o Comentarios.
Cuando esté seguro de querer eliminar los datos de copia de seguridad, seleccione
Eliminar.
Anulación del registro de una cuenta de
almacenamiento
Para proteger los recursos compartidos de archivos en una cuenta de almacenamiento
determinada mediante un almacén de Recovery Services diferente, primero debe
detener la protección de todos los recursos compartidos de archivos en esa cuenta de
almacenamiento. A continuación, anule el registro de la cuenta del almacén de Recovery
Services que se usa actualmente para la protección.
En el procedimiento siguiente se presupone que se ha detenido la protección de todos

los recursos compartidos de archivos de la cuenta de almacenamiento cuyo registro
desea anular.
Para anular el registro de la cuenta de almacenamiento:
1. Abra el almacén de Recovery Services en el que está registrada la cuenta de

almacenamiento.
2. En el panel Información general, seleccione la opción Infraestructura de Backup

en la sección Administrar.
3. El panel Infraestructura de Backup se abrirá. Seleccione Cuentas de
almacenamiento en la sección Cuentas de Azure Storage.
4. Después de seleccionar Cuentas de almacenamiento, se mostrará una lista de las

cuentas de almacenamiento registradas en el almacén.
5. Haga clic con el botón derecho en la cuenta cuyo registro desee eliminar y
seleccione Anular registro.
Pasos siguientes
Para más información, vea Solución de problemas de las copias de seguridad de
Azure con la CLI de Azure
Artículo • 09/03/2023
los recursos de Azure. En este artículo se explica cómo realizar tareas para administrar y
supervisar los recursos compartidos de archivos de Azure de los que se ha realizado una
copia de seguridad mediante Azure Backup. También puede llevar a cabo estos pasos en
Azure Portal .
Prerrequisitos
En este artículo se da por supuesto que ya tiene una copia de seguridad de un recurso
compartido de archivos de Azure realizada por Azure Backup. Si no la tiene, consulte
Copia de seguridad de recursos compartidos de archivos de Azure con la CLI para
configurar la copia de seguridad para los recursos compartidos de archivos. En este
artículo, se usarán los siguientes recursos:

Cuenta de almacenamiento: afsaccount
Recurso compartido de archivos: azurefiles



ejecute az upgrade.

Al desencadenar operaciones de copia de seguridad o restauración, el servicio de copia
de seguridad crea un trabajo para realizar un seguimiento. Para supervisar los trabajos
completados o en ejecución, use el cmdlet az backup job list. Con la CLI, también puede
suspender un trabajo que se esté ejecutando actualmente o esperar hasta que se
complete un trabajo.
En el ejemplo siguiente se muestra el estado de los trabajos de copia de seguridad para

el almacén de Recovery Services azurefilesvault:
Azure CLI
az backup job list --resource-group azurefiles --vault-name azurefilesvault
Resultados
[
{
"eTag": null,
vaults/azurefilesvault/backupJobs/d477dfb6-b292-4f24-bb43-6b14e9d06ab5",
"location": null,
"name": "d477dfb6-b292-4f24-bb43-6b14e9d06ab5",
"properties": {
"actionsInfo": null,
"activityId": "3cef43ed-0af4-43e2-b9cb-1322c496ccb4",
"duration": "0:00:29.718011",
"endTime": "2020-01-13T08:05:29.180606+00:00",
"extendedInfo": null,
"operation": "Backup",
"startTime": "2020-01-13T08:04:59.462595+00:00",
"status": "Completed",
"storageAccountVersion": "MicrosoftStorage"
},
"tags": null,
},
{
"eTag": null,
vaults/azurefilesvault/backupJobs/1b9399bf-c23c-4caa-933a-5fc2bf884519",
"location": null,
"name": "1b9399bf-c23c-4caa-933a-5fc2bf884519",
"properties": {
"actionsInfo": null,
"activityId": "2663449c-94f1-4735-aaf9-5bb991e7e00c",
"duration": "0:00:28.145216",
"endTime": "2020-01-13T08:05:27.519826+00:00",
"entityFriendlyName": "azurefilesresource",
"extendedInfo": null,
"operation": "Backup",
"startTime": "2020-01-13T08:04:59.374610+00:00",
"storageAccountVersion": "MicrosoftStorage"
},
"tags": null,
}
]
Creación de directiva
Puede crear una directiva de copia de seguridad mediante la ejecución del comando az
backup policy create con los parámetros siguientes:
--backup-management-type – Azure Storage

--workload-type - AzureFileShare
--name: nombre de la directiva
--policy: archivo JSON con la información adecuada para la programación y la
retención
--resource-group: grupo de recursos del almacén
--vault-name: nombre del almacén
Ejemplo
Azure CLI
az backup policy create --resource-group azurefiles --vault-name

azurefilesvault --name schedule20 --backup-management-type AzureStorage --
policy samplepolicy.json --workload-type AzureFileShare
JSON de ejemplo (samplepolicy.json)
JSON
{
"eTag": null,
vaults/azurefilesvault/backupPolicies/schedule20",
"location": null,
"name": "schedule20",
"properties": {
"protectedItemsCount": 0,
"retentionPolicy": {
"dailySchedule": {
"retentionDuration": {
"count": 30,
"durationType": "Days"
},
"retentionTimes": [
"2020-01-05T08:00:00+00:00"
]
},
"monthlySchedule": null,
"retentionPolicyType": "LongTermRetentionPolicy",
"weeklySchedule": null,
"yearlySchedule": null
},
"schedulePolicy": {
"schedulePolicyType": "SimpleSchedulePolicy",
"scheduleRunDays": null,
"scheduleRunFrequency": "Daily",
"scheduleRunTimes": [
"2020-01-05T08:00:00+00:00"
],
"scheduleWeeklyFrequency": 0
},
"timeZone": "UTC",
"workLoadType": “AzureFileShare”
},
"tags": null,
"type": "Microsoft.RecoveryServices/vaults/backupPolicies"
}
Ejemplo para crear una directiva de copia de seguridad que configure varias copias de
seguridad al día
Este JSON de ejemplo es para los siguientes requisitos:
Programación: copia de seguridad cada 4 horas a partir de las 8 a. m. (UTC)

durante las 12 horas siguientes.
Retención: diariamente, 5 días; semanal, todos los domingos durante 12 semanas;
mensualmente, el primer domingo de cada mes durante 60 meses; anualmente, el
primer domingo de enero durante 10 años.
JSON
{
"properties":{
"schedulePolicy": {
"schedulePolicyType": "SimpleSchedulePolicy",
"scheduleRunFrequency": "Hourly",
"hourlySchedule": {
"interval": 4,
"scheduleWindowStartTime": "2021-09-29T08:00:00.000Z",
"scheduleWindowDuration": 12
}
},
"timeZone": "UTC",
"retentionPolicy": {
"retentionPolicyType": "LongTermRetentionPolicy",
"dailySchedule": {
"retentionTimes": null,
"count": 5,
"durationType": "Days"
}
},
"weeklySchedule": {
"daysOfTheWeek": [
"Sunday"
],
"count": 12,
"durationType": "Weeks"
}
},
"monthlySchedule": {
"retentionScheduleFormatType": "Weekly",
"retentionScheduleDaily": null,
"retentionScheduleWeekly": {
"daysOfTheWeek": [
"Sunday"
],
"weeksOfTheMonth": [
"First"
]
},
"count": 60,
"durationType": "Months"
}
},
"yearlySchedule": {
"monthsOfYear": [
"January"
],
"daysOfTheWeek": [
"Sunday"
],
"First"
]
},
"count": 10,
"durationType": "Years"
}
}
}
}
}
Una vez que la directiva se crea correctamente, la salida del comando mostrará el JSON
de la directiva que pasó como parámetro al ejecutar el comando.
Puede modificar la sección de programación y retención de la directiva según sea

necesario.
Ejemplo
Si desea conservar la copia de seguridad del primer domingo de cada mes durante dos
meses, actualice la programación mensual como se indica a continuación:
JSON
"monthlySchedule": {
"count": 2,
"durationType": "Months"
},
"daysOfTheWeek": [
"Sunday"
],
"First"
]
},
"retentionTimes": [
"2020-01-05T08:00:00+00:00"
]
}
Puede modificar una directiva de copia de seguridad para cambiar la frecuencia de las
copias de seguridad o la duración de retención mediante az backup item set-policy.
Para cambiar la directiva, defina los siguientes parámetros:
--container-name: nombre de la cuenta de almacenamiento que contiene el

--name: nombre del recurso compartido de archivos para el que desea cambiar la
directiva. Para recuperar el nombre o nombre descriptivo del elemento de copia
de seguridad, use el comando az backup item list.
--policy-name: nombre de la directiva de copia de seguridad que desea establecer
para el recurso compartido de archivos. Puede usar az backup policy list para ver
todas las directivas del almacén.
En el ejemplo siguiente se establece la directiva de copia de seguridad schedule2 para el

recurso compartido de archivos azurefiles presente en la cuenta de almacenamiento
afsaccount.
Azure CLI
az backup item set-policy --policy-name schedule2 --name azurefiles --vault-
name azurefilesvault --resource-group azurefiles --container-name
"StorageContainer;Storage;AzureFiles;afsaccount" --name
"AzureFileShare;azurefiles" --backup-management-type azurestorage --out
table
También puede ejecutar el comando anterior con los nombres descriptivos del
contenedor y el elemento proporcionando los dos parámetros adicionales siguientes:
Azure CLI
az backup item set-policy --policy-name schedule2 --name azurefiles --vault-

name azurefilesvault --resource-group azurefiles --container-name afsaccount
--name azurefiles --backup-management-type azurestorage --out table
Resultados
Name ResourceGroup
------------------------------------ ---------------
fec6f004-0e35-407f-9928-10a163f123e5 azurefiles
servicio de copia de seguridad para la operación de cambio de directiva. Para realizar el

recuperación.

conservarán. La ventaja de dejarlos es que tiene la opción de restaurar el recurso
compartido de archivos más adelante, si así lo desea. Para más información sobre el
costo de dejar los puntos de recuperación, consulte la información sobre precios . Si
opta por eliminar todos los puntos de recuperación, no podrá restaurar el recurso
Para detener la protección del recurso compartido de archivos, defina los parámetros
siguientes:

--item-name: nombre del recurso compartido de archivos para el que desea
detener la protección. Para recuperar el nombre o nombre descriptivo del
elemento de copia de seguridad, use el comando az backup item list.
Detención de la protección y conservación de los puntos

de recuperación
Para detener la protección conservando los datos, use el cmdlet az backup protection
disable.
En el ejemplo siguiente se detiene la protección del recurso compartido de archivos

azurefiles, pero se conservan todos los puntos de recuperación.
Azure CLI
az backup protection disable --vault-name azurefilesvault --resource-group

--item-name “AzureFileShare;azurefiles” --out table
También puede ejecutar el comando anterior con el nombre descriptivo del contenedor
y el elemento proporcionando los dos parámetros adicionales siguientes:
Azure CLI

azurefiles --container-name afsaccount --item-name azurefiles --workload-
type azurefileshare --backup-management-type Azurestorage --out table
Resultados
Name ResourceGroup
------------------------------------ ---------------
fec6f004-0e35-407f-9928-10a163f123e5 azurefiles
servicio de copia de seguridad para la operación de detención de la protección. Para
Detención de la protección sin conservar los puntos de

recuperación
Para detener la protección sin conservar los puntos de recuperación, use el cmdlet az
backup protection disable con la opción delete-backup-data establecida en true.

azurefiles sin conservar puntos de recuperación.
Azure CLI

--item-name “AzureFileShare;azurefiles” --delete-backup-data true --out
table
Azure CLI

type azurefileshare --backup-management-type Azurestorage --delete-backup-
data true --out table
Reanudación de la protección en un recurso

Si ha detenido la protección de un recurso compartido de archivos de Azure pero ha
conservado los puntos de recuperación, puede reanudar la protección más adelante. Si
no conserva los puntos de recuperación, no puede reanudar la protección.
Para reanudar la protección del recurso compartido de archivos, defina los parámetros
siguientes:

--item-name: nombre del recurso compartido de archivos para el que desea
reanudar la protección. Para recuperar el nombre o nombre descriptivo del
elemento de copia de seguridad, use el comando az backup item list.
--policy-name: nombre de la directiva de copia de seguridad para la que desea
reanudar la protección del recurso compartido de archivos.
En el ejemplo siguiente se usa el cmdlet az backup protection resume para reanudar la

protección del recurso compartido de archivos azurefiles con la directiva de copia de
seguridad schedule1.
Azure CLI
az backup protection resume --vault-name azurefilesvault --resource-group

azurefiles --container-name "StorageContainer;Storage;AzureFiles;afsaccount”
--item-name “AzureFileShare;azurefiles” --policy-name schedule2 --out table
Azure CLI
az backup protection resume --vault-name azurefilesvault --resource-group

type azurefileshare --backup-management-type Azurestorage --policy-name
schedule2 --out table
Resultados
Name ResourceGroup
------------------------------------ ---------------
75115ab0-43b0-4065-8698-55022a234b7f azurefiles
servicio de copia de seguridad para la operación de reanudación de la protección. Para
Anulación del registro de una cuenta de
almacenamiento
Si desea proteger los recursos compartidos de archivos en una cuenta de
almacenamiento determinada mediante un almacén de Recovery Services diferente,
primero debe detener la protección de todos los recursos compartidos de archivos en
esa cuenta de almacenamiento. A continuación, anule el registro de la cuenta del
almacén de Recovery Services que se usa actualmente para la protección.
Debe proporcionar un nombre de contenedor para anular el registro de la cuenta de

almacenamiento. Para recuperar el nombre o nombre descriptivo del contenedor, use
el comando az backup container list.
En el ejemplo siguiente se anula el registro de la cuenta de almacenamiento afsaccount

de azurefilesvault con el cmdlet az backup container unregister.
Azure CLI
az backup container unregister --vault-name azurefilesvault --resource-group

--out table
También puede ejecutar el cmdlet anterior con el nombre descriptivo del contenedor
proporcionando el parámetro adicional siguiente:
Azure CLI
az backup container unregister --vault-name azurefilesvault --resource-group

azurefiles --container-name afsaccount --backup-management-type azurestorage
--out table
Pasos siguientes
Para más información, vea Solución de problemas de las copias de seguridad de
Azure con PowerShell
Artículo • 01/06/2023
En este artículo se describe el uso de Azure PowerShell para administrar y supervisar los
recursos compartidos de archivos de Azure que tienen una copia de seguridad del
servicio Azure Backup.
２ Advertencia
Asegúrese de que la versión de PowerShell se actualice a la versión mínima de

"Az.RecoveryServices 2.6.0" para las copias de seguridad de AFS. Para obtener más
información, consulte la sección que describe el requisito de este cambio.
Modificación de la directiva de protección

Para cambiar la directiva empleada para la realizar la copia de seguridad del recurso
compartido de archivos de Azure, use Enable-AzRecoveryServicesBackupProtection.
Especifique el elemento de copia de seguridad pertinente y la nueva directiva de copia
de seguridad.
En el siguiente ejemplo se cambia la directiva de protección de testAzureFS de dailyafs

a monthlyafs.
PowerShell
$monthlyafsPol = Get-AzRecoveryServicesBackupProtectionPolicy -Name

"monthlyafs"
$afsContainer = Get-AzRecoveryServicesBackupContainer -FriendlyName
"testStorageAcct" -ContainerType AzureStorage
$afsBkpItem = Get-AzRecoveryServicesBackupItem -Container $afsContainer -
WorkloadType AzureFiles -Name "testAzureFS"
Enable-AzRecoveryServicesBackupProtection -Item $afsBkpItem -Policy
$monthlyafsPol
Seguimiento de trabajos de copia de seguridad

y restauración
Las operaciones de copia de seguridad y restauración a petición devuelven un trabajo
con un identificador, como se indica al ejecutar una copia de seguridad a petición. Use
el cmdlet Get-AzRecoveryServicesBackupJobDetails para hacer un seguimiento del
progreso del trabajo y de los detalles.
PowerShell
$job = Get-AzRecoveryServicesBackupJob -JobId 00000000-6c46-496e-980a-

3740ccb2ad75 -VaultId $vaultID
$job | fl
IsCancellable : False
IsRetriable : False
ErrorDetails :
{Microsoft.Azure.Commands.RecoveryServices.Backup.Cmdlets.Models.AzureFileSh
areJobErrorInfo}
ActivityId : 00000000-5b71-4d73-9465-8a4a91f13a36
JobId : 00000000-6c46-496e-980a-3740ccb2ad75
Operation : Restore
Status : Failed
WorkloadName : testAFS
StartTime : 12/10/2018 9:56:38 AM
EndTime : 12/10/2018 11:03:03 AM
Duration : 01:06:24.4660027
BackupManagementType : AzureStorage
$job.ErrorDetails
ErrorCode ErrorMessage
Recommendations
--------- ------------ -----------
----
1073871825 Microsoft Azure Backup encountered an internal error. Wait for a
few minutes and then try the operation again. If the issue persists, please
contact Microsoft support.

recuperación.
conservan. Sin embargo, la ventaja de dejarlos es que puede restaurar el recurso
compartido de archivos más adelante, si así lo desea. Para más información sobre el
costo de dejar los puntos de recuperación, consulte la información sobre precios . Si
opta por eliminar todos los puntos de recuperación, no podrá restaurar el recurso
Detención de la protección y conservación de

los puntos de recuperación
Para detener la protección y retener los datos a la vez, puede usar el cmdlet Disable-
AzRecoveryServicesBackupProtection.

afsfileshare, pero se conservan todos los puntos de recuperación:
PowerShell
$vaultID = Get-AzRecoveryServicesVault -ResourceGroupName "afstesting" -Name

"afstest" | select -ExpandProperty ID
$bkpItem = Get-AzRecoveryServicesBackupItem -BackupManagementType
AzureStorage -WorkloadType AzureFiles -Name "afsfileshare" -VaultId $vaultID
Disable-AzRecoveryServicesBackupProtection -Item $bkpItem -VaultId $vaultID
Resultados

EndTime JobID
------------ --------- ------ ---------
------- -----
afsfileshare DisableBackup Completed 1/26/2020 2:43:59 PM
1/26/2020 2:44:21 PM 98d9f8a1-54f2-4d85-8433-c32eafbd793f
El atributo Job ID de la salida se corresponde con el id. del trabajo creado por el servicio
de copia de seguridad para la operación de "detención de la protección". Para
supervisar el estado de un trabajo, use el cmdlet Get-AzRecoveryServicesBackupJob.
Detención de la protección sin conservar los

puntos de recuperación
Para detener la protección sin conservar los puntos de recuperación, use el cmdlet
Disable-AzRecoveryServicesBackupProtection y agregue el parámetro -
RemoveRecoveryPoints.

afsfileshare sin conservar puntos de recuperación:
PowerShell
$vaultID = Get-AzRecoveryServicesVault -ResourceGroupName "afstesting" -Name

"afstest" | select -ExpandProperty ID
$bkpItem = Get-AzRecoveryServicesBackupItem -BackupManagementType
AzureStorage -WorkloadType AzureFiles -Name "afsfileshare" -VaultId $vaultID
Disable-AzRecoveryServicesBackupProtection -Item $bkpItem -VaultId $vaultID
-RemoveRecoveryPoints
Resultados

EndTime JobID
------------ --------- ------ ---------
------- -----
afsfileshare DeleteBackupData Completed 1/26/2020 2:50:57 PM
1/26/2020 2:51:39 PM b1a61c0b-548a-4687-9d15-9db1cc5bcc85
Pasos siguientes
Obtenga información acerca de la administración de copias de seguridad de recursos
compartidos de archivos de Azure en Azure Portal.
Azure con API REST
Artículo • 01/06/2023
En este artículo se explica cómo realizar tareas para administrar y supervisar los recursos
compartidos de archivos de Azure de los que se ha realizado una copia de seguridad
mediante Azure Backup.
El servicio Azure Backup desencadena trabajos que se ejecutan en segundo plano. Esto
incluye escenarios como desencadenar copias de seguridad, operaciones de
restauración y deshabilitar la copia de seguridad. Estos trabajos se pueden seguir
mediante sus identificadores.
Captura de información sobre el trabajo de las

operaciones
Una operación como desencadenar la copia de seguridad siempre devolverá un valor de
jobID en la respuesta.
Por ejemplo, la respuesta final de una operación para desencadenar una copia de
seguridad en API REST es como sigue:
JSON
{
"id": "c3a52d1d-0853-4211-8141-477c65740264",
"name": "c3a52d1d-0853-4211-8141-477c65740264",
"startTime": "2020-02-03T18:10:48.296012Z",
"endTime": "2020-02-03T18:10:48.296012Z",
"properties": {
"jobId": "e2ca2cf4-2eb9-4d4b-b16a-8e592d2a658b"
}
}
El trabajo de copia de seguridad del recurso compartido de archivos se identifica

mediante el campo jobId y se puede realizar su seguimiento como se menciona aquí
mediante una solicitud GET.
Seguimiento del trabajo

HTTP
GET
ackupJobs/{jobName}?api-version=2019-05-13
{JobName} es el valor de "jobId" mencionado anteriormente. La respuesta es siempre

"200 (Correcto)" y el campo status indica el estado del trabajo. Cuando el estado sea
"Completed" o "CompletedWithWarnings", la sección extendedInfo ofrecerá más
detalles sobre el trabajo.
HTTP
vaults/azurefilesvault/backupJobs/e2ca2cf4-2eb9-4d4b-b16a-8e592d2a658b?api-
version=2019-05-13'
Response
200 OK JobResource Aceptar
Ejemplo de respuesta
Una vez que se envía el identificador URI de GET, se devuelve una respuesta 200.
HTTP
HTTP/1.1" 200
'Expires': '-1'
'Server': 'Microsoft-IIS/10.0, Microsoft-IIS/10.0'
'x-ms-request-id': 'dba43f00-5cdb-43b1-a9ec-23e419db67c5'
'x-ms-client-request-id': 'a644712a-4895-11ea-ba57-0a580af42708, a644712a-
4895-11ea-ba57-0a580af42708'
'x-ms-correlation-request-id': 'dba43f00-5cdb-43b1-a9ec-23e419db67c5'
'x-ms-routing-request-id': 'WESTEUROPE:20200206T040341Z:dba43f00-5cdb-43b1-
a9ec-23e419db67c5'
'Date': 'Thu, 06 Feb 2020 04:03:40 GMT'
{
vaults/azurefilesvault/backupJobs/e2ca2cf4-2eb9-4d4b-b16a-8e592d2a658b",
"name": "e2ca2cf4-2eb9-4d4b-b16a-8e592d2a658b",
"type": "Microsoft.RecoveryServices/vaults/backupJobs",
"properties": {
"duration": "00:00:43.1809140",
"storageAccountName": "testvault2",
"storageAccountVersion": "Storage",
"extendedInfo": {
"tasksList": [],
"propertyBag": {
"File Share Name": "testshare",
"Storage Account Name": "testvault2",
"Policy Name": "schedule1"
}
},
"entityFriendlyName": "testshare",
"operation": "ConfigureBackup",
"startTime": "2020-02-03T18:10:48.296012Z",
"endTime": "2020-02-03T18:11:31.476926Z",
"activityId": "3677cec0-942d-4eac-921f-8f3c873140d7"
}
}
Para cambiar la directiva con la que se protege el recurso compartido de archivos,
puede usar el mismo formato que para habilitar la protección. Basta con que
proporcione el identificador de la nueva directiva en la directiva de solicitud y envíe la
solicitud.
Por ejemplo: Para cambiar la directiva de protección de testshare de schedule1 a

schedule2, proporcione el identificador schedule2 en el cuerpo de la solicitud.
JSON
{
"properties": {
"sourceResourceId": "/subscriptions/ef4ab5a7-c2c0-4304-af80-
counts/testvault2",
"policyId": "/Subscriptions/ef4ab5a7-c2c0-4304-af80-
vaults/azurefilesvault/backupPolicies/schedule2"
}
}
Detener la protección, pero conservar los datos

existentes
Puede quitar la protección de un recurso compartido de archivos protegido, pero
conservar los datos de los que ya se ha realizado una copia de seguridad. Para ello,
quite la directiva del cuerpo de la solicitud que usó parahabilitar la copia de seguridad y
enviar la solicitud. Una vez que se quita la asociación con la directiva, ya no se
desencadenan las copias de seguridad ni se crea ningún punto de recuperación nuevo.
JSON
{
"properties": {
"sourceResourceId": "/subscriptions/ef4ab5a7-c2c0-4304-af80-
counts/testvault2",
"policyId": "" ,
"protectionState":"ProtectionStopped"
}
}
Respuesta de muestra
Detener la protección de un recurso compartido de archivos es una operación
asincrónica. La operación crea otra de la que se tiene que hacer el seguimiento.
cuando se completa dicha operación.
Encabezado de respuesta cuando la operación se acepta correctamente:
HTTP
HTTP/1.1" 202
'Expires': '-1'
'Location': 'https://management.azure.com/Subscriptions/ef4ab5a7-c2c0-4304-
af80-
perationResults/b300922a-ad9c-4181-b4cd-d42ea780ad77?api-version=2019-05-13'
'Retry-After': '60'
msrest.http_logger : 'Azure-AsyncOperation':
'https://management.azure.com/Subscriptions/ef4ab5a7-c2c0-4304-af80-
perationsStatus/b300922a-ad9c-4181-b4cd-d42ea780ad77?api-version=2019-05-13'
'x-ms-request-id': '3895e8a1-e4b9-4da5-bec7-2cf0266405f8'
'x-ms-client-request-id': 'd331c15e-48ab-11ea-84c0-0a580af46a50, d331c15e-
48ab-11ea-84c0-0a580af46a50'
'x-ms-correlation-request-id': '3895e8a1-e4b9-4da5-bec7-2cf0266405f8'
'x-ms-routing-request-id': 'WESTEUROPE:20200206T064224Z:3895e8a1-e4b9-4da5-
bec7-2cf0266405f8'
'Date': 'Thu, 06 Feb 2020 06:42:24 GMT'
'Content-Length': '0'

ubicación o el encabezado Azure-AsyncOperation y un comando GET:
HTTP
vaults/azurefilesvault/backupoperations/b300922a-ad9c-4181-b4cd-
d42ea780ad77?api-version=2016-12-01
Response body
JSON
{
"id": "b300922a-ad9c-4181-b4cd-d42ea780ad77",
"name": "b300922a-ad9c-4181-b4cd-d42ea780ad77",
"startTime": "2020-02-06T06:42:24.4001299Z",
"endTime": "2020-02-06T06:42:24.4001299Z",
"properties": {
"jobId": "7816fca8-d5be-4c41-b911-1bbd922e5826"
}
}
Detener la protección y eliminar los datos

Para quitar la protección de un recurso compartido de archivos y eliminar también los
datos de la copia de seguridad, realice una operación de eliminación como se detalla
aquí.
HTTP
DELETE
s/{protectedItemName}?api-version=2019-05-13
Los parámetros {containerName} y {protectedItemName} son los que se establecen aquí.
En el ejemplo siguiente se desencadena una operación para detener la protección del

recurso compartido de archivos testshare protegido con azurefilesvault.
HTTP
DELETE https://management.azure.com/Subscriptions/ef4ab5a7-c2c0-4304-af80-
iner;Storage;AzureFiles;testvault2/protectedItems/azurefileshare;testshare?
api-version=2016-12-01
Respuestas
La eliminación de la protección es una operación asincrónica. La operación crea otra
operación de la que se debe hacer un seguimiento por separado. Devuelve las dos
respuestas: 202 (Aceptado) cuando se crea otra operación y 204 (Sin contenido) cuando
se completa dicha operación.
Pasos siguientes
Aprenda a solucionar problemas al configurar la copia de seguridad para recursos
Artículo • 13/09/2023
Si tiene aplicaciones y procesos empresariales críticos que dependen de recursos de

Azure, querrá supervisar esos recursos para su disponibilidad, rendimiento y
funcionamiento. En este artículo se describen los datos de supervisión que genera Azure
Files y cómo puede usar las características de Azure Monitor para analizar las alertas
sobre estos datos.
Se aplica a
Información general de supervisión

La página Información general de Azure Portal para cada recurso de Azure Files incluye
una breve vista del uso de los recursos, como las solicitudes y la facturación por hora.
Esta información es útil, pero solo hay disponible una pequeña cantidad de datos de
supervisión. Algunos de estos datos se recopilan automáticamente y están disponibles
para su análisis en cuanto se crea el recurso. Puede habilitar tipos adicionales de
recopilación de datos con cierta configuración adicional.
¿Qué es Azure Monitor?

Azure Files crea los datos de supervisión mediante Azure Monitor, que es un servicio de
supervisión de pila completo en Azure. Azure Monitor proporciona un conjunto
completo de características para supervisar los recursos de Azure y los recursos en otras
nubes y en el entorno local.
Comience con el artículo Supervisión de recursos de Azure con Azure Monitor, que
describe lo siguiente:
¿Qué es Azure Monitor?

Costos asociados con la supervisión
Datos de supervisión recopilados en Azure
Configuración de la recolección de datos
Herramientas estándar en Azure para analizar datos de supervisión y alertar sobre
ellos
Las secciones siguientes complementan este artículo mediante la descripción de los

datos específicos que se recopilan de Azure Files. En los ejemplos se muestra cómo
configurar la recopilación de datos y analizar estos datos con herramientas de Azure.
Supervisión de datos
Azure Files recopila los mismos tipos de datos de supervisión que otros recursos de
Azure, que se describen en Supervisión de datos de recursos de Azure.
Vea Referencia de datos de supervisión de Azure Files para obtener información

detallada sobre las métricas y las métricas de registros que crea Azure Files.
Las métricas y registros de Azure Monitor solo admiten cuentas de almacenamiento de

Azure Resource Manager. Azure Monitor no admite cuentas de almacenamiento
clásicas. Si desea usar las métricas o registros en una cuenta de almacenamiento clásica,
es preciso migrar a una cuenta de almacenamiento de Azure Resource Manager.
Consulte Migración a Azure Resource Manager.
Recopilación y enrutamiento
Las métricas de la plataforma y el registro de actividad se recopilan automáticamente,
pero se pueden enrutar a otras ubicaciones mediante una configuración de diagnóstico.
Para recopilar registros de recursos, debe crear una configuración de diagnóstico.

Cuando cree la configuración, elija archivo como tipo de almacenamiento para habilitar
los registros. A continuación, especifique una de las siguientes categorías de
operaciones de las que quiera recopilar registros.
Category Descripción
StorageRead Operaciones de lectura en objetos.
StorageWrite Operaciones de escritura en objetos.
StorageDelete Operaciones de eliminación en objetos.
El grupo de categorías de registro de recursos de auditoría permite recopilar la línea

base de los registros de recursos que Microsoft considera necesario para auditar el
recurso. Lo que se recopila es dinámico y Microsoft puede cambiarlo con el tiempo a
medida que haya nuevas categorías de registro de recursos disponibles. Si elige el
grupo de categorías auditoría, no puede especificar ninguna otra categoría de recursos,
ya que el sistema decidirá qué registros recopilar. Para más información, consulte
Configuración de diagnóstico en Azure Monitor: registros de recursos.
Para obtener la lista de operaciones de SMB y de REST que se registran, vea

Operaciones registradas de almacenamiento y mensajes de estado y Referencia de
datos de supervisión de Azure Files.
Consulte Creación de una configuración de diagnóstico para recopilar registros de

plataforma y métricas en Azure para ver el proceso detallado de creación de una
configuración de diagnóstico mediante Azure Portal, la CLI o PowerShell. También puede
encontrar vínculos a información sobre cómo crear una configuración de diagnóstico
mediante una plantilla de Azure Resource Manager o una definición de Azure Policy.
Limitaciones de destino
Para conocer las limitaciones de destino generales, consulte Limitaciones de destino. Las
siguientes limitaciones solo se aplican a la supervisión de cuentas de Azure Storage.
No puede enviar registros a la misma cuenta de almacenamiento que supervisa

con esta configuración.
Esto provocaría registros recursivos en los que una entrada de registro describe la
escritura de otra entrada de registro. Debe crear una cuenta o usar otra existente
para almacenar información de registro.
No se puede establecer una directiva de retención.
Si archiva los registros en una cuenta de almacenamiento, puede administrar la

directiva de retención de un contenedor de registros mediante la definición de una
directiva de administración del ciclo de vida. Para descubrir cómo hacerlo, consulte
Optimización de los costos mediante la automatización de los niveles de acceso de
Azure Blob Storage.
Si envía registros a Log Analytics, puede administrar el período de retención de

datos de Log Analytics en el nivel de área de trabajo o incluso especificar
diferentes configuraciones de retención por tipo de datos. Para saber cómo,
consulte Cambio del período de retención de datos.
Pasos siguientes
Análisis de métricas de Azure Files mediante Azure Monitor
Crear alertas de supervisión para Azure Files
Referencia de datos de supervisión de Azure Files
Supervisión de recursos de Azure con Azure Monitor
Migración de las métricas de Azure Storage.
Análisis de métricas de Azure Files
mediante Azure Monitor
Artículo • 13/09/2023
Comprender cómo supervisar el rendimiento del recurso compartido de archivos es

fundamental para garantizar que la aplicación se ejecute de la forma más eficaz posible.
En este artículo se muestra cómo usar Azure Monitor para analizar métricas de
Azure Files, como la disponibilidad, la latencia y el uso.
Se aplica a
Métricas compatibles
Para obtener una lista de todas las métricas compatibles con Azure Monitor, lo que
incluye Azure Files, vea Métricas compatibles con Azure Monitor.
Azure Portal
Puede analizar las métricas de Azure Storage con métricas de otros servicios de
Azure con el Explorador de métricas. Para abrir el Explorador de métricas, elija
Métricas en el menú Azure Monitor. Para más información sobre esta herramienta,
consulte Introducción al Explorador de métricas de Azure.
Para ver las métricas que admiten dimensiones, puede filtrar las métricas con el
valor de dimensión deseado. Para obtener una lista completa de las dimensiones
que admite Azure Storage, consulte Dimensiones de métricas. Las métricas de
Azure Files se encuentran en estos espacios de nombres:
Microsoft.Storage/storageAccounts
Microsoft.Storage/storageAccounts/fileServices
Supervisión del rendimiento de la carga de
trabajo
Puede usar Azure Monitor para analizar las cargas de trabajo que usan Azure Files. Siga
estos pasos.
1. Vaya a la cuenta de almacenamiento en Azure Portal .

2. En el menú de navegación izquierdo, seleccione Almacenamiento de
datos>Recursos compartidos de archivos. Seleccione el recurso compartido de
archivos que desea supervisar.
3. En el panel de navegación izquierdo, seleccione Supervisión>Métricas.
4. Al usar Azure Monitor para Azure Files, es importante seleccionar siempre el
espacio de nombres de la métrica Archivos. Seleccione Agregar métrica.
5. En Espacio de nombres de métrica, seleccione Archivo.
Supervisión de la disponibilidad
En Azure Monitor, la métrica Disponibilidad puede ser útil cuando algo es visiblemente
incorrecto desde la perspectiva de un usuario o una aplicación, o al solucionar
problemas de alertas.
Al usar esta métrica con Azure Files, es importante ver siempre la agregación como
Promedio en lugar de Max o Min. El uso de Promedio le ayudará a comprender qué
porcentaje de las solicitudes están experimentando errores y si están dentro del
Acuerdo de Nivel de Servicio para Azure Files .

Supervisión de la latencia
Las dos métricas de latencia más importantes son Latencia de E2E correcta y Latencia
del servidor correcta. Estas son métricas ideales para seleccionar al iniciar cualquier
investigación de rendimiento. El Promedio es la agregación recomendada. Como se
mencionó anteriormente, Max y Min a veces pueden ser engañosas.
En los gráficos siguientes, la línea azul indica cuánto tiempo se dedica a la latencia total
(latencia de E2E correcta) y la línea rosa indica el tiempo invertido solo en el servicio de
Azure Files (latencia del servidor correcto).
Este gráfico es un ejemplo de una máquina cliente que ha montado un recurso

compartido de archivos de Azure desde un entorno local. Esto probablemente
representará un usuario típico que se conecta desde una oficina, una casa u otra
ubicación remota. Verá que la distancia física entre el cliente y la región de Azure está
estrechamente correlacionada con la latencia del lado cliente correspondiente, que
representa la diferencia entre la latencia de E2E y del servidor.
En comparación, en el gráfico siguiente se muestra una situación en la que tanto el

cliente como el recurso compartido de archivos de Azure se encuentran dentro de la
misma región. Tenga en cuenta que la latencia del lado cliente es de solo 0,17 ms en
comparación con 43,9 ms en el primer gráfico. Esto ilustra por qué minimizar la latencia
del lado cliente es imprescindible para lograr un rendimiento óptimo.
Otro indicador de latencia que se debe buscar y podría sugerir un problema es una
mayor frecuencia o picos anómalos en la Latencia del servidor correcta. Esto suele
deberse a la limitación debido a superar los límites de escala de Azure Files para los
recursos compartidos de archivos estándar o a un Recurso compartido de Azure Files
premium aprovisionado insuficientemente.
Para obtener más información, consulte Solución de problemas de alta latencia, bajo
rendimiento o IOPS bajas.
Supervisión del uso

Las métricas de uso que miden la cantidad de datos que se transmiten (rendimiento) o
las operaciones que se administran (IOPS) se usan normalmente para determinar la
cantidad de trabajo que realiza la aplicación o la carga de trabajo. Las métricas de
transacción pueden determinar el número de operaciones o solicitudes en el servicio de
Azure Files en la granularidad en diversos momentos.
Si usa las métricas Salida o Entrada para determinar el volumen de datos entrantes o
salientes, use la agregación Suma para determinar la cantidad total de datos que se
transmiten hacia el recurso compartido de archivos y desde este durante una
granularidad de un minuto a un día. Otras agregaciones como Promedio, Max y Min
solo muestran el valor del tamaño de E/S individual. Este es el motivo por el que la
mayoría de los clientes suelen ver 1 MiB al usar la agregación Max. Aunque puede ser
útil comprender el tamaño de E/S más grande, menor o incluso el promedio, no es
posible mostrar la distribución del tamaño de E/S generado por el patrón de uso de la
carga de trabajo.
También puede seleccionar Aplicar división en tipos de respuesta (correcto, errores) u
operaciones de API (lectura, escritura, creación, cierre) para mostrar detalles adicionales,
como se muestra en el gráfico siguiente.
Para determinar el promedio de E/S por segundo (IOPS) de la carga de trabajo, primero
determine el número total de transacciones durante un minuto y, a continuación, divida
ese número en 60 segundos. Por ejemplo, 120 000 transacciones en 1 minuto /
60 segundos = 2000 IOPS en promedio.
Para determinar el rendimiento promedio de la carga de trabajo, tome la cantidad total

de datos transmitidos mediante la combinación de las métricas de Entrada y Salida
(rendimiento total) y divida esa cantidad en 60 segundos. Por ejemplo, un rendimiento
total de 1 GiB durante 1 minuto /60 segundos = 17 MiB de rendimiento promedio.
Supervisión del uso por número máximo de IOPS y ancho

de banda (solo premium)
Dado que los recursos compartidos de archivos de Azure premium se facturan en un
modelo aprovisionado en el que cada GiB de capacidad de almacenamiento que
aprovisiona le permite obtener más IOPS y rendimiento, a menudo resulta útil
determinar el número máximo de IOPS y ancho de banda. Mientras que el rendimiento
mide la cantidad real de datos transmitidos correctamente, el ancho de banda hace
referencia a la velocidad máxima de transferencia de datos.
Con los recursos compartidos de archivos de Azure premium, puede usar las métricas
Transacciones por número máximo de IOPS y Ancho de banda por número máximo
de MiB/s para mostrar lo que la carga de trabajo está logrando en horas pico. El uso de
estas métricas para analizar la carga de trabajo le ayudará a comprender la verdadera
funcionalidad a gran escala, así como a establecer una base de referencia para
comprender el impacto de más rendimiento e IOPS para que pueda aprovisionar de
forma óptima el recurso compartido de archivos de Azure premium.
En el gráfico siguiente se muestra una carga de trabajo que generó 2,63 millones de
transacciones durante 1 hora. Cuando 2,63 millones de transacciones se divide entre
3600 segundos, obtenemos un promedio de 730 IOPS.
Ahora, cuando comparamos las IOPS promedio con las Transacciones por número
máximo de IOPS, vemos que en la carga máxima logramos 1840 IOPS, que es una mejor
representación de la capacidad de la carga de trabajo a gran escala.
Seleccione Agregar métrica para combinar las Métricas de entrada y Salida en un solo
gráfico. Esto muestra que 76,2 GiB (78 028 MiB) se transfirieron a lo largo de una hora,
lo que nos proporciona un rendimiento promedio de 21,67 MiB durante esa misma
hora.

Comparado con el Ancho de banda por número máximo de MiB/s, logramos

123 MiB/s en el pico.
Análisis de registros
Puede acceder a los registros de los recursos como blob en una cuenta de
almacenamiento, como datos de eventos o a través de consultas de Log Analytics. Para
obtener información sobre cómo buscar esos registros, consulte Registros de recursos
de Azure.
Todos los registros de recursos de Azure Monitor tienen los mismos campos seguidos
de campos específicos del servicio. El esquema común se describe en Esquema de
registros de recursos de Azure Monitor. El esquema para los registros de recursos de
Azure Files se encuentra en Referencia de datos de supervisión de Azure Files.
Para obtener la lista de operaciones de SMB y de REST que se registran, consulte
Operaciones y mensajes de estado registrados por Storage.
Las entradas del registro se crean solo si se presentan solicitudes al punto de conexión
de servicio. Por ejemplo, si una cuenta de almacenamiento tiene actividad en el punto
de conexión de su archivo, pero no en los puntos de conexión de su tabla o cola, solo se
crean los registros correspondientes al servicio del archivo de Azure. Los registros de
Azure Storage contienen información detallada sobre las solicitudes correctas y erróneas
realizadas a un servicio de almacenamiento. Esta información se puede utilizar para
supervisar solicitudes concretas y para diagnosticar problemas con un servicio de
almacenamiento. Las solicitudes se registran en función de la mejor opción.
El Registro de actividad es un tipo de registro de plataforma de Azure que proporciona

conclusiones sobre los eventos del nivel de suscripción. Puede verlo de forma
independiente o enrutarlo a registros de Azure Monitor, donde puede realizar consultas
mucho más complejas mediante Log Analytics.
Registro de solicitudes autenticadas

Se registran los siguientes tipos de solicitudes autenticadas:
Solicitudes correctas
Solicitudes erróneas, incluidos errores de tiempo de espera, de limitación, de red,
de autorización y de otro tipo
Solicitudes que usan Kerberos, NTLM o una firma de acceso compartido (SAS), que
incluyen tanto las solicitudes correctas como con error
Solicitudes de datos de análisis (datos de registro clásicos en el contenedor $logs y
datos de métricas clásicos en las tablas $metric)
Las solicitudes que realiza el propio servicio Azure Files, como la creación o eliminación
de registros, no se registran. Para obtener una lista completa de solicitudes de SMB y de
REST que se registran, vea Operaciones registradas de almacenamiento y mensajes de
estado y Referencia de datos de supervisión de Azure Files.
Ejemplos de consultas de Kusto

Si envía registros a Log Analytics, puede acceder a esos registros mediante consultas de
registro de Azure Monitor. Para obtener más información, vea Tutorial de Log Analytics.
Estas son algunas consultas que puede escribir en la barra Búsqueda de registros para
ayudarle a supervisar Azure Files. Estas consultas funcionan con el nuevo lenguaje.
） Importante
Al seleccionar Registros en el menú de grupo de recursos de la cuenta de

almacenamiento, Log Analytics se abre con el ámbito de la consulta establecido en
el grupo de recursos actual. Esto significa que las consultas de registro solo
incluirán datos de ese grupo de recursos. Si quiere ejecutar una consulta que
incluya datos de otros recursos o de otros servicios de Azure, seleccione Registros
en el menú Azure Monitor. Consulte Ámbito e intervalo de tiempo de una
consulta de registro en Log Analytics de Azure Monitor para obtener más
información.
Utilice estas consultas para ayudar a supervisar los recursos compartidos de Azure:
Ver errores de SMB en la última semana
Kusto
StorageFileLogs
| where Protocol == "SMB" and TimeGenerated >= ago(7d) and StatusCode
contains "-"
| sort by StatusCode
Crear un gráfico circular de las operaciones de SMB en la última semana
Kusto
StorageFileLogs
| where Protocol == "SMB" and TimeGenerated >= ago(7d)
| summarize count() by OperationName
| sort by count_ desc
| render piechart
Ver los errores de REST en la última semana
Kusto
StorageFileLogs
| where Protocol == "HTTPS" and TimeGenerated >= ago(7d) and StatusText
!contains "Success"
| sort by StatusText asc
Crear un gráfico circular de las operaciones de REST en la última semana
Kusto
StorageFileLogs
| where Protocol == "HTTPS" and TimeGenerated >= ago(7d)
| summarize count() by OperationName
| sort by count_ desc
| render piechart
Para ver la lista de nombres y descripciones de las columnas de Azure Files, vea
StorageFileLogs.
Para obtener más información sobre cómo escribir consultas, vea Tutorial de Log
Analytics.
Pasos siguientes
Creación de alertas de supervisión para Azure Files
Descripción del rendimiento de Azure Files
Creación de alertas de supervisión para
Azure Files
Artículo • 13/09/2023
Las alertas de Azure Monitor le informan de forma proactiva cuando se detectan

condiciones importantes en los datos que se supervisan. Permiten identificar y
solucionar las incidencias en el sistema antes de que los clientes puedan verlos. Puede
establecer alertas en métricas, registros y el registro de actividad.
Para obtener más información sobre cómo crear una alerta, consulte Creación o edición
de una regla de alerta.
Se aplica a
Métricas que se usarán para las alertas

En la tabla siguiente se muestran algunos escenarios de ejemplo que se van a supervisar
y la métrica adecuada que se va a usar para la alerta:
 Sugerencia
Si crea una alerta y esta produce demasiados resultados irrelevantes, ajuste el valor
del umbral y la lógica de alerta.
Escenario Métrica que se va a usar para la alerta
El recurso compartido está limitado. Métrica: Transactions

Nombre de la dimensión: Tipo de respuesta
Nombre de la dimensión: FileShare (solo recurso
compartido de archivos premium)
El tamaño del recurso compartido de archivos Métrica: Capacidad de File

es del 80 % de la capacidad. Nombre de la dimensión: FileShare (solo recurso
Escenario compartido
Métrica quede
searchivos premium)
va a usar para la alerta
La salida del recurso compartido de archivos Métrica: Salida

ha superado los 500 GiB en un día. Nombre de la dimensión: FileShare (solo recurso
compartido de archivos premium)
Creación de una alerta si un recurso

compartido de archivos se limita
Para crear una alerta que le notificará si un recurso compartido de archivos está
limitado, siga estos pasos.
1. Abra el cuadro de diálogo Crear una regla de alerta . Para obtener más
información, consulte Creación o edición de una regla de alerta.
2. En la pestaña Condición , seleccione la métrica Transacciones .
3. En la lista desplegable Nombre de la dimensión, seleccione Tipo de respuesta.
4. En la lista desplegable Valores de la dimensión, seleccione los tipos de respuesta

adecuados para el recurso compartido de archivos.
Para recursos compartidos de archivos estándar, seleccione los siguientes tipos de

respuesta:
SuccessWithShareIopsThrottling
SuccessWithThrottling
ClientShareIopsThrottlingError
Para recursos compartidos de archivos prémium, seleccione los siguientes tipos de

respuesta:
SuccessWithShareEgressThrottling
SuccessWithShareIngressThrottling
ClientShareEgressThrottlingError
ClientShareIngressThrottlingError
７ Nota
Si los tipos de respuesta no aparecen en la lista desplegable Valores de

dimensión, significa que el recurso no se ha limitado. Para agregar los valores
de dimensión, junto a la lista desplegable Valores de dimensión, seleccione
Agregar valor personalizado, especifique el tipo de respuesta (por ejemplo,
SuccessWithThrottling), seleccione Aceptar y repita estos pasos para agregar
todos los tipos de respuesta aplicables para el recurso compartido de
archivos.
5. Para recursos compartidos de archivos premium, seleccione en el menú

desplegable Nombre de la dimensión y seleccione Recurso compartido de
archivos. Para recursos compartidos de archivos estándar, vaya al paso 7.
７ Nota
Si el recurso compartido de archivos es estándar, en la dimensión Recurso

compartido de archivos no se mostrarán los recursos compartidos de archivo
porque las métricas por recurso compartido no están disponibles para los
recursos compartidos de archivos estándar. Las alertas de limitación de los
recursos compartidos de archivos estándar se desencadenarán si algún
recurso compartido de archivos de la cuenta de almacenamiento está limitado
y la alerta no identificará cuál se ha limitado. Dado que las métricas por
recurso compartido no están disponibles para los recursos compartidos de
archivos estándar, se recomienda tener un recurso compartido de archivos
por cada cuenta de almacenamiento.
6. Seleccione la lista desplegable Valores de dimensión y después los recursos

compartidos de archivos para los que quiera generar alertas.
7. Defina los parámetros de alerta (valor de umbral, operador, período de

retrospectiva y frecuencia de evaluación).
 Sugerencia
Si usa un umbral estático, el gráfico de métricas puede ayudar a determinar

un valor de umbral razonable si el recurso compartido de archivos se está
limitando actualmente. Si usa un umbral dinámico, el gráfico de métricas
mostrará los umbrales calculados según los datos recientes.
8. Seleccione la pestaña Acciones para agregar un grupo de acciones (correo

electrónico, SMS, etc.) a la alerta. Puede seleccionar un grupo de acciones
existente o crear uno nuevo.
9. Seleccione la pestaña Detalles para rellenar los detalles de la alerta, como el
nombre de la alerta, la descripción y la gravedad.
10. Seleccione Revisar y crear para crear la alerta.
Procedimientos para crear una alerta si el

tamaño del recurso compartido de archivos de
Azure es del 80 % de la capacidad
2. En la pestaña Condición del cuadro de diálogo Crear una regla de alerta ,

seleccione la métrica Capacidad de archivo .

７ Nota

recursos compartidos de archivos estándar. Las alertas de recursos
compartidos de archivos estándar se basan en todos los recursos compartidos
de archivos de la cuenta de almacenamiento. Dado que las métricas por

5. Escriba el Valor de umbral (en bytes). Por ejemplo, si el tamaño del recurso
compartido de archivos es 100 TiB y quiere recibir una alerta cuando su tamaño
sea el 80 % de la capacidad, el valor de umbral en bytes es 87960930222080.
6. Defina los parámetros de alerta (valor de umbral, operador, período de

retrospectiva y frecuencia de evaluación).

Procedimientos para crear una alerta si la salida

del recurso compartido de archivos de Azure
ha superado los 500 GiB en un día
2. En la pestaña Condición del cuadro de diálogo Crear una regla de alerta ,

seleccione la métrica Salida .

７ Nota

recursos compartidos de archivos estándar. Las alertas de recursos
compartidos de archivos estándar se basan en todos los recursos compartidos
de archivos de la cuenta de almacenamiento. Dado que las métricas por

5. En el Umbral de valor, escriba 536870912000 bytes.
6. En la lista desplegable Comprobar cada , seleccione la frecuencia de evaluación.


Creación de una alerta para una latencia de

servidor elevada
Para crear una alerta para una latencia de servidor elevada (promedio), siga estos pasos.
2. En la pestaña Condición del cuadro de diálogo Crear una regla de alerta,

seleccione la métrica Latencia de servidor correcta.

７ Nota
Para alertar sobre la experiencia de latencia general, deje los Valores de

dimensión desactivados. Para alertar sobre la latencia de transacciones
específicas, seleccione el nombre de la API en la lista desplegable. Por
ejemplo, al seleccionar los nombres de API de lectura y escritura con el
operador de igualdad, solo se mostrará la latencia de las transacciones de
datos. Al seleccionar el nombre de la API de lectura y escritura con el
operador de desigualdad, solo se mostrará la latencia de las transacciones de
metadatos.
4. Para definir la Lógica de alerta, seleccione Estática o Dinámica. En Estática,

seleccione la agregación Promedio, el operador Mayor que y el valor de umbral.
En Dinámica, seleccione la agregación Promedio, el operador Mayor que y la
sensibilidad del umbral.
 Sugerencia
un valor de umbral razonable si el recurso compartido está experimentado
una latencia alta. Si usa un umbral dinámico, el gráfico de métricas mostrará
los umbrales calculados según los datos recientes. Se recomienda usar la
lógica dinámica con una sensibilidad de umbral media y ajustar aún más
según sea necesario. Para obtener más información, consulte Descripción de
los umbrales dinámicos.
5. Defina el período y la frecuencia de retrospectiva de la evaluación.


Pasos siguientes
Análisis de métricas de Azure Files mediante Azure Monitor
Migración de las métricas de Azure Storage.
Migración a recursos compartidos de
archivos de Azure SMB
Artículo • 22/12/2023
En este artículo se tratan los aspectos básicos de una migración a recursos compartidos
de archivos de Azure SMB y se incluye una tabla de guías de migración. Estas guías le
ayudan a trasladar los archivos a recursos compartidos de archivos de Azure. Las guías
se organizan en función de dónde se encuentran los datos y el modelo de
implementación (solo en la nube o híbrido) al que va a realizar el cambio.
Se aplica a
ﾉ Expandir tabla
Aspectos básicos de la migración

Azure ofrece diferentes tipos de almacenamiento en la nube. Un aspecto fundamental
de las migraciones de archivos a Azure es determinar qué opción de almacenamiento de
Azure es la adecuada para los datos.
Los recursos compartidos de archivos de Azure son excelentes para los datos de
archivos de uso general. Estos datos incluyen cualquier contenido para el que use un
recurso compartido de SMB local. Con Azure File Sync, puede copiar en caché el
contenido de varios recursos compartidos de archivos de Azure en servidores que
ejecuten Windows Server en el entorno local.
En el caso de una aplicación que se ejecute actualmente en un servidor local, el

almacenamiento de archivos en un recurso compartido de archivos de Azure puede ser
una buena opción. Puede trasladar la aplicación a Azure y usar los recursos compartidos
de archivos de Azure como almacenamiento compartido. También puede considerar los
discos de Azure para este escenario.
Algunas aplicaciones en la nube no dependen de SMB ni del acceso compartido o a
datos locales de la máquina. Para estas, el almacenamiento de objetos como blobs de
Azure suele ser la mejor opción.
La clave de cualquier migración es capturar toda la fidelidad aplicable de los archivos al

mover los archivos desde su ubicación de almacenamiento actual a Azure. El grado de
fidelidad que admite la opción de almacenamiento de Azure y el nivel de exigencia de
su escenario también le ayudan a elegir el almacenamiento de Azure adecuado.
Los dos componentes básicos de un archivo son los siguientes:
Flujo de datos El flujo de datos de un archivo almacena el contenido del archivo.

Metadatos de archivo: a diferencia del almacenamiento de objetos en blobs de
Azure, un recurso compartido de archivos de Azure puede almacenar de forma
nativa metadatos de archivo. Normalmente, los datos de archivos de uso general
dependen de los metadatos de archivo. Pero puede que no sea el caso de los
datos de la aplicación. Los metadatos del archivo tienen estos subcomponentes:
Atributos de archivo, como solo lectura
Los permisos de archivos, que suelen denominarse permisos NTFS o ACL de
archivos y carpetas.
Marcas de tiempo, en particular, las marcas de tiempo de creación y última
modificación
Flujo de datos alternativo, que es un espacio para almacenar grandes
cantidades de propiedades no estándar. Este flujo de datos alternativo no se
puede almacenar en un archivo de un recurso compartido de archivos de Azure.
Se conserva localmente cuando se usa Azure File Sync.
La fidelidad de los archivos en una migración se puede definir como la capacidad de:
Almacenar toda la información del archivo aplicable en el origen.

Transferir archivos con la herramienta de migración.
Almacenar archivos en el almacenamiento de destino de la migración.
El destino de las guías de migración de este artículo es uno o varios recursos
compartidos de archivos de Azure. Tenga en cuenta esta lista de características que
los recursos compartidos de archivos de Azure no admiten.
Para asegurarse de que la migración se realiza de manera fluida, identifique la mejor

herramienta de copia para sus necesidades y haga coincidir un destino de
almacenamiento con el origen.
） Importante
Si va a migrar servidores de archivos locales a Azure File Sync, establezca las ACL
para el directorio raíz del recurso compartido de archivos antes de copiar un gran
número de archivos, ya que los cambios en los permisos de las ACL raíz pueden
tardar hasta un día en propagarse si se realiza después de una migración de
archivos de gran tamaño.
Los usuarios que utilizan Active Directory Domain Services (AD DS) como su controlador
de dominio local pueden acceder de forma nativa a un recurso compartido de archivos
de Azure. Lo mismo sucede con los usuarios de Microsoft Entra Domain Services. Ambos
usan su identidad actual para obtener acceso en función de los permisos de recurso
compartido, así como de las ACL de archivos y carpetas. Este comportamiento es similar
al de un usuario que se conecta a un recurso compartido de archivos local.
Obtenga más información sobre la autenticación de Active Directory local y la

autenticación de Microsoft Entra Domain Services para recursos compartidos de
archivos de Azure.
Metadatos admitidos
En la tabla siguiente se enumeran los metadatos admitidos para Azure Files.
） Importante
La marca de tiempo LastAccessTime no se admite actualmente para archivos ni

directorios en el recurso compartido de destino.
ﾉ Expandir tabla
Origen Destino
Estructura de La estructura de directorios original del origen se puede conservar en el recurso

directorios compartido de destino.
Vínculos Los vínculos simbólicos del origen se pueden conservar y asignar en el recurso
simbólicos compartido de destino.
Permisos de Azure Files admite las ACL de Windows, y estas deben establecerse en el recurso
acceso compartido de destino incluso si no hay ninguna integración de AD configurada
en el momento de la migración. Se deben conservar las siguientes ACL:
identificador de seguridad del propietario (SID), SID de grupo, listas de acceso
discrecional (DACL), listas de control de acceso del sistema (SACL).
Origen Destino
Creación de La marca de tiempo de creación original del archivo de origen se puede

marca de conservar en el recurso compartido de destino.
tiempo
Cambio de La marca de tiempo del cambio original del archivo de origen se puede
marca de conservar en el recurso compartido de destino.
tiempo
Marca de La marca de tiempo de la modificación original del archivo de origen se puede

tiempo conservar en el recurso compartido de destino.
modificada
Atributos de Los atributos comunes, como las marcas de solo lectura, ocultas y de archivo, se
archivo pueden conservar en el recurso compartido de destino.
Guías de migración
En la tabla siguiente se enumeran las combinaciones de herramientas sugeridas para
migrar a recursos compartidos de archivos de Azure SMB.
Cómo debe usar la tabla:
1. Busque la fila del sistema de origen en el que están almacenados los archivos.
2. Elija uno de los destinos siguientes:
Una implementación híbrida con Azure File Sync para copiar en caché el
contenido de los recursos compartidos de archivos de Azure de forma local
Recursos compartidos de archivos de Azure en la nube
Seleccione la columna de destino que coincida con su elección.
3. Dentro de la intersección de origen y destino, una celda de la tabla muestra los

escenarios de migración disponibles. Seleccione uno para vincularlo directamente
a la guía de migración.
Un escenario sin un vínculo aún no tiene ninguna guía de migración publicada.

Compruebe de vez en cuando en esta tabla si hay actualizaciones. Las nuevas guías se
publicarán en cuanto estén disponibles.
ﾉ Expandir tabla
Source Destino: Destino:
implementación híbrida implementación solo en la nube
(Azure Files + Azure File Sync) (Azure Files)
Combinación de herramientas: Combinación de herramientas:
Windows Azure File Sync Mediante Azure Storage

Server 2012 R2 y Azure File Sync y Azure Mover
versiones posteriores DataBox Mediante RoboCopy a un
archivos de Azure montado
Mediante Azure File Sync:
siga los mismos pasos que
para la implementación
híbrida de Azure File Sync y
desaprovisione el punto de
conexión del servidor al final.
Windows Server 2012 y Mediante DataBox y Azure Mediante Azure Storage

versiones anteriores File Sync a un sistema Mover
operativo de servidor Mediante el servicio de
reciente migración de
Mediante el servicio de almacenamiento a un
migración de servidor reciente con Azure
almacenamiento a un File Sync
servidor reciente con Mediante RoboCopy a un
Azure File Sync y, a recurso compartido de
continuación, cárguelo archivos de Azure montado
Almacenamiento A través de la carga de Mediante Azure Storage

conectado a la red Storage Mover + Azure Mover
(NAS) File Sync Mediante DataBox
Mediante la carga de Mediante RoboCopy a un
Azure File Sync recurso compartido de
Mediante archivos de Azure montado
DataBox + Azure File Sync
Linux (solo SMB) Azure File Sync y Mediante Azure Storage

RoboCopy Mover
Mediante RoboCopy a un
archivos de Azure montado
Cuadro de herramientas de migración

Herramientas de copia de archivos
Existen varias herramientas de copia de archivos disponibles de Microsoft y otras
empresas. A fin de seleccionar la herramienta adecuada para el escenario de migración,
tenga en cuenta estas preguntas fundamentales:
¿La herramienta admite las ubicaciones de origen y destino para la copia de

archivos?
¿La herramienta admite la ruta de acceso de red o los protocolos disponibles (por
ejemplo, REST o SMB) entre las ubicaciones de almacenamiento de origen y de
destino?
¿La herramienta conserva la fidelidad de los archivos necesaria que es compatible

con las ubicaciones de origen y destino?
En algunos casos, el almacenamiento de destino no admite la misma fidelidad que

el origen. Si el almacenamiento de destino es suficiente para sus necesidades, la
herramienta solo debe hacer coincidir las funcionalidades de fidelidad de los
archivos de destino.
¿La herramienta cuenta con características que le permiten adaptarse a la

estrategia de migración?
Por ejemplo, tenga en cuenta si la herramienta le permite minimizar el tiempo de

inactividad.
Cuando una herramienta admite una opción para reflejar un origen en un destino,
a menudo puede ejecutarla varias veces en el mismo origen y destino mientras el
origen permanece accesible.
La primera vez que se ejecuta la herramienta, copia la mayor parte de los datos.
Puede que esta primera ejecución tarde un rato. A menudo tarda más tiempo del
que le gustaría para dejar sin conexión el origen de datos de sus procesos
empresariales.
Si crea un reflejo de un origen en un destino (por ejemplo, con robocopy /MIR),

puede volver a ejecutar la herramienta en ese mismo origen y destino. Esta
segunda ejecución es mucho más rápida porque solo necesita transportar los
cambios del origen que se producen después de la ejecución anterior. Volver a
ejecutar una herramienta de copia de esta manera puede reducir
significativamente el tiempo de inactividad.
En la tabla siguiente se clasifican las herramientas de Microsoft y su idoneidad actual
para los recursos compartidos de archivos de Azure SMB:
ﾉ Expandir tabla
Recomendado Herramienta Compatibilidad con los Preservación de la

recursos compartidos de fidelidad de los
archivos de Azure archivos
Azure Storage Mover Compatible. Fidelidad completa*
RoboCopy Compatible. Los recursos Fidelidad completa*

compartidos de archivos de
Azure se pueden montar
como unidades de red.
Azure File Sync Integrado de forma nativa en Fidelidad completa*

recursos compartidos de
archivos de Azure.
Guía de migración de Compatible. Fidelidad completa*

Azure Storage
Servicio de migración Indirectamente compatible. Fidelidad completa*

de almacenamiento Los recursos compartidos de
archivos de Azure se pueden
montar como unidades de
red en servidores de destino
de SMS.
Data Box (incluido el Compatible. Data Box y Data Box

servicio de copia de (Las instancias de Data Box Heavy son totalmente
datos para cargar Disk no admite recursos compatibles con los
archivos en el compartidos de archivos metadatos.
dispositivo) grandes) Data Box Disk no
conserva los
metadatos de los
archivos.
AzCopy Se admite, pero no se No admite copias

versión más reciente recomienda. diferenciales a gran
escala y es posible
que se pierda cierta
fidelidad en los
archivos.
Más información
sobre cómo usar
AzCopy con recursos
Recomendado Herramienta Compatibilidad con los Preservación de la
recursos compartidos de fidelidad de los
archivos de Azure archivos
compartidos de
archivos de Azure
Explorador de Azure Compatible pero no se Pierde la mayor parte

Storage recomienda. de fidelidad en los
versión más reciente archivos, como las
listas ACL. Admite
marcas de tiempo.
Azure Data Factory Compatible. No copia los

metadatos.
* Fidelidad total: cumple o supera las funcionalidades de los recursos compartidos de

archivos de Azure.
Herramientas del asistente para la migración

En esta sección se describen las herramientas que le ayudan a planear y ejecutar las
migraciones.
Azure Storage Mover

Azure Storage Mover es un servicio de migración relativamente nuevo y totalmente
administrado que permite migrar archivos y carpetas a recursos compartidos de
archivos de Azure SMB con el mismo nivel de fidelidad de archivos que el recurso
compartido de archivos de Azure subyacente. Se mantienen la estructura de carpetas y
los valores de metadatos, como las marcas de tiempo de archivo y carpeta, las ACL y los
atributos de archivo.
RoboCopy
Incluido en Windows, RoboCopy es una de las herramientas más aplicables a las
migraciones de archivos SMB. La documentación principal de RoboCopy es un recurso
útil para las numerosas opciones de esta herramienta.
Guía de migración de Azure Storage
Comprender los datos es el primer paso para seleccionar el servicio de almacenamiento

de Azure y la estrategia de migración adecuados. El Programa de migración de Azure
Storage proporciona diferentes herramientas que pueden analizar los datos y la
infraestructura de almacenamiento para proporcionar conclusiones valiosas. Estas
herramientas pueden ayudarle a comprender el tamaño y el tipo de los datos, el
recuento de archivos y carpetas, y los patrones de acceso. Proporcionan una vista
consolidada de los datos y permiten la creación de varios informes personalizados.
Esta información puede ayudar a lo siguiente:
Identificar conjuntos de datos duplicados y redundantes

Identificar los datos de acceso más esporádico que se pueden mover a
almacenamiento menos costoso
Para más información, vea Matriz de comparación para los participantes del Programa
de migración de archivos de Azure.
TreeSize de JAM Software GmbH

Azure File Sync se escala principalmente con el número de elementos (archivos y
carpetas) y no con la cantidad de almacenamiento total. La herramienta TreeSize le
permite determinar el número de elementos de los volúmenes de Windows Server.
Puede usar la herramienta para crear una perspectiva antes de una implementación de
Azure File Sync. También puede usarla cuando se active la nube por niveles después de
la implementación. En ese escenario, verá el número de elementos y los directorios que
usan más la memoria caché del servidor.
La versión probada de la herramienta es la 4.4.1. Es compatible con los archivos de

niveles en la nube. La herramienta no producirá la coincidencia de los archivos en
niveles durante su funcionamiento normal.
Pasos siguientes
1. Cree un plan para la implementación de los recursos compartidos de archivos de
Azure (solo en la nube o híbridos) que quieras.
2. Revise la lista de guías de migración disponibles para encontrar la que coincida
con el origen y la implementación de los recursos compartidos de archivos de
Azure.
Más información sobre las tecnologías de Azure Files mencionadas en este artículo:
¿Qué es Azure Files

Información general de nube por niveles
Migración a recursos compartidos de archivos de
Azure NFS
Artículo • 22/12/2023
En este artículo se tratan los aspectos básicos de la migración de servidores de archivos de Linux a recursos
compartidos de archivos de Azure NFS, que solo están disponibles como recursos compartidos de archivos Premium
(tipo de cuenta FileStorage). También compararemos las herramientas de copia de archivos de código abierto fpsync y
rsync para comprender cómo se realizan al copiar datos en recursos compartidos de archivos de Azure.
７ Nota
Azure Files no admite listas de control de acceso (ACL) NFS.
Se aplica a
ﾉ Expandir tabla
Requisitos previos
Necesitará al menos un recurso compartido de archivos de Azure NFS montado en una máquina virtual (VM) Linux.
Para crear uno, consulte Creación de un recurso compartido de archivos de Azure NFS y montaje en una máquina
virtual Linux. Se recomienda montar el recurso compartido con nconnect para usar varias conexiones TCP. Para más
información, consulte Mejora del rendimiento del recurso compartido de archivos NFS de Azure.
Herramientas de migración
Muchas herramientas de código abierto están disponibles para transferir datos a recursos compartidos de archivos
NFS. Sin embargo, no todos ellos son eficaces cuando se trabaja con un sistema de archivos distribuido con distintas
consideraciones de rendimiento en comparación con las configuraciones locales. En un sistema de archivos distribuido,
cada llamada de red implica un recorrido de ida y vuelta a un servidor que podría no ser local. Por lo tanto, optimizar el
tiempo invertido en las llamadas de red es fundamental para lograr un rendimiento óptimo y una transferencia de
datos eficaz a través de la red.
Uso de fpsync frente a rsync

A pesar de ser uniproceso, rsync es una herramienta versátil de copia de archivos de código abierto. Puede copiar
localmente, hacia o desde otro host a través de cualquier shell remoto, o hacia o desde un demonio rsync remoto.
Ofrece muchas opciones y permite copiar una especificación flexible del conjunto de archivos. Sin embargo, fpsync
es una aplicación multiproceso y por tanto, ofrece algunas ventajas, incluida la capacidad de ejecutar trabajos rsync en
paralelo.
En este artículo, usaremos fpsync para mover datos de un servidor de archivos Linux a recursos compartidos de
archivos de Azure NFS.
Para copiar los datos, fpsync usa herramientas rsync (valor predeterminado), cpio o tar. Calcula subconjuntos del
directorio de origen src_dir/ y genera trabajos de sincronización para sincronizarlos con el directorio de destino
dst_dir/ . Ejecuta trabajos de sincronización sobre la marcha mientras rastrea simultáneamente el sistema de archivos,
lo que lo convierte en una herramienta útil para migrar de forma eficaz sistemas de archivos grandes y copiar grandes
conjuntos de datos con varios archivos.
７ Nota
Fpsync solo sincroniza el contenido del directorio, no el propio directorio de origen. A diferencia de rsync, fpsync
aplica el "/" final en el directorio de destino, lo que significa que no obtendrá un subdirectorio con el nombre del
directorio de origen en el directorio de destino después de la sincronización.
Instalación de fpart
Para usar fpsync, deberá instalar el particionador de sistema de archivos fpart. Instale fpart en la distribución de Linux
que prefiera. Una vez instalado, debería ver fpsync en /usr/bin/ .
Ubuntu
En Ubuntu, use el administrador de paquetes apt para instalar fpart.
Bash
sudo apt-get install fpart
Copia de datos de origen a destino

Asegúrese de que el recurso compartido de archivos de Azure de destino (destino) está montado en una máquina
virtual Linux. Vea Requisitos previos:.
Si va a realizar una migración completa, copiará los datos en tres fases:
1. Copia de línea base: copia de origen a destino cuando no exista ningún dato en el destino. Para la copia de línea
base, se recomienda usar fpsync con cpio como herramienta de copia.
2. Copia incremental: copie solo los cambios incrementales de origen a destino. Para la sincronización incremental,
recomendamos usar fpsync con rsync como herramienta de copia. Esto se debe hacer varias veces para capturar
todos los cambios.
3. Pase final: se necesita un pase final para eliminar los archivos del destino que no existen en el origen.
La copia de datos con fpsync siempre implica alguna versión de este comando:
Bash
fpsync -m <specify copy tool - rsync/cpio/tar> -n <parallel transfers> <absolute source path> <absolute
destination path>
Copia de línea base

Para la copia de línea base, use fpsync con cpio.
Bash
fpsync -m cpio –n <parallel transfers> <absolute source path> <absolute destination path>
Para obtener más información, consulte Compatibilidad con Cpio y Tar .
Copia incremental
Para la sincronización incremental, use fpsync con la herramienta de copia predeterminada (rsync). Para capturar todos
los cambios, se recomienda ejecutarlo varias veces.
Bash
fpsync –n <parallel transfers> <absolute source path> <absolute destination path>
De manera predeterminada, fpsync especificará las siguientes opciones de rsync: -lptgoD -v --numeric-ids . Puede
especificar opciones de rsync adicionales agregando –o option al comando fpsync.
Pase final
Después de varias sincronizaciones incrementales, debe realizar un pase final para eliminar los archivos de ese destino
que no existen en el origen. Puede hacerlo manualmente con rsync --delete para eliminar archivos adicionales del
directorio /data/dst/ o puede usar fpsync con la opción -E. Para obtener más información, consulte El pase final .
Comparación de rsync y fpsync con diferentes conjuntos de

datos
En esta sección se compara el rendimiento de rsync y fpsync con diferentes conjuntos de datos.
Conjuntos de datos y configuración

En la tabla siguiente se enumeran los distintos conjuntos de datos que usamos para comparar el rendimiento de las
herramientas de copia en distintas cargas de trabajo.
ﾉ Expandir tabla
Configuración Tipo de copia Recuento de Recuento de Tamaño de tamaño

# archivos directorios archivo total
1.1 Copia de línea base 1 millón 1 0-32 KiB 18 GiB
1,2 Incremental (cambio 1 millón 1 0-32 KiB 18 GiB

diferencial)
2 Copia de línea base 191,345 3,906 0-32 KiB 3 GiB
3 Copia de línea base 5\.000 1 10 MiB 50 GiB
Las pruebas se realizaron en Máquinas virtuales de Azure Standard_D8s_v3 con 8 vCPU, 32 GiB de memoria y más de 1
TiB de espacio en disco para grandes conjuntos de datos. Para el destino, hemos configurado recursos compartidos de
archivos de Azure NFS con más de 1 tamaño aprovisionado de TiB.
Experimentos y resultados: rsync frente a fpsync

En función de nuestros experimentos con las configuraciones anteriores, observamos que fpsync se ha realizado mejor
cuando se usa con 64 subprocesos con rsync y 16 subprocesos con cpio para un recurso compartido de archivos NFS
de Azure montado con nconnect=8 . Los resultados reales variarán en función de la configuración y los conjuntos de
datos.
７ Nota
El rendimiento de Azure Files puede ser mucho mayor que el representado en los gráficos siguientes. Algunos de
los experimentos se realizaron deliberadamente con pequeños conjuntos de datos para simplificar.
Configuración 1
Para un único directorio con 1 millón de archivos pequeños que sume 18 GiB, hemos ejecutado esta prueba como una
copia de línea base y una copia incremental.
Hemos observado los siguientes resultados realizando una copia de línea base de origen a destino.
Hemos observado los siguientes resultados realizando una copia incremental (cambio diferencial).
Configuration 2
Observamos los siguientes resultados haciendo una copia de línea base de 191.345 archivos pequeños en 3.906
directorios con un tamaño total de 3 GiB.
Configuración 3
Observamos los siguientes resultados haciendo una copia de línea base de 5000 archivos grandes (10 MiB) en un único
directorio con un tamaño total de 50 GiB.
Resumen de los resultados

El uso de aplicaciones multiproceso como fpsync puede mejorar el rendimiento e IOPS al migrar a recursos
compartidos de archivos de Azure NFS en comparación con las herramientas de copia de un solo subproceso, como
rsync. Nuestras pruebas muestran que:
La distribución de datos en el directorio ayuda a paralelizar el proceso de migración y, por tanto, logra un mejor
rendimiento.
La copia de datos de tamaños de archivo más grandes produce un mejor rendimiento que copiar datos de
tamaños de archivo más pequeños.
En la tabla siguiente se resumen los resultados.
ﾉ Expandir tabla
Configuración Recuento Recuento Tamaño tamaño Duración de Rendimiento Duración de Rendimiento Ganancia
# de de de total rsync rsync fpsync de fpsync de
archivos directorios archivo rendimiento
1,1 (línea 1 millón 1 0- 18 GiB 837,06 minutos 0,33 MiB/s 228,16 1,20 MiB/s 267 %
base) 32 KiB minutos
1,2 1 millón 1 0- 18 GiB 84,02 minutos 3,25 MiB/s 7,5 minutos 36,41 MiB/s 1,020 %
(incremental) 32 KiB
Configuración Recuento Recuento Tamaño tamaño Duración de Rendimiento Duración de Rendimiento Ganancia
# de de de total rsync rsync fpsync de fpsync de
archivos directorios archivo rendimiento
2 (línea base) 191,345 3,906 0- 3 GiB 191,86 minutos 0,27 MiB/s 8,47 minutos 6,04 MiB/s 2,164 %
32 KiB
3 (línea base) 5\.000 1 10 MiB 50 GiB 8,12 minutos 105,04 MiB/s 2,76 minutos 308,90 MiB/s 194 %
Aviso de declinación de responsabilidades sobre la información

de terceros
Las herramientas de código abierto mencionadas en este artículo son soluciones conocidas de terceros. No son
desarrolladas, propiedad ni compatibles con Microsoft, ya sea directa o indirectamente. Es responsabilidad del cliente
examinar la licencia de software y la declaración de soporte técnico proporcionadas en la documentación de terceros.
Pasos siguientes
Mejorar el rendimiento del recurso compartido de archivos de Azure NFS
Migración de archivos entre recursos
compartidos de archivos de SMB de
Azure
Artículo • 29/07/2023
En este artículo se describe cómo migrar archivos de un recurso compartido de archivos

de SMB de Azure a otro. Esto se hace a menudo para migrar de un recurso compartido
de archivos estándar a otro Premium y así obtener un mayor rendimiento para la carga
de trabajo de la aplicación.
２ Advertencia
Si usa Azure File Sync, el proceso de migración es diferente al descrito en este

artículo. En ese caso, consulte Migración de archivos de un recurso compartido de
archivos de Azure a otro al usar Azure File Sync.
Se aplica a
Migración con Robocopy

Siga estos pasos para migrar con Robocopy, una utilidad de copia de archivos de línea
de comandos integrada en Windows.
1. Implemente una máquina virtual (VM) Windows en Azure en la misma región que
el recurso compartido de archivos de origen. Mantener los datos y las redes en
Azure será rápido y le ahorrará los cargos de transferencia de datos salientes. Para
obtener un rendimiento óptimo, se recomienda un tipo de máquina virtual de
varios núcleos con al menos 56 GiB de memoria, por ejemplo , Standard_DS5_v2.
2. Monte los recursos compartidos de archivos de origen y de destino en la máquina
virtual. Asegúrese de montarlos con la clave de cuenta de almacenamiento para
que la máquina virtual tenga acceso a todos los archivos. No use una identidad de
dominio.
3. Ejecute este comando en el símbolo del sistema de Windows. También puede

incluir marcas para las características de registro como procedimiento
recomendado (/NP, /NFL, /NDL, /UNILOG).
Consola
robocopy <source> <target> /MIR /COPYALL /MT:16 /R:2 /W:1 /B /IT

/DCOPY:DAT
Si el recurso compartido de origen se montó como s:\ y el destino era t:\, el

comando será así:
Consola
robocopy s:\ t:\ /MIR /COPYALL /MT:16 /R:2 /W:1 /B /IT /DCOPY:DAT
Puede ejecutar el comando mientras el origen siga en línea, pero tenga en cuenta
que cualquier E/S funcionará con los límites del recurso compartido existente.
4. Una vez completada la ejecución inicial, desconecte la aplicación del recurso

compartido existente y vuelva a ejecutar el mismo comando robocopy. Esto
copiará todos los cambios que se produjeron desde la ejecución inicial, omitiendo
los datos de archivo que ya se han copiado.
5. Una vez completado el comando por segunda vez, puede redirigir la aplicación al
nuevo recurso compartido.
Consulte también
Migración a recursos compartidos de archivos de Azure con RoboCopy
Migración de archivos de un recurso compartido de archivos de Azure a otro al
usar Azure File Sync
Uso de RoboCopy para migrar a
Azure
Artículo • 23/10/2023
En este artículo de migración se describe el uso de RoboCopy para mover o migrar

archivos a un recurso compartido de archivos SMB de Azure. RoboCopy es una utilidad
de copia de archivos de confianza y conocida con un conjunto de características que la
hace adecuada para las migraciones. Usa el protocolo SMB, por lo que se puede aplicar
de forma amplia a cualquier combinación de origen y destino compatible con SMB.
＂ Orígenes de datos: cualquier origen que admita el protocolo SMB, como

Almacenamiento conectado a la red (NAS), servidores Windows o Linux, otro
recurso compartido de archivos de Azure y muchos más.
＂ Ruta de migración: desde el almacenamiento de origen ⇒ máquina Windows con
RoboCopy ⇒ recurso compartido de archivos.
＂ Sin almacenamiento en caché de archivos en el entorno local: dado que el objetivo
final es usar los recursos compartidos de archivos de Azure directamente en la
nube, no hay ningún plan para usar Azure File Sync.
Hay muchas rutas de migración diferentes para diversas combinaciones de origen e

implementación. Consulte la tabla de guías de migración para encontrar la migración
que mejor se adapte a sus necesidades.
Se aplica a
AzCopy frente a RoboCopy

AzCopy y RoboCopy son dos herramientas de copia de archivos radicalmente diferentes.
RoboCopy usa cualquier versión del protocolo SMB. AzCopy es una herramienta nativa
de la nube que se puede usar para mover datos siempre que el destino esté en Azure
Storage. AzCopy depende de un protocolo REST.
RoboCopy, como herramienta de copia basada en Windows de confianza, tiene la

ventaja de copiar archivos con plena fidelidad. RoboCopy admite muchos escenarios de
migración debido a su amplio conjunto de características y a la capacidad de copiar
archivos y carpetas con plena fidelidad. Consulte la sección fidelidad de archivos del
artículo de información general sobre la migración para obtener más información sobre
la importancia de copiar archivos con la máxima fidelidad posible.
AzCopy, por otro lado, se ha expandido recientemente para admitir la copia de archivos
con cierta fidelidad y ha agregado las primeras características necesarias para
considerarse como una herramienta de migración. Sin embargo, todavía hay lagunas y
pueden surgir malentendidos con facilidad en relación con la funcionalidad al comparar
las marcas de AzCopy con las de RoboCopy.
Un ejemplo: RoboCopy /MIR reflejará el origen en el destino, lo que significa que se

tienen en cuenta los archivos agregados, modificados y eliminados. Una diferencia
importante en el uso de AzCopy -sync es que los archivos eliminados en el origen no se
eliminan del destino. Por ello, el conjunto de características de copia diferencial es
incompleto. AzCopy continuará evolucionando. En este momento, no se recomienda
usar AzCopy para escenarios de migración con recursos compartidos de archivos de
Azure como destino.
Objetivos de la migración
El objetivo es mover los datos de ubicaciones de recursos compartidos de archivos
existentes a Azure. En Azure, almacenará los datos en recursos compartidos de archivos
nativos de Azure que puede usar sin necesidad de Windows Server. Esta migración se
debe realizar de forma que garantice la integridad de los datos de producción y la
disponibilidad durante la migración. Esta última requiere que el tiempo de inactividad
sea mínimo, para ajustarse o solo superar ligeramente las ventanas de mantenimiento
regulares.

El proceso de migración consta de varias fases. Primero, deberá implementar cuentas de
almacenamiento y recursos compartidos de archivos de Azure. Después, configurará las
redes, considerará una implementación de espacio de nombres DFS (DFS-N) o
actualizará la existente. Una vez que haya llegado el momento de la copia de datos real,
deberá tener en cuenta las ejecuciones diferenciales de RoboCopy repetidas para
minimizar el tiempo de inactividad y, por último, deberá migrar a los usuarios a los
recursos compartidos de archivos de Azure recién creados. En las secciones siguientes
se describen detalladamente las fases del proceso de migración.
Fase 1: Implementación de recursos de

almacenamiento de Azure
En esta fase, aprovisionará las cuentas de almacenamiento de Azure y los recursos
compartidos de archivos SMB de Azure que se encuentren en estas.
Recuerde que un recurso compartido de archivos de Azure se implementa en la nube en

una cuenta de almacenamiento de Azure. En el caso de los recursos compartidos de
archivos, esta disposición hace que la cuenta de almacenamiento sea un destino de
escalado para los números de rendimiento, como IOPS y rendimiento. Si coloca varios
recursos compartidos de archivos en una única cuenta de almacenamiento, está creando
un grupo compartido de IOPS y rendimiento para esos recursos compartidos.
Como regla general, puede agrupar varios recursos compartidos de archivos de Azure
en la misma cuenta de almacenamiento si tiene recursos compartidos de archivo o que
espera que tengan escasa actividad diaria. Sin embargo, si tiene recursos compartidos
muy activos (recursos compartidos usados por muchos usuarios o aplicaciones), es
conveniente implementar cuentas de almacenamiento con un recurso compartido de
archivos cada una. Estas limitaciones no se aplican a las cuentas de almacenamiento de
FileStorage (prémium), donde el rendimiento se aprovisiona y garantiza explícitamente
para cada recurso compartido.
７ Nota
Hay un límite de 250 cuentas de almacenamiento por suscripción por cada región
de Azure. Con un aumento de cuota, podría crear hasta 500 cuentas de
almacenamiento por región. Para obtener más información, consulte Aumento de
las cuotas de la cuenta de Azure Storage.
Otra consideración a la hora de implementar una cuenta de almacenamiento es la

redundancia. Consulte Redundancia de Azure Files.
Los recursos compartidos de archivos de Azure Estándar se crean con un límite de 5 TiB
de forma predeterminada. Si necesita más capacidad, puede crear un recurso
compartido de archivos grande (hasta 100 TiB). Sin embargo, ese recurso compartido
solo puede las opciones de redundancia de almacenamiento con redundancia local o de
almacenamiento con redundancia de zona. Tenga en cuenta sus necesidades de
redundancia de almacenamiento antes de usar recursos compartidos de archivos de
100 TiB.
Si ha creado una lista de recursos compartidos, tiene que asignar cada recurso
compartido a la cuenta de almacenamiento en la que se creará.
Los nombres de los recursos también son importantes. Por ejemplo, si agrupa varios
recursos compartidos para el Departamento de Recursos Humanos en una cuenta de
almacenamiento de Azure, debe asignar el nombre adecuado a la cuenta de
almacenamiento. Del mismo modo, al asignar el nombre a los recursos compartidos de
archivos de Azure, tiene que usar nombres similares a los que se usan para sus
homólogos locales.
Ahora, implemente el número adecuado de cuentas de almacenamiento de Azure con el

número adecuado de recursos compartidos de archivos de Azure en estas. Para ello,
siga las instrucciones de Creación de un recurso compartido de archivos SMB. En la
mayoría de los casos, se recomienda asegurarse de que la región de cada una de las
cuentas de almacenamiento es la misma.
Fase 2: Preparación para el uso de recursos

Con la información de esta fase, podrá decidir cómo se habilitarán los servidores y los
usuarios dentro y fuera de Azure para usar los recursos compartidos de archivos de
Azure. Las decisiones más críticas son las siguientes:
Redes: habilite las redes para enrutar el tráfico SMB.

Autenticación: configure cuentas de almacenamiento de Azure para la
autenticación Kerberos. El uso de la autenticación basada en identidades y unir a
un dominio la cuenta de almacenamiento permitirá que las aplicaciones y los
usuarios usen su identidad de AD para la autenticación.
Autorización: las ACL de nivel de recurso compartido para cada recurso
compartido de archivos de Azure permitirán a los usuarios y grupos de AD acceder
a un recurso compartido determinado. Además, dentro de un recurso compartido
de archivos de Azure, las ACL nativas de NTFS asumirán el control. La autorización
basada en ACL de archivos y carpetas funciona del mismo modo que en los
recursos compartidos SMB locales.
Continuidad empresarial: la integración de recursos compartidos de archivos de
Azure en un entorno existente suele implicar la conservación de las direcciones de
recursos compartidos existentes. Si aún no está usando los espacios de nombres
DFS, considere la posibilidad de configurarlos en su entorno. De este modo, podría
conservar sin cambios las direcciones de recursos compartidos que usan los
usuarios y los scripts. DFS-N proporciona un servicio de enrutamiento de espacios
de nombres para SMB mediante el redireccionamiento de los clientes a los
https://www.youtube-nocookie.com/embed/jd49W33DxkQ
la información en cinco sencillos pasos.
En el vídeo se hace referencia a documentación dedicada para algunos temas:
Introducción a las identidades
Unión a un dominio de una cuenta de almacenamiento
Información general sobre redes para recursos compartidos de archivos de Azure
Configuración de puntos de conexión públicos y privados
Configuración de una VPN S2S
Configuración de una VPN de Windows P2S
Configuración de una VPN P2S de Linux
Configuración del reenvío de DNS
Configuración de DFS-N
Montaje de un recurso compartido de archivos de Azure

Antes de que pueda usar RoboCopy, debe hacer que el recurso compartido de archivos
de Azure sea accesible a través de SMB. La manera más fácil consiste en montar el
recurso compartido como una unidad de red local en la instancia de Windows Server
que está planeando usar para RoboCopy.
） Importante
Asegúrese de montar el recurso compartido de archivos de Azure usando la clave

de acceso de la cuenta de almacenamiento. No use una identidad de dominio.
Antes de que pueda montar correctamente un recurso compartido de archivos de
Azure en una instancia local de Windows Server, debe haber completado la fase 2:
Preparación para el uso de recursos compartidos de archivos de Azure.
Una vez todo listo, revise Uso de un recurso compartido de archivos de Azure con
Windows. A continuación, monte el recurso compartido de archivos de Azure para el
que desea iniciar RoboCopy.
Fase 3: RoboCopy
El siguiente comando RoboCopy solo copiará las diferencias (archivos y carpetas
actualizados) desde el almacenamiento de origen al recurso compartido de archivos de
Azure.
Consola
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO

/DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:
<FilePathAndName>
Conmutador Significado
/MT:n Permite que Robocopy se ejecute en modo multiproceso. El valor

predeterminado para n es 8. La cantidad máxima es de 128 subprocesos. Aunque
un número elevado de subprocesos contribuye a saturar el ancho de banda
disponible, no significa que la migración sea siempre más rápida con más
subprocesos. Las pruebas realizadas con Azure Files indican que entre 8 y 20
proporcionan un rendimiento equilibrado para la ejecución de una copia inicial.
Las ejecuciones subsiguientes de /MIR se ven afectadas progresivamente por el
proceso disponible en comparación con el ancho de banda de red disponible.
Para las ejecuciones posteriores, haga coincidir más estrechamente el valor del
número de subprocesos con el número de núcleos del procesador y el número
de subprocesos por núcleo. Considere si es necesario reservar los núcleos para
otras tareas que quizá tenga un servidor de producción. Las pruebas realizadas
con Azure Files han demostrado que, con un máximo de 64 subprocesos, se
obtiene un buen rendimiento, pero solo si los procesadores pueden mantenerlos
activos al mismo tiempo.
/R:n Número máximo de reintentos para un archivo que no se puede copiar en el

primer intento. Robocopy prueba n veces antes de determinar que el archivo,
definitivamente, no se copia en la ejecución. Para optimizar el rendimiento de la
ejecución, elija un valor de dos o tres si cree que hubo problemas de tiempo de
espera que causaron errores en el pasado. Esto puede ser más habitual a través
de vínculos WAN. Elija no reintentarlo o un valor de uno si cree que el archivo no
se pudo copiar porque estaba en uso de forma activa. Volver a intentarlo unos
segundos más tarde puede no ser suficiente tiempo para que cambie el estado
de “en uso” del archivo. Es posible que los usuarios o aplicaciones que tienen
abierto el archivo necesiten más tiempo. En este caso, puede que, si acepta que el
archivo no se ha copiado y lo incluye en una ejecución posterior planeada de
Robocopy, el archivo se copie finalmente. Esto ayuda a que la ejecución en curso
finalice más rápido al no prolongarla con muchos reintentos que, al final, dan
lugar a una mayoría de errores de copia porque los archivos siguen abiertos
después del tiempo de espera de reintento.
/W:n Especifica el tiempo que espera Robocopy antes de intentar copiar un archivo
que no se ha copiado correctamente en el último intento. n es el número de
segundos de espera entre reintentos. /W:n a menudo se usa junto con /R:n .
/B Ejecuta Robocopy en el mismo modo que usaría una aplicación de copia de

seguridad. Este conmutador permite que Robocopy mueva los archivos para los
que el usuario actual no tiene permisos. El modificador de la copia de seguridad
depende de la ejecución del comando Robocopy en una consola con privilegios
elevados de administrador o en una ventana de PowerShell. Si usa Robocopy para
Azure Files, asegúrese de montar el recurso compartido de archivos de Azure con
la clave de acceso de la cuenta de almacenamiento en lugar de una identidad de
dominio. Si no lo hace, es posible que los mensajes de error no lo lleven
intuitivamente a una solución del problema.
/MIR (Reflejar origen en destino). Permite que Robocopy solo tenga que copiar las
diferencias entre el origen y el destino. Se copiarán los subdirectorios vacíos. Se
copiarán los elementos (archivos o carpetas) que hayan cambiado o no existan en
el destino. Los elementos que existan en el destino, pero no en el origen, se
purgarán (se eliminarán) del destino. Cuando use este conmutador, haga
coincidir exactamente con las estructuras de carpetas de origen y de destino.
Coincidencia significa que se copia desde el nivel de carpeta y origen correctos en
el nivel de carpeta del destino coincidente. Solo entonces se puede realizar
correctamente una copia de "puesta al día". Cuando el origen y el destino no
coinciden, el uso de /MIR dará lugar a eliminaciones y nuevas copias a gran
escala.
/IT Garantiza que se conserve la fidelidad en ciertos escenarios de reflejo.

Por ejemplo, si un archivo experimenta un cambio de ACL y una actualización de
atributo entre dos ejecuciones de Robocopy, se marca como oculto. Sin /IT ,
Robocopy podría omitir el cambio de ACL y no se transferiría a la ubicación de
destino.
/COPY: Fidelidad de la copia del archivo. Predeterminado: /COPY:DAT . Marcas de copia:

[copyflags] D = datos, A = atributos, T = marcas de tiempo, S = seguridad = ACL de NTFS,
O = información del propietario, U = información de a D ditoría. No se puede
almacenar la información de auditoría en un recurso compartido de archivos de
Azure.
/DCOPY: Fidelidad de la copia de directorios. Predeterminado: /DCOPY:DA . Marcas de copia:

[copyflags] D = Datos, A = Atributos, T = Marcas de tiempo.
/NP Especifica que no se mostrará el progreso de la copia de cada archivo y carpeta.

Mostrar el progreso reduce significativamente el rendimiento de la copia.
/NFL Especifica que los nombres de archivo no se han registrado. Mejora el

rendimiento de la copia.
/NDL Especifica que los nombres de directorio no se han registrado. Mejora el

/XD Especifica los directorios que se excluirán. Cuando ejecute Robocopy en la raíz de
un volumen, considere la posibilidad de excluir la carpeta System Volume
Information oculta. Si se usa como está previsto, toda la información que
contiene es específica del volumen exacto en este sistema exacto y se puede
recompilar a petición. Copiar esta información no será útil en la nube ni cuando
los datos se vuelvan a copiar en otro volumen Windows. Dejar este contenido
atrás no debe considerarse una pérdida de datos.
/UNILOG: Escribe el estado en el archivo de registro como Unicode. (Sobrescribe el registro

<file name> existente).
/L Solo para una serie de pruebas

Los archivos solo se muestran en la lista. No se copiarán, no se eliminarán y no
tendrán marca de tiempo. Por lo general, se usa con /TEE para la salida de la
consola. Es posible que las marcas del script de ejemplo, como /NP , /NFL y /NDL ,
se tengan que quitar para lograr los resultados de la prueba documentados
correctamente.
/Z Usar con precaución

Copia los archivos en modo de reinicio. Este conmutador solo se recomienda en
un entorno de red inestable. Reduce significativamente el rendimiento de la copia
debido al registro adicional.
/ZB Usar con precaución

Usa el modo de reinicio. Si se deniega el acceso, esta opción utiliza el modo de
copia de seguridad. Esta opción reduce significativamente el rendimiento de la
copia debido a los puntos de control.
） Importante
Se recomienda usar Windows Server 2022. Cuando use Windows Server 2019,
asegúrese de que está instalado con el nivel de revisión más reciente o, al menos,
la actualización KB5005103 del sistema operativo . Contiene correcciones
importantes para determinados escenarios de Robocopy.
 Sugerencia
Consulte la sección de solución de problemas si RoboCopy está afectando a su

entorno de producción, si notifica un gran número de errores o si no progresa tan
rápido como se espera.
Fase 4: Migración total de los usuarios

Al ejecutar por primera vez el comando RoboCopy, los usuarios y las aplicaciones siguen
accediendo a los archivos en el origen de la migración y pueden modificarlos. Es posible
que RoboCopy haya procesado un directorio, haya pasado al siguiente y, después, un
usuario en la ubicación de origen agregue, cambia o elimina un archivo que no se
procesará en esta ejecución actual de RoboCopy. Este comportamiento es normal.
La primera ejecución consiste en migrar la mayor parte de los datos renovados al

recurso compartido de archivos de Azure. Esta primera copia puede tardar unos
minutos. Consulte la sección de solución de problemas para obtener más información
acerca de lo que puede afectar a la velocidad de RoboCopy.
Una vez completada la ejecución inicial, vuelva a ejecutar el comando.
La segunda vez que ejecute RoboCopy para el mismo recurso compartido se completará
más rápido, ya que solo necesita transportar los cambios posteriores a la última
ejecución. Puede ejecutar trabajos repetidos para el mismo recurso compartido.
Después de considerar la cantidad de tiempo de inactividad aceptable, debe quitar el

acceso de usuario a los recursos compartidos de origen. Para ello, siga los pasos que
impidan que los usuarios cambien el contenido y la estructura de archivos y carpetas.
Un ejemplo es dirigir DFS-Namespace a una ubicación no existente o cambiar las ACL
de cada recurso compartido.
Ejecute una última ronda de RoboCopy. Recuperará todos los cambios que puedan
haberse omitido. El tiempo necesario para hacer este último paso depende de la
velocidad del análisis de RoboCopy. Para realizar un cálculo estimado del tiempo (que
equivale al tiempo de inactividad) averigüe cuánto tardó en realizarse la ejecución
anterior.
En la fase 2, configuró a los usuarios para acceder al recurso compartido con su

identidad y debería haber establecido una estrategia para que los usuarios usen rutas
de acceso establecidas a los nuevos recursos compartidos de archivos de Azure (DFS-N).
Puede intentar ejecutar algunas de estas copias entre distintos recursos compartidos de
origen y destino en paralelo. Al hacerlo, tenga en cuenta el rendimiento de la red y la
relación de número de subprocesos y núcleos para no sobrecargar el sistema.
Solución de problemas y optimización

La velocidad y la tasa de éxito de una ejecución determinada de RoboCopy dependerán
de varios factores:
El número de IOPS en el almacenamiento de origen y de destino.

El ancho de banda de red disponible entre el origen y el destino.
La capacidad de procesar rápidamente archivos y carpetas en un espacio de
nombres.
El número de cambios entre ejecuciones de RoboCopy.
el tamaño y el número de archivos que debe copiar
Consideraciones sobre el ancho de banda y el número de

IOPS.
En esta categoría, debe tener en cuenta la capacidad del almacenamiento de origen, el
almacenamiento de destinoy la red que los conecta. El mayor rendimiento posible
viene determinado por el más lento de estos tres componentes. Asegúrese de que la
infraestructura de red se haya configurado para admitir las mejores velocidades de
transferencia.
Ｕ Precaución
Aunque es deseable copiar lo más rápido posible, tenga en cuenta el uso de la red
local y el dispositivo NAS en otras tareas que suelen ser críticas para la empresa.
Copiar lo más rápido posible podría no ser deseable si existe el riesgo de que la
migración acapare los recursos disponibles.
Tenga en cuenta cuándo es mejor para su entorno hacer migraciones: durante el

día, fuera del horario laboral o en los fines de semana.
Considere también la calidad de servicio de redes en Windows Server para limitar
la velocidad de RoboCopy.
Evite trabajo innecesario a las herramientas de migración.
RoboCopy puede introducir retrasos entre paquetes al especificar el modificador

/IPG:n , en donde el valor n se calcula en milisegundos entre los paquetes de
RoboCopy. El uso de este modificador puede ayudar a evitar el acaparamiento de los

recursos en dispositivos de E/S restringidos y vínculos de red saturados.
/IPG:n no se puede usar para limitar la red a un número exacto de megabits por
segundo. En su lugar, use la calidad de servicio de red de Windows Server. RoboCopy se

basa íntegramente en el protocolo SMB para todas las necesidades de red. El uso de
SMB es el motivo por el que RoboCopy no puede influir en el propio rendimiento de la
red, pero puede ralentizar su uso.
Un enfoque similar se aplica a las operaciones de IOPS observadas en el dispositivo
NAS. El tamaño del clúster en el volumen de NAS y los tamaños de paquete, entre otros
factores, influyen en las IOPS observadas. La introducción de retraso entre paquetes
suele ser la manera más fácil de controlar la carga en el dispositivo NAS. Pruebe varios
valores, por ejemplo, de 20 milisegundos (n = 20) a múltiplos de ese número. Una vez
que introduzca un retraso, podrá valorar si las otras aplicaciones funcionan según lo
esperado. Esta estrategia de optimización le permitirá encontrar la velocidad de
RoboCopy óptima para su entorno.
Velocidad de procesamiento
RoboCopy recorrerá el espacio de nombres al que se apunta y evaluará cada archivo y
carpeta con fines de copia. Los archivos se evaluarán durante una copia inicial y durante
las copias de puesta al día. Por ejemplo, ejecuciones repetidas de RoboCopy/MIR en las
mismas ubicaciones de almacenamiento de origen y de destino. Estas ejecuciones
repetidas son útiles para minimizar el tiempo de inactividad de los usuarios y las
aplicaciones, así como para mejorar la tasa de éxito general de los archivos migrados.
A menudo, el ancho de banda suele considerarse como el factor más restrictivo en una
migración, algo que puede ser cierto. Pero la posibilidad de enumerar un espacio de
nombres puede influir en el tiempo total de copia para espacios de nombres más largos
con archivos más pequeños. Tenga en cuenta que copiar 1 TiB de archivos pequeños
tardará mucho más que copiar 1 TiB de un número inferior de archivos de mayor
tamaño, si se supone que todas las demás variables permanecen iguales. Por lo tanto, es
posible que se experimente una transferencia lenta si va a migrar una gran cantidad de
archivos pequeños. Este es un comportamiento esperado.
La razón de esta diferencia es la potencia de procesamiento necesaria para recorrer un

espacio de nombres. RoboCopy admite copias multiproceso mediante el parámetro
/MT:n , donde n indica el número de subprocesos que se van a usar. Por lo tanto, al
aprovisionar una máquina específicamente para RoboCopy, tenga en cuenta el número

de núcleos de procesador y su relación con el número de subprocesos que
proporcionan. Lo más habitual son dos subprocesos por núcleo. El número de núcleos y
subprocesos de una máquina es un punto de datos importante para determinar qué
valores multiproceso /MT:n se deberían especificar. Tenga en cuenta también cuántos
trabajos de RoboCopy tiene previsto ejecutar al mismo tiempo en una máquina
determinada.
Un número mayor de subprocesos copiarán nuestro ejemplo de 1 TiB de archivos

pequeños considerablemente más rápido que un número menor de subprocesos. Al
mismo tiempo, la inversión adicional en recursos en 1 TiB de archivos de más grandes
podría no aportar ventajas proporcionales. Un número mayor de subprocesos intentará
copiar simultáneamente más archivos grandes a través de la red. Esta actividad de red
adicional aumentará la probabilidad de sufrir restricciones asociadas al rendimiento o a
las operaciones de IOPS de almacenamiento.
Durante una primera ejecución de RoboCopy en un destino vacío o una ejecución

diferencial con una gran cantidad de archivos modificados, es probable que el
rendimiento de la red plantee restricciones. Comience con un número elevado de
subprocesos para una ejecución inicial. Un alto número de subprocesos, incluso más allá
de los subprocesos disponibles actualmente en la máquina, ayuda a saturar el ancho de
banda de red disponible. Las ejecuciones /MIR posteriores se verán afectadas
progresivamente por el procesamiento de elementos. Menos cambios en una ejecución
diferencial significa menos transporte de datos a través de la red. La velocidad ahora
depende más de la capacidad de procesar elementos de espacio de nombres que de
moverlos a través del vínculo de red. Para las ejecuciones posteriores, haga coincidir el
valor del número de subprocesos con el número de núcleos del procesador y el número
de subprocesos por núcleo. Considere si es necesario reservar los núcleos para otras
tareas que quizá tenga un servidor de producción.
 Sugerencia
Regla general: la primera ejecución de RoboCopy, que moverá una gran cantidad
de datos de una red de mayor latencia, se beneficia del aprovisionamiento excesivo
del número de subprocesos ( /MT:n ). Las ejecuciones posteriores copiarán menos
diferencias y es más probable que se cambie de un rendimiento restringido de red
a otro restringido por proceso. En estas circunstancias, a menudo es mejor que el
número de subprocesos de RoboCopy coincida con los subprocesos disponibles
realmente en la máquina. El aprovisionamiento excesivo en ese escenario puede
generar más cambios de contexto en el procesador, lo que podría ralentizar la
copia.
Evitar el trabajo innecesario

Evite cambios a gran escala en el espacio de nombres, como mover archivos entre
directorios, cambiar las propiedades a gran escala o cambiar los permisos de directorio
y de nivel de archivo (ACL de NTFS). Los cambios en la ACL en especial pueden tener
una importante repercusión, ya que con frecuencia tienen un efecto de cambio en
cascada en los archivos de nivel inferior en la jerarquía de carpetas. Entre las
consecuencias, cabe destacar las siguientes:
La ampliación del tiempo de ejecución del trabajo de RoboCopy, ya que será
necesario actualizar cada archivo y carpeta a los que afecte un cambio de ACL.
Es posible que haya que volver a copiar los datos que se migraron anteriormente.
Por ejemplo, habrá que copiar más datos si cambian las estructuras de carpetas,
aunque los archivos se hubieran copiado anteriormente. Un trabajo de RoboCopy
no puede "reproducir" un cambio del espacio de nombres. El siguiente trabajo
debe purgar los archivos transportados previamente en la estructura de carpetas
antigua y volver a cargar los archivos en la nueva estructura de carpetas.
Otro aspecto importante es usar la herramienta RoboCopy de forma eficaz. Con el script
de RoboCopy recomendado, se creará y guardará un archivo de registro de los errores.
Es normal que puedan producirse errores de copia. Estos errores suelen hacer que sea
necesario ejecutar varias rondas de una herramienta de copia como RoboCopy: una
ejecución inicial, por ejemplo, desde un NAS a DataBox o un servidor a un recurso
compartido de archivos de Azure, y una o varias ejecuciones adicionales con el
modificador /MIR para detectar y volver a intentar archivos que no se copiaron.
Debe estar preparado para ejecutar varias rondas de RoboCopy en el ámbito de un

espacio de nombres determinado. Las sucesivas ejecuciones finalizarán más rápido, ya
que tienen menos que copiar, pero cada vez tendrán más restricciones debido a la
velocidad de procesamiento del espacio de nombres. Cuando ejecute varias rondas,
puede acelerar cada una de ellas si evita que RoboCopy intente copiarlo todo en una
misma ejecución. Los siguientes modificadores RoboCopy pueden marcar una diferencia
importante:
/R:n n = la frecuencia con la que se vuelve a intentar copiar un archivo con errores
/W:n n = el número de segundos que hay que esperar entre reintentos
/R:5 /W:5 es un valor razonable que puede ajustar a su gusto. En este ejemplo, un
archivo con errores se intentará volver a copiar cinco veces, con un tiempo de espera de
cinco segundos entre un reintento y otro. Si el archivo sigue sin copiarse, el siguiente
trabajo de RoboCopy lo volverá a intentar. A menudo, los archivos que generan errores
por estar en uso o debido a problemas de tiempo de espera se pueden copiar
correctamente de esta manera.
Pasos siguientes
Los siguientes artículos le ayudarán a comprender las opciones avanzadas y los
procedimientos recomendados.

Información general acerca de la migración
Copia de seguridad: Instantáneas de recursos compartidos de archivos de Azure
Uso de Espacios de nombres DFS con Azure Files
Uso de DataBox para migrar desde un
almacenamiento conectado a la red
(NAS) a los recursos compartidos de
archivos de Azure
Artículo • 21/11/2023
Este artículo de migración es uno de varios que implican las palabras clave NAS y Azure
Data Box. Compruebe si este artículo se aplica a su escenario:
＂ Origen de datos: almacenamiento conectado a la red (NAS)

＂ Ruta de migración: NAS ⇒ DataBox ⇒ recurso compartido de archivos de Azure
＂ Sin almacenamiento en caché de archivos en el entorno local: dado que el objetivo
final es usar los recursos compartidos de archivos de Azure directamente en la
nube, no hay ningún plan para usar Azure File Sync.
Si el escenario es diferente, examine la tabla de guías de migración.
Este artículo le guía de forma detallada por el planeamiento, implementación y

configuración de las redes necesarias para migrar del dispositivo NAS a recursos
compartidos de archivos de Azure funcionales. En esta guía se usa Azure Data Box para
el transporte de datos masivo (transporte de datos sin conexión).
Se aplica a
El objetivo es migrar los recursos compartidos del dispositivo NAS a Azure y convertirlos
en recursos compartidos de archivos de Azure nativos. Puede usar estos recursos
compartidos sin necesidad de una instancia de Windows Server. Esta migración se debe
realizar de forma que garantice la integridad de los datos de producción y la
disponibilidad durante la migración. Esta última requiere que el tiempo de inactividad
sea mínimo, para ajustarse o solo superar ligeramente las ventanas de mantenimiento
regulares.

El proceso de migración consta de varias fases. Deberá implementar cuentas de
almacenamiento y recursos compartidos de archivos de Azure y configurar las redes. A
continuación, migrará los archivos mediante Azure DataBox y usará RoboCopy para
ponerse al día con los cambios. Por último, hará la transición de los usuarios y las
aplicaciones a los recursos compartidos de archivos de Azure recién creados. En las
secciones siguientes se describen detalladamente las fases del proceso de migración.
 Sugerencia
Si vuelve a este artículo, use la navegación del lado derecho para ir a la fase de
migración en la que se quedó.
Fase 1: Identificación de cuántos recursos

compartidos de archivos de Azure se necesitan
En este paso, establecerá cuántos recursos compartidos de archivos de Azure se
necesitan. Es posible que tenga más carpetas en los volúmenes que actualmente
comparte localmente como recursos compartidos de SMB en sus usuarios y
aplicaciones. En función del número de recursos compartidos de archivos que quiera
migrar a la nube, puede optar por usar una asignación 1:1 o una agrupación de recursos
compartidos.
Uso de una asignación 1:1

Si tiene un número suficientemente pequeño de recursos compartidos, se recomienda
una asignación 1:1. La manera más sencilla de visualizar este escenario es imaginar un
recurso compartido local que asigne 1:1 a un recurso compartido de archivos de Azure.
Uso de la agrupación de recursos compartidos

Si tiene una cantidad elevada de recursos compartidos de archivos, plantéese la
posibilidad de agrupar recursos compartidos. Por ejemplo, si el departamento de
RR. HH. tiene 15 recursos compartidos, podría considerar la posibilidad de almacenar
todos los datos de RR. HH. en un solo recurso compartido de archivos de Azure. De este
modo, solo se necesita un único recurso compartido de archivos de Azure en la nube
para este grupo de recursos compartidos locales.

En esta fase, aprovisionará las cuentas de almacenamiento de Azure y los recursos
compartidos de archivos que se encuentren en estas.
Recuerde que un recurso compartido de archivos de Azure se implementa en la nube en

una cuenta de almacenamiento de Azure. En el caso de los recursos compartidos de
archivos, esta disposición hace que la cuenta de almacenamiento sea un destino de
escalado para los números de rendimiento, como IOPS y rendimiento. Si coloca varios
recursos compartidos de archivos en una única cuenta de almacenamiento, está creando
un grupo compartido de IOPS y rendimiento para esos recursos compartidos.
Como regla general, puede agrupar varios recursos compartidos de archivos de Azure
en la misma cuenta de almacenamiento si tiene recursos compartidos de archivo o que
espera que tengan escasa actividad diaria. Sin embargo, si tiene recursos compartidos
muy activos (recursos compartidos usados por muchos usuarios o aplicaciones), es
conveniente implementar cuentas de almacenamiento con un recurso compartido de
archivos cada una. Estas limitaciones no se aplican a las cuentas de almacenamiento de
FileStorage (prémium), donde el rendimiento se aprovisiona y garantiza explícitamente
para cada recurso compartido.
７ Nota
de Azure. Con un aumento de cuota, podría crear hasta 500 cuentas de
almacenamiento por región. Para obtener más información, consulte Aumento de
las cuotas de la cuenta de Azure Storage.

redundancia. Consulte Redundancia de Azure Files.
Los recursos compartidos de archivos de Azure se crean con un límite de 5 TiB de

manera predeterminada. Si necesita más capacidad, puede crear un recurso compartido
de archivos grande (hasta 100 TiB). Sin embargo, ese recurso compartido solo puede las
opciones de redundancia de almacenamiento con redundancia local o de
almacenamiento con redundancia de zona. Tenga en cuenta sus necesidades de
redundancia de almacenamiento antes de usar recursos compartidos de archivos de
100 TiB.
compartido a la cuenta de almacenamiento en la que se creará.
homólogos locales.
Ahora, implemente el número adecuado de cuentas de almacenamiento de Azure con el

número adecuado de recursos compartidos de archivos de Azure en estas. Para ello,
siga las instrucciones de Creación de un recurso compartido de archivos SMB. En la
mayoría de los casos, se recomienda asegurarse de que la región de cada una de las
cuentas de almacenamiento es la misma.
Fase 3: Determinación del número de

dispositivos de Azure DataBox que necesita
Inicie este paso solo cuando haya completado la fase anterior. Los recursos de
almacenamiento de Azure Storage (cuentas de almacenamiento y recursos compartidos
de archivos) se deben crear en este momento. Durante el pedido de DataBox, debe
especificar a qué cuentas de almacenamiento se mueven los datos de DataBox.
En esta fase, debe asignar los resultados del plan de migración de la fase anterior a los
límites de las opciones de DataBox disponibles. Estas consideraciones le ayudarán a
crear un plan para las opciones de DataBox que debe elegir, así como cuántas
necesitará para mover los recursos compartidos de NAS a recursos compartidos de
archivos de Azure.
Para determinar el número de dispositivos que necesita de cada tipo, tenga en cuenta
estos límites importantes:
Cualquier instancia de Azure DataBox puede mover datos a un máximo de

10 cuentas de almacenamiento.
Cada opción de DataBox tiene su propia capacidad utilizable. Consulte Opciones
de DataBox.
Consulte el plan de migración para conocer el número de cuentas de almacenamiento
que ha decidido crear y los recursos compartidos en cada una de ellas. A continuación,
examine el tamaño de cada uno de los recursos compartidos de NAS. La combinación
de esta información le permitirá optimizar y decidir qué dispositivo debe enviar datos a
las cuentas de almacenamiento. Puede tener dos dispositivos de DataBox para trasladar
los archivos a la misma cuenta de almacenamiento, pero no divida el contenido de un
solo recurso compartido de archivos en dos instancias de DataBox.
Opciones de DataBox
Para una migración estándar, se debe elegir una combinación de estas dos opciones de
DataBox:
DataBox: esta es la opción más común. Se le enviará un dispositivo DataBox

resistente, que funciona de forma similar a un NAS. Tiene una capacidad utilizable
de 80 TiB. Para obtener más información, consulte la Documentación de DataBox.
DataBox Heavy: esta opción presenta un dispositivo DataBox resistente en ruedas,
que funciona de forma similar a un NAS, con una capacidad de 1 PiB. La capacidad
utilizable es aproximadamente un 20 % menos debido a la sobrecarga del sistema
de archivos y el cifrado. Para obtener más información, consulte la Documentación
de DataBox Heavy.
２ Advertencia
No se recomienda Data Box Disks para migraciones a recursos compartidos de

archivos de Azure. Data Box Disks no conserva los metadatos de archivo, como los
permisos de acceso (ACL) y otros atributos.
Fase 4: Aprovisionamiento de una instancia de

Windows Server temporal
Mientras espera a que lleguen los dispositivos Azure Data Box, ya puede implementar
una o varias instancias de Windows Server que necesitará para ejecutar trabajos de
RoboCopy.
Estos servidores se usarán primero para copiar los archivos en el dispositivo Data
Box.
Después, se usarán para ponerse al día con los cambios que se han producido en
el dispositivo NAS mientras el dispositivo Data Box estaba transportándose. Este
enfoque reduce al mínimo el tiempo de inactividad en el lado de origen.
La velocidad con la que funcionan los trabajos de RoboCopy depende principalmente
de los siguientes factores:

el ancho de banda de red disponible entre ellos
Puede encontrar más detalles en la sección de solución de problemas:
Consideraciones de IOPS y ancho de banda
la capacidad de procesar rápidamente archivos y carpetas en un espacio de
nombres
Busque más detalles en la sección de solución de problemas: Velocidad de
procesamiento
el número de cambios entre ejecuciones de RoboCopy
Puede encontrar más detalles en la sección de solución problemas: Evitación de
trabajo innecesario
Es importante tener en cuenta los detalles a los que se hace referencia al elegir la RAM y
el número de subprocesos que se proporcionarán a las instancias temporales de
Windows Server.
Fase 5: Preparación para el uso de recursos

Para ahorrar tiempo, debe continuar con esta fase mientras espera a que llegue el
dispositivo Data Box. Con la información de esta fase, podrá decidir cómo se habilitarán
los servidores y los usuarios dentro y fuera de Azure para usar los recursos compartidos
de archivos de Azure. Las decisiones más críticas son las siguientes:
Redes: habilite las redes para enrutar el tráfico SMB.

Autenticación: configure cuentas de almacenamiento de Azure para la
autenticación Kerberos. Unir su cuenta de almacenamiento a un dominio e
instancia de AD Connect permitirá que las aplicaciones y los usuarios usen su
identidad de AD para la autenticación
Autorización: las ACL de nivel de recurso compartido para cada recurso
compartido de archivos de Azure permitirán a los usuarios y grupos de AD acceder
a un recurso compartido determinado. Además, dentro de un recurso compartido
de archivos de Azure, las ACL nativas de NTFS asumirán el control. La autorización
basada en ACL de archivos y carpetas funciona del mismo modo que en los
recursos compartidos SMB locales.
Continuidad empresarial: la integración de recursos compartidos de archivos de
Azure en un entorno existente suele implicar la conservación de las direcciones de
recursos compartidos existentes. Si aún no está usando los espacios de nombres
DFS, considere la posibilidad de configurarlos en su entorno. De este modo, podría
conservar sin cambios las direcciones de recursos compartidos que usan los
usuarios y los scripts. DFS-N se usaría como servicio de enrutamiento de espacios
de nombres para SMB, ya que redirigiría los destinos de espacio de nombres DFS a
recursos compartidos de archivos de Azure después de la migración.
https://www.youtube-nocookie.com/embed/jd49W33DxkQ
Fase 6: Copia de archivos en el dispositivo Data

Box
Cuando llegue el dispositivo DataBox, deberá configurarlo con conectividad de red no
impedida a su dispositivo NAS. Siga la documentación de configuración del tipo de
DataBox que solicitó.
Configuración de Data Box

Configuración de Data Box Disk
Configuración de Data Box Heavy
En función del tipo de DataBox, puede que haya herramientas de copia de DataBox
disponibles. En este momento, no se recomiendan para las migraciones a recursos
compartidos de archivos de Azure, ya que no copian los archivos con plena fidelidad en
el dispositivo DataBox. En su lugar, use RoboCopy.
Cuando llegue el dispositivo DataBox, tendrá recursos compartidos de SMB

aprovisionados previamente disponibles para cada cuenta de almacenamiento que
especificó en el momento del pedido.
Si los archivos entran en un recurso compartido de archivos prémium de Azure,
habrá un recurso compartido de SMB por cuenta de almacenamiento de
"almacenamiento de archivos" prémium.
Si los archivos entran en una cuenta de almacenamiento estándar, habrá tres
recursos compartidos de SMB por cuenta de almacenamiento estándar (GPv1 y
GPv2). Solo los recursos compartidos de archivos que terminan con _AzFiles son
relevantes para la migración. Omita los recursos compartidos de blob en bloques y
en páginas.
Siga los pasos descritos en la documentación de Azure DataBox:
1. Conexión a un dispositivo Data Box

2. Copia de datos a un dispositivo Data Box
3. Preparación del dispositivo DataBox para su salida a Azure
La documentación vinculada de DataBox especifica un comando RoboCopy. Sin

embargo, el comando no es adecuado para conservar la fidelidad total de archivos y
carpetas. En su lugar, use este comando:
Consola
Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG:
<FilePathAndName> <SourcePath> <Dest.Path>
Para obtener más información acerca de los detalles de cada marca de RoboCopy,
consulte la tabla en sección de RoboCopy más adelante.
Para obtener más información acerca de cómo ajustar correctamente el número de
subprocesos /MT:n , optimizar la velocidad de RoboCopy y hacer que RoboCopy
funcione adecuadamente en el centro de datos, eche un vistazo a la sección de
solución de problemas de RoboCopy.
 Sugerencia
Como alternativa a Robocopy, Data Box ha creado un servicio de copia de datos.

Puede usar este servicio para cargar archivos en Data Box con plena fidelidad. Siga
este tutorial sobre el servicio de copia de datos y asegúrese de establecer el
destino correcto del recurso compartido de archivos de Azure.
Fase 7: Puesta al día de RoboCopy a partir del

NAS
Una vez que el dispositivo Data Box informe de que todos los archivos y carpetas se han
colocado en los recursos compartidos de archivos de Azure planeados, puede continuar
con esta fase. Un comando RoboCopy de puesta al día solo es necesario si es posible
que los datos del NAS hayan cambiado desde que se inició la copia de Data Box. En
algunos escenarios en los que se usa un recurso compartido con fines de archivado, es
posible que pueda detener los cambios en el recurso compartido del NAS hasta que se
complete la migración. También podría cumplir los requisitos de su empresa al
configurar recursos compartidos de NAS en modo solo lectura durante la migración.
En los casos en los que necesita que un recurso compartido sea de lectura y escritura
durante la migración y solo pueda permitirse un pequeño período de inactividad, será
importante que complete este paso de RoboCopy de puesta al día antes de la
conmutación por error del acceso del usuario directamente al recurso compartido de
archivos de Azure.
En este paso, ejecutará trabajos de RoboCopy para poner al día los recursos
compartidos en la nube con los cambios más recientes del NAS desde el momento en
que bifurcó los recursos compartidos en el dispositivo DataBox. Esta puesta al día de
RoboCopy puede finalizar rápidamente o tardar unos minutos en función de la cantidad
de abandonos que haya ocurrido en los recursos compartidos de NAS.
Ejecute la primera copia local en la carpeta de destino de Windows Server:
1. Identifique la primera ubicación en el dispositivo NAS.

2. Identifique el recurso compartido de archivos de Azure correspondiente.
3. Monte el recurso compartido de archivos de Azure como una unidad de red local
en la instancia temporal de Windows Server.
4. Inicie la copia con RoboCopy como se describió.
Montaje de un recurso compartido de archivos de Azure

Antes de que pueda usar RoboCopy, debe hacer que el recurso compartido de archivos
de Azure sea accesible a través de SMB. La manera más fácil consiste en montar el
recurso compartido como una unidad de red local en la instancia de Windows Server
que está planeando usar para RoboCopy.
） Importante
Antes de que pueda montar correctamente un recurso compartido de archivos de

Azure en una instancia local de Windows Server, debe haber completado la fase
Preparación para el uso de recursos compartidos de archivos de Azure.
Una vez listo, revise el artículo de procedimientos Uso de un recurso compartido de
archivos de Azure con Windows y monte el recurso compartido de archivos de Azure
para el que quiere iniciar el comando RoboCopy de puesta al día del NAS.
RoboCopy
El siguiente comando RoboCopy solo copiará las diferencias (archivos y carpetas
actualizados) desde el almacenamiento NAS al recurso compartido de archivos de
Azure.
Consola

<FilePathAndName>



escala.

destino.

Azure.






correctamente.


） Importante
 Sugerencia
Consulte la sección de solución de problemas si RoboCopy está afectando a su
entorno de producción, si notifica un gran número de errores o si no progresa tan
rápido como se espera.
Migración total de los usuarios

accediendo a los archivos en la ubicación de NAS y pueden modificarlos. Es posible que
RoboCopy haya procesado un directorio, pase al siguiente y, después, un usuario en la
ubicación de origen (NAS) agregue, cambie o elimine un archivo que no se procesará en
esta ejecución actual de RoboCopy. Este comportamiento es normal.
La primera ejecución consiste en migrar la mayor parte de los datos renovados al

recurso compartido de archivos de Azure. Esta primera copia puede tardar unos
minutos. Consulte la sección de solución de problemas para obtener más información
acerca de lo que puede afectar a la velocidad de RoboCopy.
La segunda vez que ejecute RoboCopy para el mismo recurso compartido se completará
más rápido, ya que solo necesita transportar los cambios posteriores a la última
Si considera que el tiempo de inactividad es aceptable, debe quitar el acceso de usuario

a los recursos compartidos basados en NAS. Para ello, siga los pasos que impidan que
los usuarios cambien el contenido y la estructura de archivos y carpetas. Un ejemplo es
dirigir DFS-Namespace a una ubicación no existente o cambiar las ACL raíz del recurso
compartido.
haberse omitido. El tiempo necesario para realizar este último paso dependerá de la
anterior.
Cree un recurso compartido en la carpeta de Windows Server y, eventualmente, ajuste

esta carpeta como destino de la implementación de DFS-N. Asegúrese de establecer los
mismos permisos de nivel de recurso compartido que en el recurso compartido de SMB
de NAS. Si tuviera un NAS unido a un dominio de clase empresarial, los SID de usuario
coincidirían automáticamente a medida que los usuarios se encuentren en
Active Directory y RoboCopy copia los archivos y metadatos con total fidelidad. Si ha
utilizado usuarios locales en la ubicación de NAS, debe volver a crearlos como usuarios
locales de Windows Server y asignar los SID existentes que RoboCopy ha transferido a la
instancia de Windows Server a los SID de los nuevos usuarios locales de
Windows Server.
Ha terminado de migrar un recurso compartido o un grupo de recursos compartidos a

un volumen o una raíz comunes.
Puede intentar ejecutar algunas de estas copias en paralelo. Se recomienda procesar el

ámbito de un recurso compartido de archivos de Azure a la vez.
de varios factores:

nombres.

IOPS.
transferencia.
Ｕ Precaución






determinada.


 Sugerencia
número de subprocesos de robocopy coincida con los subprocesos disponibles
copia.

Evite cambios a gran escala en el espacio de nombres. Por ejemplo, mover archivos
entre directorios, cambiar propiedades a gran escala o cambiar permisos (ACL de NTFS).
Los cambios en la ACL en especial pueden tener una importante repercusión, ya que
con frecuencia tienen un efecto de cambio en cascada en los archivos de nivel inferior
en la jerarquía de carpetas. Entre las consecuencias, cabe destacar las siguientes:

necesario ejecutar varias rondas de una herramienta de copia como RoboCopy. Una
ejecución inicial, por ejemplo, de un dispositivo NAS a DataBox o de un servidor a un
recurso compartido de archivos de Azure. Y una o varias ejecuciones adicionales con el
modificador /MIR para identificar los archivos que no se han copiado y volver a
intentarlo.

importante:

Pasos siguientes
Hay más información sobre los recursos compartidos de archivos de Azure. Los artículos
siguientes le ayudarán a comprender las opciones avanzadas, los procedimientos
recomendados y también contienen ayuda para la solución de problemas. Estos
artículos se vinculan a la documentación de recursos compartidos de archivos de Azure
según corresponda.

Supervisión, diagnóstico y solución de problemas de Microsoft Azure Storage
Consideraciones de red para el acceso directo
Copia de seguridad: Instantáneas de recursos compartidos de archivos de Azure
Migración desde Linux a una
implementación de nube híbrida con
Azure File Sync
Artículo • 23/03/2023
Este artículo de migración es uno de varios que implican las palabras clave NFS y Azure
File Sync. Compruebe si este artículo se aplica a su escenario:

＂ Ruta de migración: servidor Linux con Samba ⇒ Windows Server 2012R2 o
posterior ⇒ sincronización con recursos compartidos de archivos de Azure
＂ Almacenamiento en caché de archivos locales: sí, el objetivo final es una
Azure File Sync funciona en instancias de Windows Server con almacenamiento

conectado directamente (DAS). No admite la sincronización hacia y desde clientes Linux,
un recurso compartido de Bloque de mensajes del servidor (SMB) remoto o recursos
compartidos de Network File System (NFS).
Como resultado, la transformación de los servicios de archivo en una implementación

híbrida realiza una migración a una instancia de Windows Server necesaria. Este artículo
le guía a través del planeamiento y la ejecución de este tipo de migración.
Se aplica a
El objetivo es trasladar los recursos compartidos que tiene en el servidor Samba de
Linux a una instancia de Windows Server. Después, usará Azure File Sync para una
implementación de nube híbrida. Esta migración se debe realizar de forma que
garantice la integridad de los datos de producción y la disponibilidad durante la
migración. Esta última requiere que el tiempo de inactividad sea mínimo, para ajustarse
o solo superar ligeramente las ventanas de mantenimiento regulares.

Como se ha mencionado en el artículo de información general sobre la migración, de
Azure Files, es importante usar la herramienta de copia y el enfoque correctos. El
servidor Samba de Linux expone recursos compartidos de SMB directamente en la red
local. Robocopy, integrado en Windows Server, es la mejor manera de trasladar los
archivos en este escenario de migración.
Si no ejecuta Samba en el servidor de Linux y prefiere migrar carpetas a una

implementación híbrida en una instancia de Windows Server, puede usar las
herramientas de copia de Linux en lugar de RoboCopy. Tenga en cuenta las capacidades
de fidelidad de la herramienta de copia. Revise la sección de aspectos básicos de la
migración en el artículo Información general sobre la migración para obtener
información sobre lo que se debe buscar en una herramienta de copia.

necesitan. Una sola instancia de Windows Server (o clúster) puede sincronizar hasta
30 recursos compartidos de archivos de Azure.
Es posible que tenga más carpetas en los volúmenes que actualmente comparte
localmente como recursos compartidos de SMB en sus usuarios y aplicaciones. La
manera más sencilla de visualizar este escenario es imaginar un recurso compartido
local que asigne 1:1 a un recurso compartido de archivos de Azure. Si tiene un número
suficientemente pequeño de recursos compartidos, por debajo de 30 para una sola
instancia de Windows Server, se recomienda una asignación 1:1.
Si tiene más de 30 recursos compartidos, a menudo no es necesaria la asignación 1:1 de

recursos compartidos locales a un recurso compartido de archivos de Azure. Considere
las opciones siguientes.
Agrupación de recursos compartidos

Por ejemplo, si el departamento de RR. HH. tiene 15 recursos compartidos, podría
considerar la posibilidad de almacenar todos los datos de RR. HH. en un solo recurso
compartido de archivos de Azure. El almacenamiento de varios recursos compartidos
locales en un recurso compartido de archivos de Azure no evita que tenga que crear los
15 recursos compartidos de SMB habituales en la instancia local de Windows Server.
Solo significa que organiza las carpetas raíz de estos 15 recursos compartidos como
subcarpetas en una carpeta común. A continuación, sincronizará esta carpeta común
con un recurso compartido de archivos de Azure. De este modo, solo se necesita un
único recurso compartido de archivos de Azure en la nube para este grupo de recursos
compartidos locales.
Sincronización de volúmenes
Azure File Sync admite la sincronización de la raíz de un volumen con un recurso
compartido de archivos de Azure. Si sincroniza la raíz del volumen, todas las
subcarpetas y los archivos van al mismo recurso compartido de archivos de Azure.
La sincronización de la raíz del volumen no siempre es la mejor opción. La

sincronización de varias ubicaciones ofrece varias ventajas. Por ejemplo, ayuda a
disminuir el número de elementos por ámbito de sincronización. Probamos los recursos
compartidos de archivos de Azure y Azure File Sync con 100 millones de elementos
(archivos y carpetas) por recurso compartido. Pero un procedimiento es intentar
mantener el número por debajo de 20 o 30 millones en un solo recurso compartido. La
configuración de Azure File Sync con un número de elementos menor no solo es
beneficiosa para la sincronización de archivos. Un menor número de elementos también
beneficia a escenarios como estos:
El examen inicial del contenido de la nube puede realizarse más rápido, lo que a su
vez reduce la espera de que aparezca el espacio de nombres en un servidor
habilitado para Azure File Sync.
La restauración en la nube a partir de una instantánea de recursos compartidos de
archivos de Azure se hará con mayor rapidez.
La recuperación ante desastres de un servidor local puede acelerarse de forma
considerable.
Los cambios hechos directamente en un recurso compartido de archivos de Azure
(sin sincronización) se pueden detectar y sincronizar más rápido.
 Sugerencia
Si no está seguro de cuántos archivos y carpetas tiene, consulte la herramienta

TreeSize de JAM Software GmbH.
Un enfoque estructurado de una asignación de implementación
Antes de implementar el almacenamiento en la nube en un paso posterior, es
importante crear una asignación entre carpetas locales y recursos compartidos de
archivos de Azure. Esta asignación informará de cuántos recursos del grupo de
sincronización de Azure File Sync se van a aprovisionar y de cuáles van a ser. Un grupo
de sincronización está relacionado con el recurso compartido de archivos de Azure y la
carpeta de su servidor, y establece una conexión de sincronización.
Para decidir cuántos recursos compartidos de archivos de Azure necesita, revise los
límites y procedimientos recomendados siguientes. Eso le va a ayudar a optimizar la
asignación.
Un servidor donde está instalado el agente de Azure File Sync puede sincronizarse
con hasta 30 recursos compartidos de archivos de Azure.
Un recurso compartido de archivos de Azure se implementa en una cuenta de

almacenamiento. Esta disposición hace que la cuenta de almacenamiento sea un
destino de escalado para los números de rendimiento, como IOPS y rendimiento.
Preste atención a las limitaciones de IOPS de una cuenta de almacenamiento al

recursos compartidos de archivos 1:1 con cuentas de almacenamiento. Pero quizás
no sea posible debido a diversos límites y restricciones, tanto de su organización
como de Azure. Cuando no sea posible tener un solo recurso compartido de
archivos implementado en una cuenta de almacenamiento, tenga en cuenta qué
recursos compartidos estarán muy activos y cuales estarán menos activos, con el
fin de asegurarse de que los recursos compartidos de archivos más activos no se
colocan en la misma cuenta de almacenamiento.
Si tiene previsto mover una aplicación a Azure que usará el recurso compartido de
archivos de Azure de forma nativa, es posible que necesite un mayor rendimiento
del recurso compartido de archivos de Azure. Si este tipo de uso es una
posibilidad, incluso en el futuro, lo mejor es crear un único recurso compartido de
archivos de Azure estándar en su propia cuenta de almacenamiento.
de Azure.
 Sugerencia
Teniendo en cuenta esta información, suele ser necesario agrupar varias carpetas
de nivel superior de sus volúmenes en un nuevo directorio raíz común. Luego se
sincroniza este nuevo directorio raíz y todas las carpetas agrupadas en él, en un
solo recurso compartido de archivos de Azure. Esta técnica permite permanecer
dentro del límite de 30 sincronizaciones de recursos compartidos de archivos de
Azure por servidor.
Esta agrupación bajo una raíz común no afecta al acceso a sus datos. Las ACL se
mantienen como están. Solo tiene que ajustar algunas rutas de acceso a los
recursos compartidos (como las de los recursos compartidos SMB o NFS) que
podría haber en las carpetas de servidor locales que ahora han cambiado a una raíz
común. No cambia nada más.
） Importante
El vector de escala más importante para Azure File Sync es el número de elementos
(archivos y carpetas) que tienen que sincronizarse. Para más información, revise los
objetivos de escala de Azure File Sync.
Se recomienda mantener bajo el número de elementos por ámbito de sincronización.

Ese es un factor importante que se debe tener en cuenta en la asignación de carpetas a
recursos compartidos de archivos de Azure. Azure File Sync se prueba con 100 millones
elementos (archivos y carpetas) por recurso compartido. Pero a menudo es mejor
mantener el número de elementos por debajo de 20 o 30 millones en un solo recurso
compartido. Divida el espacio de nombres en varios recursos compartidos si empieza a
superar estos números. Puede seguir agrupando varios recursos compartidos locales en
el mismo recurso compartido de archivos de Azure, siempre y cuando se mantenga
aproximadamente por debajo de estos números. Esto le proporcionará más espacio
para crecer.
En una situación tal, es posible que un conjunto de carpetas pueda sincronizarse de

forma lógica con el mismo recurso compartido de archivos de Azure (mediante el nuevo
enfoque de carpeta raíz común mencionado anteriormente). Pero puede que siga
siendo mejor reagrupar carpetas de modo que se sincronicen con dos recursos
compartidos de archivos de Azure en lugar de uno. Puede usar este enfoque para
mantener equilibrado el número de archivos y carpetas por recurso compartido de
archivos en el servidor. También puede dividir los recursos compartidos locales y
sincronizarlos entre más servidores locales, lo que agrega la posibilidad de sincronizar
30 recursos compartidos de archivos de Azure más por cada servidor adicional.
Escenarios y consideraciones comunes de sincronización de

archivos
# Escenario de Compatible Consideraciones Solución (o solución alternativa)
sincronización (o limitaciones)
1 Servidor de No Un recurso 1) Comience con la sincronización de

archivos con compartido de un disco (su volumen raíz) para el
varios discos o archivos de recurso compartido de archivos de
volúmenes y Azure de destino Azure de destino. Empezar con el disco
varios recursos (punto de o volumen más grande, ayudará con
compartidos en conexión en la los requisitos de almacenamiento
el mismo nube) solo locales. Configure la nube por niveles
recurso admite la para organizar en capas todos los
compartido de sincronización datos en la nube, lo que libera espacio
archivos de con un grupo de en el disco del servidor de archivos.
Azure de destino sincronización. Mueva datos de otros volúmenes o
(consolidación) recursos compartidos al volumen
Un grupo de actual que se está sincronizando.
sincronización Continúe los pasos uno por uno hasta
solo admite un que todos los datos estén en capas en
punto de la nube o migrados.
conexión de 2) Tenga un solo volumen raíz (disco)
servidor por como destino a la vez. Use la nube por
servidor niveles para organizar en capas todos
registrado. los datos para tener como destino el
Azure. Quite el punto de conexión de
servidor del grupo de sincronización,
vuelva a crear el punto de conexión
con el siguiente volumen o disco raíz,
sincronice y repita el proceso. Nota: Es
posible que sea necesario volver a
instalar el agente.
3) Se recomienda usar varios recursos
compartidos de archivos de Azure de
destino (misma o diferente cuenta de
almacenamiento en función de los
requisitos de rendimiento)
2 Servidor de Sí No se pueden Sincronice la raíz del volumen que

archivos con un tener varios contiene varios recursos compartidos o
único volumen y puntos de carpetas de nivel superior. Consulte
varios recursos conexión de Concepto de agrupación de recursos
compartidos en servidor por compartidos y Sincronización de
el mismo servidor volúmenes para obtener más
recurso registrado que información.
compartido de se sincronicen
archivos de con el mismo
Azure de destino recurso
(consolidación) compartido de
archivos de
Azure de destino
(igual que
anteriormente)
3 Servidor de Sí Una sola 1) Use varios grupos de sincronización

archivos con instancia de (número de grupos de sincronización =
varios recursos Windows Server número de recursos compartidos de
compartidos o (o clúster) puede archivos de Azure con los que
volúmenes en sincronizar hasta sincronizar).
varios recursos 30 recursos 2) Solo se pueden sincronizar 30
compartidos de compartidos de recursos compartidos en este escenario
archivos de archivos de a la vez. Si tiene más de 30 recursos
Azure en una Azure. compartidos en ese servidor de
sola cuenta de archivos, use el concepto de
almacenamiento Una cuenta de agrupación de recursos compartidos y
(asignación de almacenamiento la sincronización de volúmenes para
recursos es un destino de reducir el número de carpetas raíz o de
compartidos de escalado para el nivel superior en el origen.
1:1) rendimiento. 3) Use servidores File Sync adicionales
IOPS y el locales y divida o mueva datos a estos
rendimiento se servidores para solucionar las
comparten entre limitaciones del servidor Windows de
recursos origen.
compartidos de
archivos.
Mantenga el
número de
elementos por
grupo de
sincronización
por debajo de
100 millones de
elementos
(archivos y
carpetas) por
recurso
compartido.
Idealmente, es
mejor
permanecer por
debajo de 20 o
30 millones por
recurso
compartido.
4 Servidor de Sí Una sola El mismo enfoque que más arriba

archivos con instancia de
varios recursos Windows Server
compartidos o (o clúster) puede
volúmenes en sincronizar hasta
varios recursos 30 recursos
compartidos de compartidos de
archivos de archivos de
Azure en una Azure (la misma
cuenta de cuenta de
almacenamiento almacenamiento
diferente o una diferente).
(asignación de
recursos Mantenga el
compartidos de número de
1:1) elementos por
grupo de
sincronización
por debajo de
100 millones de
elementos
(archivos y
carpetas) por
recurso
compartido.
Idealmente, es
mejor
permanecer por
debajo de 20 o
30 millones por
recurso
compartido.
5 Varios servidores No Un grupo de Siga las instrucciones del escenario n.º 1

de archivos con sincronización anterior con una consideración
un único no puede usar el adicional sobre tener un único servidor
(volumen raíz o punto de de archivos como destino a la vez.
recurso conexión en la
compartido) en nube (recurso
el mismo compartido de
recurso archivos de
compartido de Azure) ya
archivos de configurado en
Azure de destino otro grupo de
(consolidación) sincronización.
Aunque un
grupo de
sincronización
puede tener
puntos de
conexión de
servidor en
distintos
servidores de
archivos, los
archivos no
pueden ser
distintos.
Creación de una tabla de asignación


Use la información anterior para decidir cuántos recursos compartidos de archivos de

Azure necesita, y qué partes de los datos existentes terminarán en cuál recurso
Cree una tabla para registrar sus ideas, de modo que pueda consultarla cuando sea
necesario. La organización es importante, ya que puede ser fácil perder detalles del plan
de asignación cuando se aprovisionan muchos recursos de Azure a la vez. Descargue el
siguiente archivo de Excel para usarlo como plantilla para ayudar a crear la asignación.
Descargue una plantilla de asignación de espacios de nombres.

Windows Server adecuada en el entorno local
Cree una instancia de Windows Server 2019 como una máquina virtual o un
servidor físico. El requisito mínimo es Windows Server 2012 R2. También se admite
un clúster de conmutación por error de Windows Server.
Aprovisione o agregue almacenamiento de conexión directa (DAS). No se admite

el almacenamiento conectado a la red (NAS).
La cantidad de almacenamiento que aprovisione puede ser menor que la que usa
actualmente en el servidor Samba de Linux, si usa la característica de nube por
niveles de Azure File Sync.
actualmente en el servidor Samba de Linux. Esta opción de configuración requiere que
use también la característica de nube por niveles de Azure File Sync. Sin embargo,
cuando en una fase posterior copie los archivos del espacio del servidor Samba de Linux
más grande al volumen más pequeño de Windows Server, tendrá que trabajar en lotes:
1. Mueva un conjunto de archivos que quepa en el disco.

2. Deje que la sincronización de archivos y la nube por niveles interactúen.
3. Cuando se cree más espacio disponible en el volumen, continúe con el siguiente
lote de archivos. También puede revisar el comando RoboCopy en la próxima
sección RoboCopy para usar el nuevo modificador /LFSM . El uso de /LFSM puede
simplificar significativamente los trabajos de RoboCopy, pero no es compatible con
otros modificadores de RoboCopy de los que podría depender.
Puede evitar este enfoque de procesamiento por lotes si aprovisiona el espacio

equivalente en la instancia de Windows Server que ocupan los archivos en el servidor
Samba de Linux. Considere la posibilidad de habilitar la desduplicación en Windows. Si
no quiere confirmar de manera permanente esta gran cantidad de almacenamiento en
la instancia de Windows Server, puede reducir el tamaño del volumen después de la
migración y antes de ajustar las directivas de nube por niveles. Esto crea una caché local
más pequeña de los recursos compartidos de archivos de Azure.
La configuración de recursos (de proceso y RAM) de la instancia de Windows Server que

implemente depende principalmente del número de elementos (archivos y carpetas)
que se van a sincronizar. Se recomienda trabajar con una configuración de rendimiento
más alto si tiene problemas.
Aprenda a cambiar el tamaño de una instancia de Windows Server según el número de

elementos (archivos y carpetas) que necesite sincronizar.
７ Nota
El artículo vinculado anteriormente presenta una tabla con un intervalo de memoria

del servidor (RAM). Puede orientarse hacia el número más pequeño para el
servidor, pero espere que la sincronización inicial tarde mucho más.
Fase 3: Implementación del recurso de nube de
Azure File Sync
Para completar este paso, necesita las credenciales de la suscripción a Azure.
El recurso principal para configurar Azure File Sync se denomina servicio de

sincronización de almacenamiento. Se recomienda implementar solo uno para todos los
servidores que sincronizan el mismo conjunto de archivos ahora o en el futuro. Solo
debe crear varios servicios de sincronización de almacenamiento si tiene distintos
conjuntos de servidores que nunca deben intercambiar datos. Por ejemplo, podría tener
servidores que nunca deben sincronizar el mismo recurso compartido de archivos de
Azure. De lo contrario, el procedimiento recomendado es contar con un único servicio
de sincronización de almacenamiento.
Elija una región de Azure para el servicio de sincronización de almacenamiento que esté
cerca de su ubicación. Todos los demás recursos de nube se deben implementar en la
misma región. Para simplificar el proceso de administración, cree un nuevo grupo de
recursos en la suscripción para hospedar los recursos de sincronización y
almacenamiento.
Para más información, consulte la sección sobre la implementación del servicio de

sincronización de almacenamiento en el artículo sobre la implementación de Azure File
Sync. Siga solo esta sección del artículo. En pasos posteriores, tendrá vínculos a otras
secciones del artículo.

En esta fase, consulte la tabla de asignación de la fase 1 y úsela para aprovisionar el
número correcto de cuentas de almacenamiento de Azure y recursos compartidos de
archivos que contienen.
Un recurso compartido de archivos de Azure en la nube en una cuenta de

almacenamiento de Azure. Aquí se aplica otro nivel de consideraciones relativas al
rendimiento.
Si tiene recursos compartidos muy activos (recursos compartidos que usan muchos
usuarios o aplicaciones), dos recursos compartidos de archivos de Azure podrían
alcanzar el límite de rendimiento de una cuenta de almacenamiento.
Un procedimiento recomendado es implementar cuentas de almacenamiento con un
recurso compartido de archivos cada una. Puede agrupar varios recursos compartidos
de archivos de Azure en la misma cuenta de almacenamiento si tiene recursos
compartidos de archivo o que espera que tengan escasa actividad diaria.
Estas consideraciones se aplican más al acceso directo a la nube (a través de una VM de

Azure) que a Azure File Sync. Si tiene pensado usar solo Azure File Sync en estos
recursos compartidos, es correcta la agrupación de varios en una sola cuenta de
almacenamiento de Azure.
compartido a la cuenta de almacenamiento en la que se encontrará.
En la fase anterior, estableció el número adecuado de recursos compartidos. En este

paso, tiene una asignación de cuentas de almacenamiento a recursos compartidos de
archivos. Ahora debe implementar el número adecuado de cuentas de almacenamiento
de Azure con el número adecuado de recursos compartidos de archivos de Azure en
ellas.
Asegúrese de que la región de cada una de las cuentas de almacenamiento sea la

misma y coincida con la región del recurso del servicio de sincronización de
almacenamiento que ya ha implementado.
Ｕ Precaución
Si crea un recurso compartido de archivos de Azure con un límite de 100 TiB, ese
recurso compartido puede usar solo las opciones de redundancia de
almacenamiento con redundancia local o de zona. Tenga en cuenta sus
necesidades de redundancia de almacenamiento antes de usar recursos
compartidos de archivos de 100 TiB.
Los recursos compartidos de archivos de Azure todavía se crean con un límite de 5 TiB
de forma predeterminada. Para crear un recurso compartido de archivos grande, siga los
pasos de Creación de un recurso compartido de archivos de Azure.

redundancia de Azure Storage. Consulte las Opciones de redundancia de Azure Storage.
homólogos locales.
Fase 5: Implementar el agente de Azure File

Sync
En esta sección se instala el agente de Azure File Sync en una instancia de
Windows Server.
En la guía de implementación se explica que es preciso desactivar la configuración de

seguridad mejorada de Internet Explorer. Esta medida de seguridad no se puede
aplicar con Azure File Sync. Si la desactiva, puede autenticarse en Azure sin ningún
problema.
Abra PowerShell. Instale los módulos de PowerShell necesarios mediante los siguientes
comandos. Asegúrese de instalar el módulo completo y el proveedor de NuGet cuando
se le solicite hacerlo.
PowerShell
Install-Module -Name Az -AllowClobber

Install-Module -Name Az.StorageSync
Si tiene algún problema para conectarse a Internet desde el servidor, ahora es el

momento de solucionarlo. Azure File Sync usa cualquier conexión de red disponible a
Internet. También se admite la exigencia de un servidor proxy para tener acceso a
Internet. Ya puede configurar un proxy en toda la máquina, o bien, durante la instalación
del agente, especificar un proxy que solo va a usar Azure File Sync.
Si para configurar un proxy debe abrir los firewalls del servidor, es posible que ese
enfoque le resulte aceptable. Al final de la instalación del servidor, después de haber
completado el registro del servidor, un informe de conectividad de red le mostrará las
direcciones URL exactas de los puntos de conexión en Azure, con las que Azure File Sync
necesita comunicarse en la región que ha seleccionado. El informe también indica por
qué se necesita la comunicación. Puede usar el informe para bloquear los firewalls del
servidor en direcciones URL específicas.
También puede adoptar un enfoque más conservador y no abrir totalmente los firewalls.
En su lugar puede limitar el servidor para que se comunique con espacios de nombres
DNS de nivel superior. Para más información, consulte Configuración del proxy y el
firewall de Azure File Sync. Siga sus propios procedimientos recomendados de redes.
Al final del Asistente para la instalación del servidor, se abrirá un Asistente para el
registro del servidor. Registre el servidor en el recurso de Azure del servicio de
sincronización de almacenamiento anterior.
Estos pasos se describen con más detalle en la guía de implementación, que incluye los
módulos de PowerShell que se deben instalar primero: Instalación de agente de Azure
File Sync.
Use el agente más reciente. Puede descargarlo del Centro de descarga de Microsoft:
Agente de Azure File Sync .
Después de una instalación y un registro del servidor correctos, puede confirmar que ha
completado correctamente este paso. Vaya al recurso de Storage Sync Service en Azure
Portal. En el menú de la izquierda, vaya a Servidores registrados. Verá que el servidor
aparece en esa lista.
Fase 6: Configurar Azure File Sync en la

implementación de Windows Server
La instancia registrada de Windows Server local debe estar preparada y conectada a
Internet para este proceso.
Este paso une todos los recursos y carpetas que ha configurado en la instancia de
Windows Server durante los pasos anteriores.

2. Busque el recurso del servicio de sincronización de almacenamiento.
3. Cree un nuevo grupo de sincronización en el recurso del servicio de sincronización
de almacenamiento para cada recurso compartido de archivos de Azure. En la
terminología de Azure File Sync, el recurso compartido de archivos de Azure se
convertirá en punto de conexión de la nube en la topología de sincronización que
describe con la creación de un grupo de sincronización. Cuando cree el grupo de
sincronización, asígnele un nombre descriptivo para poder reconocer qué conjunto
de archivos se sincroniza allí. Asegúrese de hacer referencia al recurso compartido
de archivos de Azure con un nombre coincidente.
4. Después de haber creado el grupo de sincronización, aparecerá una fila para él en
la lista de grupos de sincronización. Seleccione el nombre (un vínculo) para
mostrar el contenido del grupo de sincronización. Verá el recurso compartido de
archivos de Azure en Puntos de conexión en la nube.
5. Busque el botón Agregar punto de conexión de servidor. La carpeta del servidor
local que ha aprovisionado se convertirá en la ruta de acceso de este punto de
conexión del servidor.
） Importante
La nube por niveles es la característica de Azure File Sync que permite al servidor
local tener menos capacidad de almacenamiento de la que está almacenada en la
nube y, a pesar de ello, disponer de todo el espacio de nombres. Los datos de
interés local también se almacenan en caché para conseguir un rendimiento de
acceso rápido. La nube por niveles es una característica opcional de cada punto de
conexión de servidor de Azure File Sync.
２ Advertencia
Si ha aprovisionado menos almacenamiento en los volúmenes de Windows Server

que los datos usados en el servidor Samba de Linux, la nube por niveles es
obligatoria. Si no activa la nube por niveles, el servidor no liberará espacio para
almacenar todos los archivos. De forma temporal para realizar la migración,
establezca la directiva de almacenamiento por niveles en el 99 % de espacio
disponible en el volumen. Asegúrese de volver a la configuración de nube por
niveles una vez que se haya completado la migración y establezca la directiva en un
nivel más útil a largo plazo.
Repita los pasos de creación de grupos de sincronización y adición de la carpeta de

servidor correspondiente como un punto de conexión de servidor para todos los
recursos compartidos de archivos de Azure y las ubicaciones del servidor, que deban
configurarse para la sincronización.
Después de crear todos los puntos de conexión de servidor, la sincronización funciona.

Puede crear un archivo de prueba y ver que se sincroniza desde la ubicación del servidor
con el recurso compartido de archivos de Azure conectado (como se describe en el
punto de conexión en la nube del grupo de sincronización).
En ambas ubicaciones, las carpetas del servidor y los recursos compartidos de archivos
de Azure están vacíos y a la espera de datos. En el paso siguiente, comenzará a copiar
archivos a la instancia de Windows Server para que Azure File Sync los transfiera a la
nube. Si habilitó la nube por niveles, el servidor comenzará a organizar los archivos en
niveles si se queda sin capacidad en los volúmenes locales.
Fase 7: Robocopy
El enfoque de migración básico es usar Robocopy para copiar archivos y usar Azure File
Sync para realizar la sincronización.
1. Identifique la primera ubicación en el servidor Samba de Linux.

2. Identifique la carpeta coincidente en la instancia de Windows Server, que ya tiene
Azure File Sync configurado.
3. Inicie la copia con Robocopy.
El comando de Robocopy siguiente copiará los archivos desde el almacenamiento de los

servidores Samba de Linux a la carpeta de destino de la instancia de Windows Server.
Windows Server los sincronizará con los recursos compartidos de archivos de Azure.
Si ha aprovisionado menos almacenamiento en la instancia de Windows Server que el

que ocupan los archivos en el servidor Samba de Linux, ha configurado la nube por
niveles. A medida que el volumen local de Windows Server se llena, la nube por niveles
se iniciará y organizará por niveles los archivos que ya se han sincronizado
correctamente. La nube por niveles generará espacio suficiente para continuar con la
copia desde el servidor Samba de Linux. La nube por niveles realiza comprobaciones
cada hora para averiguar qué se ha sincronizado y para liberar espacio en disco para
alcanzar la directiva del 99 % de espacio libre para un volumen.
Es posible que Robocopy mueva los archivos más rápido de lo que se pueden
sincronizar con la nube y los organice por niveles de manera local, lo que hará que se
quede sin espacio en el disco local. Robocopy generará un error. Se recomienda trabajar
con los recursos compartidos en una secuencia que evite este problema. Por ejemplo,
considere la posibilidad de no iniciar trabajos de Robocopy en todos los recursos
compartidos al mismo tiempo. O bien considere la posibilidad de mover los recursos
compartidos que se ajustan a la cantidad actual de espacio libre en la instancia de
Windows Server. Si se produce un error en el trabajo de Robocopy, puede volver a
ejecutar el comando siempre que use la opción de reflejo/purga siguiente:
Consola

<FilePathAndName>
/MT:n Permite que Robocopy se ejecute en modo multiproceso. El valor predeterminado

para n es 8. La cantidad máxima es de 128 subprocesos. Aunque un número
elevado de subprocesos contribuye a saturar el ancho de banda disponible, no
significa que la migración sea siempre más rápida con más subprocesos. Las
pruebas realizadas con Azure Files indican que entre 8 y 20 proporcionan un
rendimiento equilibrado para la ejecución de una copia inicial. Las ejecuciones
subsiguientes de /MIR se ven afectadas progresivamente por el proceso
disponible en comparación con el ancho de banda de red disponible. Para las
ejecuciones posteriores, haga coincidir más estrechamente el valor del número de
subprocesos con el número de núcleos del procesador y el número de
subprocesos por núcleo. Considere si es necesario reservar los núcleos para otras
tareas que quizá tenga un servidor de producción. Las pruebas realizadas con
Azure Files han demostrado que, con un máximo de 64 subprocesos, se obtiene
un buen rendimiento, pero solo si los procesadores pueden mantenerlos activos
al mismo tiempo.

segundos más tarde puede no ser suficiente tiempo para que cambie el estado de
“en uso” del archivo. Es posible que los usuarios o aplicaciones que tienen abierto
el archivo necesiten más tiempo. En este caso, puede que, si acepta que el archivo
no se ha copiado y lo incluye en una ejecución posterior planeada de Robocopy,
el archivo se copie finalmente. Esto ayuda a que la ejecución en curso finalice más
rápido al no prolongarla con muchos reintentos que, al final, dan lugar a una
mayoría de errores de copia porque los archivos siguen abiertos después del
tiempo de espera de reintento.
/W:n Especifica el tiempo que espera Robocopy antes de intentar copiar un archivo que
no se ha copiado correctamente en el último intento. n es el número de

purgarán (se eliminarán) del destino. Cuando use este conmutador, haga coincidir
exactamente con las estructuras de carpetas de origen y de destino. Coincidencia
significa que se copia desde el nivel de carpeta y origen correctos en el nivel de
carpeta del destino coincidente. Solo entonces se puede realizar correctamente
una copia de "puesta al día". Cuando el origen y el destino no coinciden, el uso de
/MIR dará lugar a eliminaciones y nuevas copias a gran escala.

destino.

Azure.





/L Solo para una serie de pruebas Los archivos solo se muestran en la lista. No se
copiarán, no se eliminarán y no tendrán marca de tiempo. Por lo general, se usa
con /TEE para la salida de la consola. Es posible que las marcas del script de
ejemplo, como /NP , /NFL y /NDL , se tengan que quitar para lograr los resultados
de la prueba documentados correctamente.
/LFSM Solo para destinos con almacenamiento en niveles. No se admite cuando el

destino sea un recurso compartido de SMB remoto.
Especifica que Robocopy funciona en "modo de espacio libre bajo". Este
modificador solo es útil para los destinos con almacenamiento en niveles que
podrían quedarse sin capacidad local antes de que finalice Robocopy. Se agregó
específicamente para su uso con un destino habilitado de nube por niveles de
Azure File Sync. Se puede usar con independencia de Azure File Sync. En este
modo, Robocopy se pondrá en pausa siempre que una copia de archivo haga que
el espacio disponible del volumen de destino se sitúe por debajo de un valor de
"suelo". El formato /LFSM:n de la marca puede especificar este valor. El parámetro
n se especifica en la base 2: nKB , nMB o nGB . Si /LFSM se especifica sin ningún
valor floor explícito, floor se establece en el 10 por ciento del tamaño del volumen
de destino. El modo de espacio libre bajo no es compatible con /MT , /EFSRAW ni
/ZB . Se agregó compatibilidad con /B en Windows Server 2022. Consulte la
sección Windows Server 2022 y RoboCopy LFSM a continuación para obtener más
información, incluidos detalles sobre un error y una solución alternativa
relacionados.
/Z Usar con precauciónCopia los archivos en modo de reinicio. Este conmutador

solo se recomienda en un entorno de red inestable. Reduce significativamente el
rendimiento de la copia debido al registro adicional.
/ZB Usar con precauciónUsa el modo de reinicio. Si se deniega el acceso, esta opción
utiliza el modo de copia de seguridad. Esta opción reduce significativamente el
rendimiento de la copia debido a los puntos de control.
） Importante

Al ejecutar por primera vez el comando Robocopy, los usuarios y las aplicaciones siguen
accediendo a los archivos en el servidor Samba de Linux y pueden modificarlos. Es
posible que Robocopy haya procesado un directorio, pase al siguiente y, después, un
usuario en la ubicación de origen (Linux) agregue, cambie o elimine un archivo que no
se procesará en esta ejecución actual de Robocopy. Este comportamiento es normal.
La primera ejecución consiste en mover la mayor parte de los datos a la instancia de

Windows Server y, después, a la nube a través de Azure File Sync. Esta primera copia
puede tardar mucho tiempo, en función de lo siguiente:
El ancho de banda de descarga.

El ancho de banda de carga.
La velocidad de la red local y el número de subprocesos de Robocopy que
coincidan de forma óptima con ella.
El número de elementos (archivos y carpetas) que deben procesar Robocopy y
Azure File Sync.
La segunda vez se completará más rápido, ya que solo necesita transportar los cambios
posteriores a la última ejecución. Durante esta segunda ejecución, de todos modos se
pueden acumular cambios nuevos.
Repita este proceso hasta que considere que el tiempo que tarda en completarse una
operación de Robocopy para una ubicación concreta se encuentra dentro una ventana
de inactividad aceptable.
Cuando considere que el tiempo de inactividad es aceptable y esté preparado para dejar
sin conexión la ubicación de Linux, puede cambiar las ACL en la raíz del recurso
compartido para que los usuarios ya no puedan acceder a la ubicación. También puede
realizar cualquier otro paso adecuado que impida que el contenido cambie en esta
carpeta en el servidor Linux.
Ejecute una última ronda de Robocopy. Recuperará todos los cambios que puedan
velocidad del análisis de Robocopy. Para realizar un cálculo estimado del tiempo (que
anterior.

del servidor Samba de Linux. Si ha usado usuarios locales en el servidor Samba de Linux,
debe volver a crearlos como usuarios locales de Windows Server. También debe asignar
los SID existentes que Robocopy ha migrado a su instancia de Windows Server a los SID
de los usuarios locales nuevos de Windows Server. Si ha usado cuentas y ACL de
Active Directory, Robocopy las transferirá tal cual y no es necesario realizar ninguna otra
acción.
Terminó de migrar un recurso compartido o un grupo de recursos compartidos a una

raíz o un volumen común (en función de la asignación de la fase 1).

２ Advertencia
Una vez que haya migrado todos los datos del servidor Samba de Linux a la
instancia de Windows Server y se haya completado la migración, vuelva a todos los
grupos de sincronización de Azure Portal. Ajuste el porcentaje de espacio
disponible para el volumen de nube por niveles a un número más adecuado para el
uso de la memoria caché, como el 20 por ciento.
La directiva de espacio libre en el volumen de la nube por niveles actúa en un nivel de

volumen desde el que se pueden sincronizar varios puntos de conexión de servidor. Si
olvida ajustar el espacio disponible en un punto de conexión del servidor, la
sincronización seguirá aplicando la regla más restrictiva e intentará mantener un 99 %
de espacio libre en disco. Esto hará que la caché local no funcione según lo previsto. El
rendimiento puede ser aceptable si el objetivo es tener el espacio de nombres de un
volumen que contenga solo datos de archivo de acceso menos frecuente y se está
reservando el resto del espacio de almacenamiento para otro escenario.
El problema más común es que el comando de Robocopy genere el error de Volumen
lleno en el lado de Windows Server. La nube por niveles actúa una vez cada hora para
evacuar el contenido del disco local de Windows Server, que se ha sincronizado. Su
objetivo es alcanzar un espacio libre del 99 por ciento en el volumen.
Permita que el progreso de la sincronización y la nube por niveles liberen espacio en

disco. Puede observarlo en el Explorador de archivos en Windows Server.
Cuando la instancia de Windows Server tenga capacidad suficiente disponible, el

problema se resolverá al volver a ejecutar el comando. Si se da esta situación, no se
interrumpe nada y puede avanzar con confianza. La única consecuencia es el
inconveniente de tener que volver a ejecutar el comando.
Consulte el vínculo de la sección siguiente para solucionar problemas de Azure File Sync.
Pasos siguientes
Hay más información sobre los recursos compartidos de archivos de Azure y Azure File
Sync. Los artículos siguientes contienen opciones avanzadas, procedimientos
recomendados y ayuda para la solución de problemas. Estos artículos se vinculan a la
documentación de recursos compartidos de archivos de Azure según corresponda.
Introducción a Azure File Sync

Migración desde un almacenamiento
conectado a la red (NAS) a una
implementación de nube híbrida con
Azure File Sync
Artículo • 28/03/2023
Este artículo de migración es uno de varios que implican las palabras clave NAS y Azure
File Sync. Compruebe si este artículo se aplica a su escenario:

＂ Ruta de migración: NAS ⇒ Windows Server ⇒ Carga y sincronización con recursos
Azure File Sync funciona en ubicaciones de almacenamiento de conexión directa (DAS) y

no admite la sincronización con ubicaciones de almacenamiento conectado a la red
(NAS). Es por esto que resulta necesario migrar los archivos y en este artículo encontrará
una guía para planear y ejecutar dicha migración.
Se aplica a
El objetivo es mover los recursos compartidos del dispositivo NAS a Windows Server y, a
continuación, usar Azure File Sync para una implementación en la nube híbrida. En
general, las migraciones se deben realizar de forma que garanticen la integridad de los
datos de producción, así como su disponibilidad durante la migración. Esta última
requiere que el tiempo de inactividad sea mínimo, para ajustarse o solo superar
ligeramente las ventanas de mantenimiento regulares.

Como se mencionó en el artículo de información general sobre la migración, de Azure
Files, es importante usar la herramienta de copia y el enfoque correctos. El dispositivo
NAS expone los recursos compartidos de SMB directamente en la red local. RoboCopy,
integrado en Windows Server, es la mejor manera de trasladar los archivos en este
escenario de migración.
Fase 1: Identificación de cuántos recursos compartidos de archivos de Azure se

necesitan
Fase 2: Aprovisionamiento de una instancia de Windows Server adecuada en el
entorno local
Fase 3: Implementación del recurso de nube de Azure File Sync
Fase 4: Implementación de recursos de almacenamiento de Azure
Fase 5: Implementación del agente de Azure File Sync
Fase 6: Configuración de Azure File Sync en la instancia de Windows Server
Fase 7: RoboCopy




considerable.
 Sugerencia

asignación.


de Azure.
 Sugerencia
Azure por servidor.
） Importante

para crecer.


archivos


instalar el agente.

archivos de
Azure de destino
(igual que
anteriormente)

recursos origen.
compartidos de
archivos.
Mantenga el
número de
elementos por
grupo de
sincronización
por debajo de
100 millones de
elementos
(archivos y
carpetas) por
recurso
compartido.
Idealmente, es
mejor
permanecer por
debajo de 20 o
30 millones por
recurso
compartido.

cuenta de cuenta de
(asignación de
1:1) elementos por
grupo de
sincronización
por debajo de
100 millones de
elementos
(archivos y
carpetas) por
recurso
compartido.
Idealmente, es
mejor
permanecer por
debajo de 20 o
30 millones por
recurso
compartido.

recurso archivos de
Aunque un
grupo de
sincronización
puede tener
puntos de
conexión de
servidor en
distintos
servidores de
archivos, los
archivos no
pueden ser
distintos.




Cree una máquina virtual de Windows Server 2022 o Windows Server 2019, o
implemente un servidor físico. También se admite un clúster de conmutación por
error de Windows Server.
Aprovisione o agregue almacenamiento de conexión directa (DAS en lugar de

NAS, que no se admite).
actualmente en el dispositivo NAS. Esta opción de configuración requiere que use
también la característica de nube por niveles de Azure File Sync. Sin embargo,
cuando en una fase posterior copie los archivos del espacio de NAS más grande al
volumen más pequeño de Windows Server, tendrá que trabajar en lotes:
1. Mueva un conjunto de archivos que quepa en el disco.

2. Deje que la sincronización de archivos y la nube por niveles interactúen
3. Cuando se cree más espacio disponible en el volumen, continúe con el
siguiente lote de archivos. También puede revisar el comando RoboCopy en
la sección sobre RoboCopy de este artículo para usar el nuevo conmutador
/LFSM . El uso de /LFSM puede simplificar significativamente los trabajos de
RoboCopy, pero no es compatible con otros modificadores de RoboCopy de

los que podría depender. Use el conmutador /LFSM solo cuando el destino
de la migración sea el almacenamiento local. No se admite cuando el destino
es un recurso compartido de SMB remoto.
Puede evitar este enfoque de procesamiento por lotes si aprovisiona el espacio

equivalente en la instancia de Windows Server que ocupan los archivos en el
dispositivo NAS. Considere la desduplicación en NAS/Windows. Si no quiere
confirmar de manera permanente esta gran cantidad de almacenamiento en la
instancia de Windows Server, puede reducir el tamaño del volumen después de la
migración y antes de ajustar las directivas de nube por niveles. Esto crea una caché
local más pequeña de los recursos compartidos de archivos de Azure.

implemente depende principalmente del número de elementos (archivos y carpetas)
que se van a sincronizar. Se recomienda trabajar con una configuración de rendimiento
más alto si tiene problemas.
Aprenda a cambiar el tamaño de un servidor de Windows Server según el número de

elementos (archivos y carpetas) que necesite sincronizar.
７ Nota
El artículo vinculado anteriormente presenta una tabla con un intervalo de memoria

del servidor (RAM). Puede orientarse hacia el número más pequeño para el
servidor, pero espere que la sincronización inicial tarde mucho más.
Azure File Sync

almacenamiento.



rendimiento.


ellas.

Ｕ Precaución

homólogos locales.
Fase 5: Implementar el agente de Azure File

Sync
Windows Server.

problema.
PowerShell


File Sync.
Fase 6: Configuración de Azure File Sync en el

servidor de Windows Server
El servidor registrado de Windows Server debe estar preparado y conectado a Internet
para este proceso.

） Importante
nube y, a pesar de ello, disponer de todo el espacio de nombres. Los datos de
interés local (nivel de acceso frecuente) también se almacenan en caché para
conseguir un rendimiento de acceso rápido. La nube por niveles es una
característica opcional de cada "punto de conexión de servidor" de Azure File Sync.
２ Advertencia
Si aprovisionó menos almacenamiento en los volúmenes del servidor de Windows

que los datos usados en el dispositivo NAS, la nube por niveles es obligatoria. Si no
activa la nube por niveles, el servidor no liberará espacio para almacenar todos los
archivos. De forma temporal para realizar la migración, establezca la directiva de
almacenamiento por niveles en el 99 % de espacio disponible en el volumen.
Asegúrese de volver a la configuración de nube por niveles una vez que se haya
completado la migración y establézcala en un nivel de utilidad a más largo plazo.

recursos compartidos de archivos de Azure o las ubicaciones del servidor, que deban
Después de crear todos los puntos de conexión de servidor, la sincronización funciona.

Puede crear un archivo de prueba y ver que se sincroniza desde la ubicación del servidor
con el recurso compartido de archivos de Azure conectado (como se describe en el
punto de conexión en la nube del grupo de sincronización).
En las dos ubicaciones, las carpetas del servidor y los recursos compartidos de archivos
de Azure están vacíos y a la espera de datos. En el paso siguiente, comenzará a copiar
archivos a la instancia de Windows Server para que Azure File Sync los transfiera a la
nube. En caso de que haya habilitado la nube por niveles, el servidor comenzará a
organizar los archivos en niveles, si se queda sin capacidad en los volúmenes locales.
Fase 7: RoboCopy
El enfoque de migración básico es una ejecución de RoboCopy del dispositivo NAS a
Windows Server y de Azure File Sync a los recursos compartidos de archivos de Azure.
Identifique la primera ubicación en el dispositivo NAS.

Identifique la carpeta coincidente en el servidor de Windows Server, que ya tiene
Inicie la copia con RoboCopy.
El comando de RoboCopy siguiente copiará los archivos desde el almacenamiento NAS

a la carpeta de destino de la instancia de Windows Server. Windows Server los
sincronizará con los recursos compartidos de archivos de Azure.

que ocupan los archivos en el dispositivo NAS, ha configurado la nube por niveles. A
medida que el volumen local de Windows Server se llena, la nube por niveles se iniciará
y organizará por niveles los archivos que ya se han sincronizado correctamente. La nube
por niveles generará espacio suficiente para continuar con la copia desde el dispositivo
NAS. La nube por niveles realiza comprobaciones cada hora para averiguar qué se ha
sincronizado y para liberar espacio en disco para alcanzar el 99 % de espacio libre del
volumen. Es posible que RoboCopy mueva los archivos más rápido de lo que se pueden
sincronizar con la nube y el nivel localmente, y por tanto quedarse sin espacio en el
disco local. En este caso, RoboCopy producirá un error. Se recomienda trabajar a través
de los recursos compartidos en una secuencia que impida esto. Por ejemplo, no inicie
trabajos de RoboCopy para todos los recursos compartidos al mismo tiempo, o bien
transfiera solo los recursos compartidos que se ajusten a la cantidad actual de espacio
disponible en la instancia de Windows Server.
Consola

<FilePathAndName>

un buen rendimiento, pero solo si los procesadores pueden mantenerlos activos
al mismo tiempo.



destino.

Azure.






relacionados.

） Importante

accediendo a los archivos en la ubicación de NAS y pueden modificarlos. Es posible que
RoboCopy haya procesado un directorio, pase al siguiente y, después, un usuario en la
ubicación de origen (NAS) agregue, cambie o elimine un archivo que no se procesará en
esta ejecución actual de RoboCopy. Este comportamiento es normal.
La primera ejecución consiste en mover la mayor parte de los datos a la instancia de

Windows Server y, después, a la nube a través de Azure File Sync. Esta primera copia
puede tardar mucho tiempo, en función de lo siguiente:

La velocidad de la red local y el número de subprocesos de RoboCopy que
coincidan de forma óptima con ella.
El número de elementos (archivos y carpetas) que deben procesar RoboCopy y
Azure File Sync
posteriores a la última ejecución. Durante esta segunda ejecución, de todos modos se
pueden acumular cambios nuevos.
Repita este proceso hasta que considere que el tiempo que tarda en completarse una
operación de RoboCopy para una ubicación concreta se encuentra dentro una ventana
de inactividad aceptable.

a los recursos compartidos basados en NAS. Para ello, siga los pasos que impidan que
los usuarios cambien el contenido y la estructura de archivos y carpetas. Un ejemplo es
dirigir DFS-Namespace a una ubicación no existente o cambiar las ACL raíz del recurso
compartido.
anterior.

coincidirían automáticamente a medida que los usuarios se encuentren en
Active Directory y RoboCopy copia los archivos y metadatos con total fidelidad. Si ha
utilizado usuarios locales en la ubicación de NAS, debe volver a crearlos como usuarios
locales de Windows Server y asignar los SID existentes que RoboCopy ha transferido a la
instancia de Windows Server a los SID de los nuevos usuarios locales de
Windows Server.

un volumen o una raíz comunes. (Según la asignación de la fase 1)

２ Advertencia
Cuando haya movido todos los datos de su ubicación de NAS a Windows Server y
se haya completado la migración: vuelva a todos los grupos de sincronización de
Azure Portal y ajuste el valor porcentual de espacio libre en el volumen de la nube
por niveles a un valor más adecuado para el uso de la memoria caché, por ejemplo,
un 20 %.

de espacio libre en disco, lo que hará que la memoria caché local no funcione según lo
previsto. A menos que el objetivo sea tener solamente el espacio de nombres para un
volumen que solo contiene datos de archivo a los que se accede con poca frecuencia y
reserve el resto del espacio de almacenamiento para otro escenario.
El problema que puede experimentar más probablemente es que el comando de
RoboCopy produzca el error "Volumen lleno" en el lado de Windows Server. La nube por
niveles actúa una vez cada hora para evacuar el contenido del disco local de
Windows Server, que se ha sincronizado. Su objetivo es alcanzar el 99 % de espacio libre
en el volumen.

Cuando Windows Server tenga capacidad suficiente disponible, el problema se resolverá

al volver a ejecutar el comando. Si se da esta situación, no se interrumpe nada y puede
avanzar con confianza. La única consecuencia es el inconveniente de tener que volver a
ejecutar el comando.
Consulte el vínculo de la sección siguiente para solucionar problemas de Azure File Sync.
Pasos siguientes
Los artículos siguientes le ayudarán a comprender las opciones de implementación, los
procedimientos recomendados y los pasos para solucionar problemas.

Uso de Data Box para migrar de un
almacenamiento conectado a la red
(NAS) a una implementación de nube
híbrida con Azure File Sync
Artículo • 21/11/2023
Este artículo de migración es uno de los que se aplican a las palabras clave NAS, Azure
File Sync y Azure Data Box. Compruebe si este artículo se aplica a su escenario:

＂ Ruta de migración: NAS ⇒ Data Box ⇒ recurso compartido de archivos de Azure ⇒
sincronización con Windows Server
implementación de Azure File Sync
Azure File Sync funciona en ubicaciones de almacenamiento de conexión directa (DAS).

No admite la sincronización con ubicaciones de almacenamiento conectado a la red
(NAS). Por esta razón, debe migrar los archivos. Este artículo le guía a través del
planeamiento y la implementación de esta migración.
Se aplica a
El objetivo es trasladar los recursos compartidos que tiene en el dispositivo NAS a
Windows Server. Después, usará Azure File Sync para una implementación de nube
híbrida. Esta migración se debe realizar de forma que garantice la integridad de los
datos de producción y la disponibilidad durante la migración. Esta última requiere que
el tiempo de inactividad sea mínimo, para cumplir o solo superar ligeramente las
ventanas de mantenimiento regulares.

El proceso de migración consta de varias fases. Necesitará:
Implementar cuentas de almacenamiento y recursos compartidos de archivos de

Azure
Implementar un equipo local que ejecute Windows Server
Configure Azure File Sync.
Migrar archivos mediante Robocopy
Realizar la transición
En las secciones siguientes se describen detalladamente las fases del proceso de

migración.
 Sugerencia
Si vuelve a este artículo, use la navegación del lado derecho de la pantalla para
saltar a la fase de migración en la que se quedó.
Fase 1: Determinación del número de recursos

compartidos de archivos de Azure que necesita



considerable.
 Sugerencia

asignación.


de Azure.
 Sugerencia
Azure por servidor.
） Importante

para crecer.


archivos
# Escenario de Compatible Consideraciones (o Solución (o solución

sincronización limitaciones) alternativa)
1 Servidor de archivos No Un recurso 1) Comience con la

con varios discos o compartido de sincronización de un disco (su
volúmenes y varios archivos de Azure de volumen raíz) para el recurso
recursos destino (punto de compartido de archivos de
compartidos en el conexión en la nube) Azure de destino. Empezar
mismo recurso solo admite la con el disco o volumen más
compartido de sincronización con un grande, ayudará con los
archivos de Azure de grupo de requisitos de almacenamiento
destino sincronización. locales. Configure la nube por
(consolidación) niveles para organizar en
Un grupo de capas todos los datos en la
sincronización solo nube, lo que libera espacio en
admite un punto de el disco del servidor de
conexión de servidor archivos. Mueva datos de
por servidor otros volúmenes o recursos
registrado. compartidos al volumen
actual que se está
sincronizando. Continúe los
pasos uno por uno hasta que
todos los datos estén en
capas en la nube o migrados.
2) Tenga un solo volumen raíz
(disco) como destino a la vez.
Use la nube por niveles para
organizar en capas todos los
datos para tener como
destino el recurso compartido
de archivos de Azure. Quite el
punto de conexión de
servidor del grupo de
sincronización, vuelva a crear
el punto de conexión con el
siguiente volumen o disco
raíz, sincronice y repita el
proceso. Nota: Es posible que
sea necesario volver a instalar
el agente.
3) Se recomienda usar varios
recursos compartidos de
archivos de Azure de destino

(misma o diferente cuenta de
almacenamiento en función
de los requisitos de
rendimiento)
2 Servidor de archivos Sí No se pueden tener Sincronice la raíz del volumen

con un único varios puntos de que contiene varios recursos
volumen y varios conexión de servidor compartidos o carpetas de
recursos por servidor nivel superior. Consulte
compartidos en el registrado que se Concepto de agrupación de
mismo recurso sincronicen con el recursos compartidos y
compartido de mismo recurso Sincronización de volúmenes
archivos de Azure de compartido de para obtener más
destino archivos de Azure de información.
(consolidación) destino (igual que
anteriormente)
3 Servidor de archivos Sí Una sola instancia de 1) Use varios grupos de

con varios recursos Windows Server (o sincronización (número de
compartidos o clúster) puede grupos de sincronización =
volúmenes en varios sincronizar hasta número de recursos
recursos 30 recursos compartidos de archivos de
compartidos de compartidos de Azure con los que
archivos de Azure en archivos de Azure. sincronizar).
una sola cuenta de 2) Solo se pueden sincronizar
almacenamiento Una cuenta de 30 recursos compartidos en
(asignación de almacenamiento es un este escenario a la vez. Si
recursos destino de escalado tiene más de 30 recursos
compartidos de 1:1) para el rendimiento. compartidos en ese servidor
IOPS y el rendimiento de archivos, use el concepto
se comparten entre de agrupación de recursos
recursos compartidos compartidos y la
de archivos. sincronización de volúmenes
para reducir el número de
Mantenga el número carpetas raíz o de nivel
de elementos por superior en el origen.
grupo de 3) Use servidores File Sync
sincronización por adicionales locales y divida o
debajo de 100 mueva datos a estos
millones de elementos servidores para solucionar las
(archivos y carpetas) limitaciones del servidor
por recurso Windows de origen.
compartido.
Idealmente, es mejor
permanecer por
debajo de 20 o 30
millones por recurso

compartido.
4 Servidor de archivos Sí Una sola instancia de El mismo enfoque que más

con varios recursos Windows Server (o arriba
compartidos o clúster) puede
volúmenes en varios sincronizar hasta
recursos 30 recursos
archivos de Azure en archivos de Azure (la
una cuenta de misma cuenta de
almacenamiento almacenamiento o
diferente (asignación una diferente).
de recursos
compartidos de 1:1) Mantenga el número
de elementos por
grupo de
sincronización por
debajo de 100
millones de elementos
(archivos y carpetas)
por recurso
compartido.
Idealmente, es mejor
permanecer por
debajo de 20 o 30
millones por recurso
compartido.
5 Varios servidores de No Un grupo de Siga las instrucciones del

archivos con un sincronización no escenario n.º 1 anterior con
único (volumen raíz puede usar el punto una consideración adicional
o recurso de conexión en la sobre tener un único servidor
compartido) en el nube (recurso de archivos como destino a la
mismo recurso compartido de vez.
compartido de archivos de Azure) ya
archivos de Azure de configurado en otro
destino grupo de
Aunque un grupo de
sincronización puede
tener puntos de
conexión de servidor
en distintos servidores
de archivos, los
archivos no pueden
ser distintos.



rendimiento.



ellas.

Ｕ Precaución

homólogos locales.
Fase 3: Determinación del número de

dispositivos de Azure Data Box que necesita
Inicie este paso solo después de haber finalizado la fase anterior. Los recursos de
almacenamiento de Azure Storage (cuentas de almacenamiento y recursos compartidos
de archivos) se deben crear en este momento. Al solicitar su Data Box, debe especificar
las cuentas de almacenamiento a las que Data Box se mueve.
En esta fase, debe asignar los resultados del plan de migración de la fase anterior a los
límites de las opciones de Data Box disponibles. Estas consideraciones le ayudarán a
crear un plan para las opciones de Data Box que se van a elegir, así como cuántas
necesitará para mover los recursos compartidos de NAS a recursos compartidos de
archivos de Azure.
Para determinar el número de dispositivos que necesita y sus tipos, tenga en cuenta
estos límites importantes:
Cualquier dispositivo de Azure Data Box puede mover datos a un máximo de

10 cuentas de almacenamiento.
Cada opción de Data Box viene con su propia capacidad utilizable. Consulte
opciones de Data Box.
Consulte el plan de migración para encontrar el número de cuentas de almacenamiento

que ha decidido crear y los recursos compartidos en cada una de ellas. A continuación,
examine el tamaño de cada uno de los recursos compartidos de NAS. La combinación
de esta información le permitirá optimizar y decidir qué dispositivo debe enviar datos a
las cuentas de almacenamiento. Dos dispositivos de Data Box pueden trasladar los
archivos a la misma cuenta de almacenamiento, pero no divida el contenido de un solo
recurso compartido de archivos en dos instancias de Data Box.
Opciones de Data Box

Para una migración estándar, elija una combinación de estas opciones de Data Box:
Data Box Disk. Data Box Disks: Microsoft le enviará entre uno y cinco discos SSD
con una capacidad de 8 TiB cada uno, con un total de 40 TiB como máximo. La
capacidad utilizable es aproximadamente un 20 % menor debido al cifrado y la
sobrecarga del sistema de archivos. Para más información, consulte la
documentación de Data Box Disk.
Data Box. Esta opción es la más común. Microsoft le enviará un dispositivo de Data
Box resistente que funciona de forma similar a un NAS. Tiene una capacidad
utilizable de 80 TiB. Para más información, consulte la documentación de Data Box.
Data Box Heavy. Esta opción presenta un dispositivo Data Box resistente en
ruedas, que funciona de forma similar a un NAS. Tiene una capacidad de 1 PiB. La
capacidad utilizable es aproximadamente un 20 % menor debido al cifrado y la
sobrecarga del sistema de archivos. Para más información, consulte la
documentación de Data Box Heavy.

Mientras espera a que lleguen los dispositivos Azure Data Box, puede empezar a revisar
las necesidades de una o más instancias de Windows Server que va a usar con Azure File
Sync.
Cree una instancia de Windows Server 2019 (como mínimo,

Windows Server 2012 R2) como una máquina virtual o un servidor físico. También
se admite un clúster de conmutación por error de Windows Server.
Aprovisione o agregue almacenamiento de conexión directa (DAS, en lugar de
NAS, que no se admite).

implemente depende principalmente del número de archivos y carpetas que se van a
sincronizar. Se recomienda una configuración de rendimiento más alto si tiene
problemas.
Aprenda a cambiar el tamaño de una instancia de Windows Server según el número de
elementos que necesite sincronizar.
７ Nota
El artículo vinculado anteriormente incluye una tabla con un intervalo de memoria

del servidor (RAM). Puede usar los números del extremo inferior del intervalo para
el servidor, pero probablemente la sincronización inicial tardará mucho más.
Fase 5: Copia de archivos en el dispositivo Data

Box
Cuando llegue el dispositivo Data Box, deberá configurarlo con conectividad de red no
impedida a su dispositivo NAS. Siga la documentación de establecimiento del tipo de
Data Box que solicitó:
Configuración de Data Box.

Configuración de Data Box Disk.
Configuración de Data Box Heavy.
Dependiendo del tipo de Data Box, las herramientas de copia de Data Box podrían estar
disponibles. En este punto, no se recomiendan para las migraciones a recursos
compartidos de archivos de Azure porque no copian los archivos en el dispositivo Data
Box con total fidelidad. En su lugar, use RoboCopy.
Cuando llegue el dispositivo Data Box, tendrá recursos compartidos de SMB

aprovisionados previamente disponibles para cada cuenta de almacenamiento que
especificó cuando lo solicitó.
Si los archivos entran en un recurso compartido de archivos prémium de Azure,

habrá un recurso compartido de SMB por cuenta de almacenamiento de
"almacenamiento de archivos" prémium.
Si los archivos entran en una cuenta de almacenamiento estándar, habrá tres
recursos compartidos de SMB por cuenta de almacenamiento estándar (GPv1 y
GPv2). Solo los recursos compartidos de archivos que terminan con _AzFiles son
pertinentes para la migración. Omita los recursos compartidos de blob en bloques
y en páginas.
Siga los pasos descritos en la documentación de Azure Data Box:
1. Conexión a un dispositivo Data Box.

2. Copia de datos a un dispositivo Data Box.
Puede usar Robocopy (siga las instrucciones que se incluyen a continuación) o el
nuevo servicio de copia de datos de Data Box.
3. Preparación del dispositivo Data Box para cargarlo en Azure.
 Sugerencia
Como alternativa a Robocopy, Data Box ha creado un servicio de copia de datos.

Puede usar este servicio para cargar archivos en Data Box con plena fidelidad. Siga
este tutorial sobre el servicio de copia de datos y asegúrese de establecer el
destino correcto del recurso compartido de archivos de Azure.
La documentación de Data Box especifica un comando Robocopy. Ese comando no es

adecuado para conservar la fidelidad completa de archivos y carpetas. En su lugar, use
este comando:
Consola

<FilePathAndName>




escala.

destino.

Azure.






correctamente.

"suelo". El formato /LFSM:n de la marca puede especificar este valor. El
parámetro n se especifica en la base 2: nKB , nMB o nGB . Si /LFSM se especifica sin
ningún valor floor explícito, floor se establece en el 10 por ciento del tamaño del
volumen de destino. El modo de espacio libre bajo no es compatible con /MT ,
/EFSRAW ni /ZB . Se agregó compatibilidad con /B en Windows Server 2022.
Consulte la sección Windows Server 2022 y RoboCopy LFSM a continuación para
obtener más información, incluidos detalles sobre un error y una solución
alternativa relacionados.


） Importante

Azure File Sync
Antes de continuar con esta guía, espere hasta que todos los archivos hayan llegado a
los recursos compartidos de archivos de Azure correctos. El proceso de envío e ingesta
de datos de Data Box llevará tiempo.

almacenamiento.
Fase 7: Implementación del agente de Azure

File Sync
Windows Server.

problema.
PowerShell


File Sync.
Fase 8: Configuración de Azure File Sync en la

instancia de Windows Server

Active la característica de nube por niveles y seleccione Namespace only (Solo espacio
de nombres) en la sección de descarga inicial.
） Importante
nube pero disponer de todo el espacio de nombres. Los datos de interés local
también se almacenan en caché para conseguir un rendimiento de acceso rápido.
La nube por niveles es opcional. Puede establecerla individualmente para cada
punto de conexión de Azure File Sync servidor. Debe usar esta característica si no
tiene suficiente capacidad de disco local en una instancia de Windows Server para
contener todos los datos en la nube y si quiere evitar la descarga de todos los
datos de la nube.
Para todos los recursos compartidos de archivos de Azure o las ubicaciones de servidor
que necesita configurar para la sincronización, repita los pasos para crear grupos de
sincronización y agregar las carpetas de servidor correspondientes como puntos de
conexión de servidor. Espere hasta que se complete la sincronización del espacio de
nombres. En la sección siguiente se explica cómo puede asegurarse de que la
sincronización se haya completado.
７ Nota
Después de crear un punto de conexión de servidor, la sincronización funciona.

Aun así, la sincronización debe enumerar (detectar) los archivos y las carpetas que
se movieron a través de Data Box al recurso compartido de archivos de Azure.
Según el tamaño del espacio de nombres, puede pasar mucho tiempo antes de
que el espacio de nombres de la nube aparezca en el servidor.
Fase 9: Espera para que el espacio de nombres

aparezca por completo en el servidor
Antes de continuar con los pasos siguientes de la migración, espere a que el servidor
haya descargado por completo el espacio de nombres del recurso compartido de nube.
Si empieza a mover archivos demasiado pronto al servidor, corre el riesgo de que se
realicen cargas innecesarias e incluso de que se produzcan conflictos de sincronización
de archivos.
Para determinar si el servidor ha completado la sincronización inicial de la descarga,

abra el Visor de eventos en la instancia de Windows Server que se está sincronizando y
use el registro de eventos de telemetría de Azure File Sync. El registro de eventos de
telemetría se encuentra en el Visor de eventos en Applications and
Services\Microsoft\FileSync\Agent.
Busque el evento 9102 más reciente. El identificador de evento 9102 se registra cuando
finaliza una sesión de sincronización. En el texto del evento, hay un campo para la
dirección de sincronización de la descarga. ( HResult debe ser cero y los archivos deben
descargarse).
Debería ver dos eventos consecutivos de este tipo y con este contenido para asegurarse
de que el servidor haya terminado de descargar el espacio de nombres. No hay ningún
problema si hay otros eventos entre los dos eventos 9102.
Fase 10: Ejecución de Robocopy desde el NAS

Una vez que el servidor haya completado la sincronización inicial del espacio de
nombres completo desde el recurso compartido en la nube, puede continuar con este
paso. La sincronización inicial debe completarse antes de continuar con este paso.
Consulte la sección anterior para obtener más información.
En este paso, ejecutará trabajos de Robocopy para sincronizar los recursos compartidos
en la nube con los cambios más recientes del NAS que se produjeron desde el
momento en que bifurcó los recursos compartidos en el dispositivo Data Box. Esta
ejecución de Robocopy puede finalizar rápidamente o tardar unos minutos, en función
de la cantidad de abandonos que se hayan producido en los recursos compartidos de
NAS.
２ Advertencia
Debido al comportamiento con regresión de Robocopy en Windows Server 2019, el

modificador /MIR de Robocopy no es compatible con los directorios de destino en
capas. No puede usar Windows Server 2019 ni un cliente Windows 10 para esta
fase de la migración. Use Robocopy en una instancia intermedia de
Windows Server 2016.
Este es el enfoque de migración básico:
Ejecute Robocopy desde el dispositivo NAS para sincronizar la instancia de

Windows Server.
Use Azure File Sync para sincronizar los recursos compartidos de archivos de Azure
desde Windows Server.
1. Identifique la primera ubicación en el dispositivo NAS.

2. Identifique la carpeta coincidente en la instancia de Windows Server, que ya tiene
3. Inicie la copia con Robocopy.
El comando de Robocopy siguiente solo copiará las diferencias (archivos y carpetas

actualizados) desde el almacenamiento NAS a la carpeta de destino de la instancia de
Windows Server. Después, la instancia de Windows Server los sincronizará con los
Consola

<FilePathAndName>



escala.

destino.


Azure.






correctamente.

"suelo". El formato /LFSM:n de la marca puede especificar este valor. El
parámetro n se especifica en la base 2: nKB , nMB o nGB . Si /LFSM se especifica sin
ningún valor floor explícito, floor se establece en el 10 por ciento del tamaño del
volumen de destino. El modo de espacio libre bajo no es compatible con /MT ,
/EFSRAW ni /ZB . Se agregó compatibilidad con /B en Windows Server 2022.
Consulte la sección Windows Server 2022 y RoboCopy LFSM a continuación para
obtener más información, incluidos detalles sobre un error y una solución

alternativa relacionados.


） Importante

que usan los archivos del dispositivo NAS, ha configurado la nube por niveles. A medida
que el volumen local de Windows Server se llena, la nube por niveles se iniciará y
organizará por niveles los archivos que ya se han sincronizado correctamente. La nube
por niveles generará espacio suficiente para continuar con la copia desde el dispositivo
NAS. La nube por niveles realiza comprobaciones cada hora para determinar qué se ha
sincronizado y liberar espacio en disco a fin de alcanzar el 99 % de espacio libre del
volumen.
Robocopy podría tener que trasladar más archivos de los que se pueden almacenar
localmente en la instancia de Windows Server. Puede esperar que Robocopy realice el
traslado más rápido de lo que Azure File Sync puede cargar los archivos y cambiarlos de
nivel del volumen local. En esta situación, Robocopy producirá un error. Se recomienda
trabajar con los recursos compartidos en una secuencia que impida esta situación. Por
ejemplo, mueva solo los recursos compartidos que quepan en el espacio disponible en
la instancia de Windows Server. Otra opción es evitar iniciar trabajos de Robocopy en
todos los recursos compartidos al mismo tiempo. La buena noticia es que el
modificador /MIR garantizará que solo se muevan los valores delta. Una vez que se haya
movido un valor delta, un trabajo reiniciado no tendrá que volver a mover el archivo.
Realización de la transición
Al ejecutar por primera vez el comando Robocopy, los usuarios y las aplicaciones
seguirán accediendo a los archivos en la ubicación del NAS y podrán modificarlos.
Robocopy procesará un directorio y, luego, pasará al siguiente. A continuación, un
usuario del NAS podría agregar, cambiar o eliminar un archivo del primer directorio que
no se procesará durante la ejecución actual de Robocopy. Este comportamiento es
normal.
La primera ejecución consiste en mover la mayor parte de los datos perdidos a la

instancia de Windows Server y, después, a la nube mediante Azure File Sync. Esta
primera copia puede tardar mucho tiempo, en función de lo siguiente:

La velocidad de la red local y lo óptimamente que los subprocesos de Robocopy
coinciden con ella.
El número de elementos (archivos y carpetas) que deben procesar Robocopy y
Azure File Sync.
Robocopy finalizará más rápido la segunda vez que lo ejecute para un recurso
compartido, ya que solo necesita transportar los cambios posteriores a la última

a los recursos compartidos basados en NAS. Hágalo de cualquier forma que impida que
los usuarios cambien el contenido y la estructura de archivos y carpetas. Por ejemplo,
puede apuntar el espacio de nombres DFS a una ubicación que no existe o cambiar las
ACL raíz en el recurso compartido.
Ejecute Robocopy una última vez. Recuperará todos los cambios que se hayan omitido.
El tiempo necesario para hacer este último paso depende de la velocidad del análisis de
Robocopy. Para realizar un cálculo estimado del tiempo (que equivale al tiempo de
inactividad), averigüe cuánto duró la ejecución anterior.

coincidirían automáticamente porque los usuarios se encuentran en Active Directory y
Robocopy copia los archivos y metadatos con total fidelidad. Si ha empleado usuarios
locales en el NAS, debe hacer lo siguiente:
Vuelva a crear estos usuarios como usuarios locales de Windows Server.

Asigne los SID existentes que Robocopy ha migrado a su instancia de
Windows Server a los SID de los usuarios locales nuevos de Windows Server.
Ha completado la migración de un recurso compartido o un grupo de recursos

compartidos a una raíz o un volumen común (en función de la asignación de la fase 1).

ámbito de un recurso compartido de archivos de Azure de cada vez.
Opción en desuso: "transferencia de datos sin

conexión"
Antes de la publicación del agente de Azure File Sync versión 13, la integración con Data
Box se realizaba mediante un proceso denominado "transferencia de datos sin
conexión". Este proceso está en desuso. Con la versión 13 del agente, se ha
reemplazado por los pasos mucho más sencillos y rápidos que se describen en este
artículo. Si sabe que quiere usar la funcionalidad de "transferencia de datos sin
conexión" en desuso, todavía puede hacerlo. Sigue disponible mediante un módulo de
PowerShell de AFS anterior concreto:
PowerShell
Install-Module Az.StorageSync -RequiredVersion 1.4.0

Import-module Az.StorageSync -RequiredVersion 1.4.0
# Verify the specific version is loaded:
Get-module Az.StorageSync
２ Advertencia
Después del 15 de mayo de 2022, ya no podrá crear un punto de conexión de

servidor en el modo de "transferencia de datos sin conexión". Las migraciones en
curso con este método deben finalizar antes del 15 de julio de 2022. Si la migración
continúa en ejecución con un punto de conexión de servidor habilitado para la
"transferencia de datos sin conexión", el servidor comenzará a cargar los archivos
restantes del servidor el 15 de julio de 2022 y ya no aprovechará los archivos
transferidos con Azure Data Box al recurso compartido de almacenamiento
provisional.
El problema más común es que el comando Robocopy genere un error de tipo
"Volumen lleno" en el lado de Windows Server. La nube por niveles actúa una vez cada
hora para evacuar el contenido del disco local de Windows Server, que se ha
sincronizado. Su objetivo es alcanzar el 99 % de espacio libre en el volumen.

disco. Puede observarlo en el Explorador de archivos en la instancia de Windows Server.
Cuando la instancia de Windows Server tenga capacidad suficiente disponible, vuelva a

ejecutar el comando para resolver el problema. Si se da esta situación, no se interrumpe
nada y puede avanzar con plena confianza. La única consecuencia es el inconveniente
de tener que volver a ejecutar el comando.
Para solucionar problemas de Azure File Sync, consulte el artículo que se indica en la
sección siguiente.
Pasos siguientes
Hay más información sobre los recursos compartidos de archivos de Azure y Azure File
Sync. Los artículos siguientes lo ayudarán a comprender las opciones avanzadas y los
procedimientos recomendados. También proporcionan ayuda para solucionar
problemas. Estos artículos contienen vínculos a la documentación del recurso
compartido de archivos de Azure cuando corresponda.

Migración de las series 8100 y 8600 de
StorSimple a Azure File Sync
Artículo • 21/03/2023
La serie StorSimple 8000 está representada por los dispositivos físicos y locales 8100 o
8600 y sus componentes de servicios en la nube. Las aplicaciones virtuales StorSimple
8010 y 8020 también se tratan en esta guía de migración. Es posible migrar los datos de
cualquiera de estos dispositivos a recursos compartidos de archivos de Azure con la
aplicación Azure File Sync opcional. Azure File Sync es el servicio de Azure a largo plazo
predeterminado y estratégico que reemplaza la funcionalidad local de StorSimple. En
este artículo se proporcionan los conocimientos básicos y los pasos de migración
necesarios para realizar una migración correcta a Azure File Sync.
７ Nota
El servicio StorSimple (incluido el Administrador de dispositivos de StorSimple para

las series 8000 y 1200 y StorSimple Data Manager) ha llegado al final de la fase de
soporte técnico. El final del soporte técnico de StorSimple se publicó en 2019 en las
páginas Política del ciclo de vida de Microsoft y Comunicaciones de Azure . Se
enviaron notificaciones adicionales por correo electrónico y se publicaron en Azure
Portal y en la información general de StorSimple. Póngase en contacto con el
servicio de Soporte técnico de Microsoft para obtener más información.
En este vídeo se proporciona información general sobre:

Azure Files
Azure File Sync
Comparación de la Azure Files de StorSimple &
Información general sobre la herramienta de migración y el proceso de StorSimple
Data Manager
Fase 1: Preparación para la migración

Esta sección contiene los pasos que debe seguir al principio de la migración de
volúmenes de StorSimple a recursos compartidos de archivos de Azure.
El vídeo trata de:

Selección del nivel de almacenamiento
Selección de redundancia de almacenamiento.
Selección de acceso directo a recursos compartidos de archivos o Azure File Sync
Clave de cifrado de datos del servicio de StorSimple& número de serie
Migración de copia de seguridad de volúmenes de StorSimple
Asignación de recursos compartidos de volúmenes de StorSimple& a recursos
Agrupación de recursos compartidos dentro de recursos compartidos de archivos
de Azure
Consideraciones de asignación
Hoja de cálculo de planificación de iteración
Hoja de cálculo de asignación de espacios de nombres
Tema de
Cuando empiece a planear la migración, identifique primero todos los dispositivos y
volúmenes de StorSimple que necesita migrar. Una vez hecho esto, puede decidir cuál
es la mejor ruta de migración.
Los dispositivos físicos de StorSimple (serie 8000) usan esta guía de migración.
Los dispositivos virtuales, serie StorSimple 1200, usan una guía de migración
diferente.
Resumen de costos de migración

Las migraciones a recursos compartidos de archivos de Azure desde volúmenes de
StorSimple a través de trabajos de migración en un recurso de StorSimple Data Manager
son gratuitas. Pueden producirse otros costos durante y después de la migración:
Salida de red: los archivos de StorSimple residen en una cuenta de

almacenamiento dentro de una región de Azure específica. Si aprovisiona los
recursos compartidos de archivos de Azure que migra a una cuenta de
almacenamiento que se encuentra en la misma región de Azure, no se incurrirá en
ningún costo de salida. Puede trasladar los archivos a una cuenta de
almacenamiento en una región diferente como parte de esta migración. En ese
caso, se le aplicarán costos de salida.
Transacciones de recursos compartido de archivos de Azure: cuando los archivos
se copian en un recurso compartido de archivos de Azure (como parte de una
migración o fuera de una), los costos de transacción se aplican a medida que se
escriben archivos y metadatos. Como procedimiento recomendado, inicie el
recurso compartido de archivos de Azure del nivel optimizado para transacciones
durante la migración. Cambie al nivel deseado después de finalizar la migración.
Las fases siguientes recordarán este paso en el momento apropiado.
Cambio del nivel de un recurso compartido de archivos de Azure: cambiar el
nivel de un recurso compartido de archivos de Azure conlleva transacciones. En la
mayoría de los casos, será más rentable seguir los consejos del punto anterior.
Coste de almacenamiento: cuando esta migración comienza a copiar archivos en
un recurso compartido de archivos de Azure, se consume y se factura
almacenamiento. Las copias de seguridad migradas se convertirán en instantáneas
de recurso compartido de archivos de Azure. Las instantáneas de recurso
compartido de archivos solo consumen la capacidad de almacenamiento para las
diferencias que contienen.
StorSimple: hasta que tenga la oportunidad de desaprovisionar las cuentas de
almacenamiento y los dispositivos de StorSimple, se seguirá incurriendo el costo
de StorSimple por almacenamiento, copias de seguridad y dispositivos.
Acceso directo de recursos compartidos frente a Azure

File Sync
Los recursos compartidos de archivos de Azure proporcionan un sinfín de
oportunidades para estructurar la implementación de servicios de archivo. Un recurso
compartido de archivos de Azure es simplemente un recurso compartido de SMB en la
nube, que puede configurar para que los usuarios tengan acceso directo a través del
protocolo SMB con la autenticación Kerberos conocida y los permisos NTFS existentes
(ACL de archivos y carpetas) funcionen de forma nativa. Obtenga más información sobre
el acceso basado en identidad a recursos compartidos de archivos de Azure.
Una alternativa al acceso directo es Azure File Sync. Azure File Sync es un análogo
directo de la capacidad de StorSimple de almacenar en caché los archivos que se usan
con frecuencia de forma local.
Azure File Sync es un servicio en la nube de Microsoft, que se basa en dos componentes
principales:
Sincronización de archivos y nube por niveles para crear una caché de acceso de
rendimiento en cualquier servidor de Windows.
Recursos compartidos de archivos como almacenamiento nativo en Azure, a los
que se puede acceder a través de varios protocolos, como SMB y REST de archivos.
Los recursos compartidos de archivos de Azure conservan aspectos importantes de la

fidelidad de archivos en archivos almacenados como atributos, permisos y marcas de
tiempo. Con los recursos compartidos de Azure, ya no es necesario una aplicación o
servicio que interprete los archivos y carpetas que están almacenados en la nube. Puede
acceder a ellos de forma nativa mediante protocolos y clientes conocidos como el
Explorador de archivos de Windows. Los recursos compartidos de archivos de Azure
permiten almacenar datos de aplicaciones y de servidores de archivos de uso general en
la nube. La copia de seguridad de un recurso compartido de archivos de Azure es una
funcionalidad integrada que se puede mejorar gracias a Azure Backup.
Este artículo se centra en los pasos de migración. Si desea obtener más información
sobre Azure File Sync antes de la migración, consulte los siguientes artículos:

Guía de implementación de Azure File Sync
Clave de cifrado de datos del servicio de StorSimple

La primera vez que se configura el dispositivo de StorSimple, se genera una "clave de
cifrado de datos del servicio" y se le indica que almacene la clave de forma segura. Esta
clave se usa para cifrar todos los datos de la cuenta de almacenamiento de Azure
asociada, en la que el dispositivo de StorSimple almacena los archivos.
La "clave de cifrado de datos del servicio" es necesaria para llevar a cabo una migración
correcta. Ahora es un buen momento para recuperar esta clave de los registros, una
para cada dispositivo del inventario.
Si no puede encontrar las claves en los registros, puede recuperar una nueva clave
desde el dispositivo. Cada dispositivo tiene una clave de cifrado única.
Cambiar la clave de cifrado de datos de servicio

Las claves de cifrado de datos del servicio se usan para cifrar datos confidenciales de los
clientes, como las credenciales de la cuenta de almacenamiento, que se envían desde el
servicio StorSimple Manager al dispositivo de StorSimple. Necesitará cambiar estas
claves periódicamente si su organización de TI tiene una directiva de rotación de claves
en los dispositivos de almacenamiento. El proceso de cambio de clave puede ser
ligeramente diferente dependiendo de si el servicio StorSimple Manager administra uno
o varios dispositivos. Para más información, vaya a StorSimple security and data
protection (Protección de datos y seguridad de StorSimple).
El cambio de la clave de cifrado de datos del servicio se realiza en 3 pasos:
1. Mediante scripts de Windows PowerShell para Azure Resource Manager, autorice a

un dispositivo cambiar la clave de cifrado de datos del servicio.
2. En Windows PowerShell para StorSimple, inicie el cambio de claves de cifrado de
datos del servicio.
3. Si tiene más de un dispositivo de StorSimple, actualice la clave de cifrado de datos
del servicio en los demás dispositivos.
Paso 1: Usar un script de Windows PowerShell para

autorizar a un dispositivo a cambiar la clave de cifrado de
datos del servicio
Normalmente, el administrador de dispositivos solicitará que el administrador de
servicios autorice que un dispositivo cambie las claves de cifrado de datos del servicio. A
continuación, el administrador de servicios autorizará que el dispositivo cambie la clave.
Este paso se realiza con el script basado en Azure Resource Manager. El administrador
de servicios puede seleccionar un dispositivo que sea apto para la autorización. A
continuación, se autoriza que el dispositivo inicie el proceso de cambio de las claves de
cifrado de datos del servicio.
Para más información sobre el uso del script, vaya a Authorize-

ServiceEncryptionRollover.ps1
¿Qué dispositivos se pueden autorizar para que cambien las claves
de cifrado de datos del servicio?
Para poder autorizar que un dispositivo inicie los cambios de las claves de cifrado de
datos del servicio debe cumplir los siguientes criterios:
Para que sea válido para la autorización de cambio de claves de cifrado de datos
del servicio, el dispositivo debe estar en línea.
Si el cambio de claves no se ha iniciado, es posible autorizar el mismo dispositivo
30 minutos después.
Se puede autorizar otro dispositivo, siempre que el dispositivo autorizado
anteriormente no haya iniciado el cambio de claves. Una vez que se haya
autorizado el nuevo dispositivo, el anterior no puede iniciar el cambio.
No se puede autorizar un dispositivo mientras la sustitución de la clave de cifrado
de datos del servicio esté en curso.
Se puede autorizar un dispositivo cuando algunos de los dispositivos registrados
en el servicio hayan sustituido el cifrado, mientras que otros no lo hayan hecho.
Paso 2: Usar Windows PowerShell para StorSimple a fin

de iniciar el cambio de claves de cifrado de datos del
servicio
Este paso se realiza en la interfaz de Windows PowerShell para StorSimple del
dispositivo de StorSimple autorizado.
７ Nota
Hasta que se complete la sustitución de claves no se pueden realizar operaciones

en Azure Portal del servicio StorSimple Manager.
Si utiliza la consola serie del dispositivo para conectarse a la interfaz de Windows

PowerShell, realice los pasos siguientes.
Para iniciar el cambio de claves de cifrado de datos del servicio
1. Seleccione la opción 1 para iniciar sesión con acceso total.
2. En el símbolo del sistema, escriba:
Invoke-HcsmServiceDataEncryptionKeyChange
3. Una vez que se haya completado correctamente el cmdlet, obtendrá una nueva
clave de cifrado de datos del servicio. Copie y guarde esta clave para usarla en el
paso 3 de este proceso. Esta clave se utilizará para actualizar todos los dispositivos
restantes registrados en el servicio StorSimple Manager.
７ Nota
Este proceso debe iniciarse en las cuatro horas siguientes a la autorización de

un dispositivo de StorSimple.
A continuación, esta nueva clave se envía al servicio de inserción en todos los

dispositivos que están registrados en el servicio. Seguidamente, aparecerá una
alerta en el panel del servicio. El servicio deshabilitará todas las operaciones en los
dispositivos registrados y, a continuación, el administrador de dispositivos tendrá
que actualizar la clave de cifrado de datos del servicio en el resto de dispositivos.
Sin embargo, las E/S (hosts que envían datos a la nube) no se interrumpirán.
Si tiene un único dispositivo registrado en el servicio, el proceso de sustitución

habrá finalizado y puede omitir el paso siguiente. Si tiene varios dispositivos
registrados en el servicio, vaya al paso 3.
Paso 3: Actualizar la clave de cifrado de datos del servicio

en otros dispositivos de StorSimple
Estos pasos deben realizarse en la interfaz de Windows PowerShell del dispositivo de
StorSimple si tiene varios dispositivos registrados en el servicio StorSimple Manager. La
clave que obtuvo en el paso 2 se debe usar para actualizar todos los dispositivos de
StorSimple restantes registrados con el servicio StorSimple Manager.
Realice los pasos siguientes para actualizar el cifrado de datos del servicio en el
dispositivo.
Para actualizar la clave de cifrado de datos del servicio en

dispositivos físicos
1. Use Windows PowerShell para StorSimple para conectarse a la consola. Seleccione

la opción 1 para iniciar sesión con acceso total.
2. En el símbolo del sistema, escriba: Invoke-HcsmServiceDataEncryptionKeyChange –
ServiceDataEncryptionKey
3. Proporcione la clave de cifrado de datos del servicio que obtuvo en Paso 2: Usar
Windows PowerShell para StorSimple a fin de iniciar el cambio de claves de cifrado
de datos del servicio.
Para actualizar la clave de cifrado de datos del servicio en todas las

aplicaciones en la nube 8010/8020
1. Descargue y configure el script de PowerShell Update-

CloudApplianceServiceEncryptionKey.ps1 .
2. Abra PowerShell y, en el símbolo del sistema, escriba: Update-
CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -
TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device
manager]
Este script asegurará de que esa clave de cifrado de datos del servicio se establece en
todas las aplicaciones en la nube 8010/8020 en el administrador de dispositivos.
Ｕ Precaución
Cuando decida cómo conectarse a su dispositivo de StorSimple, tenga en cuenta lo

siguiente:
La conexión a través de una sesión HTTPS es la opción más segura y la

recomendada.
Es seguro conectarse directamente a la consola en serie del dispositivo, pero
la conexión a la consola en serie a través conmutadores de red no lo es.
Las conexiones de sesión HTTP son una opción, pero no están cifradas. No se
recomiendan a menos que se usen en una red cerrada y de confianza.
Restricciones conocidas
Los recursos compartidos de StorSimple Data Manager y Azure tienen algunas
limitaciones que debe tener en cuenta antes de comenzar la migración, ya que pueden
impedir una migración:
Solo se admiten volúmenes NTFS desde el dispositivo StorSimple. Los volúmenes

ReFS no son compatibles.
No se admite ningún volumen ubicado en discos dinámicos de Windows Server
(en desuso antes Windows Server 2012)
El servicio no funciona con volúmenes cifrados con BitLocker o que tengan
habilitada la opción Desduplicación de datos.
Las copias de seguridad de StorSimple dañadas no se pueden migrar.
Las opciones de red especiales, como los firewalls o la comunicación solo de punto
de conexión privado, no se pueden habilitar ni en la cuenta de almacenamiento de
origen donde se almacenan las copias de seguridad de StorSimple ni en la cuenta
de almacenamiento de destino que contiene los recursos compartidos de archivos
de Azure.
Fidelidad de archivos
Si ninguna de las limitaciones de Known limitations (Limitaciones conocidas) impide una
migración. Hay limitaciones en cuanto a lo que se puede almacenar en los recursos
compartidos de archivos de Azure que debe tener en cuenta. La fidelidad de los archivos
hace referencia a la gran cantidad de atributos, marcas de tiempo y datos que
componen un archivo. En una migración, la fidelidad de los archivos es una medida de
lo bien que se puede trasladar (migrar) la información del origen (volumen StorSimple)
al destino (recurso compartido de archivos de Azure). Azure Files admite un
subconjunto de las propiedades del archivo NTFS. Se migrarán las ACL, los metadatos
comunes y algunas marcas de tiempo. Los siguientes elementos no impedirán una
migración, pero provocarán problemas por elementos durante la misma:
Marcas de tiempo: no se establecerá el tiempo de cambio de archivo; actualmente

es de solo lectura a través del protocolo REST. La marca de tiempo de último
acceso de un archivo no se trasladará; actualmente no es un atributo admitido en
los archivos almacenados en un recurso compartido de archivos de Azure.
Los flujos de datos alternativos no se pueden almacenar en recursos compartidos
de archivos de Azure. Los archivos que contienen flujos de datos alternativos se
copiarán, pero los flujos de datos alternativos se eliminarán del archivo en el
proceso.
Los vínculos simbólicos, los vínculos duros, las uniones y los puntos de análisis se
omiten durante una migración. Los registros de copia de la migración mostrarán
cada elemento omitido y el motivo de su omisión.
Los archivos cifrados de EFS no se copiarán. Los registros de copia mostrarán que
el elemento no se pudo copiar con "Access is denied" (Acceso denegado).
Los archivos dañados se omiten. Los registros de copia pueden mostrar errores
diferentes para cada elemento dañado en el disco de StorSimple: "The request
failed due to a fatal device hardware error" (Error en la solicitud debido a un error
irrecuperable de hardware del dispositivo) o "The file or directory is corrupted or
unreadable" (El archivo o directorio está dañado o no se puede leer) o "The access
control list (ACL) structure is invalid" (La estructura de la lista de control de acceso
[ACL] no es válida).
Se omitirán los archivos individuales de más de 4 TiB.
Las longitudes de ruta de acceso de archivo deben ser iguales o inferiores a
2048 caracteres. Se omitirán los archivos y carpetas con rutas de acceso más
largas.
Se omitirán los puntos de repetición de análisis. El motor de migración no puede
resolver ningún punto de repetición de análisis de datos de SIS o Desduplicación
de datos de Microsoft, o los de terceros, y evitar una migración de los archivos y
carpetas afectados.
La sección de solución de problemas al final de este artículo tiene más detalles sobre el
nivel de elemento y los códigos de error de nivel de trabajo de migración y, siempre que
sea posible, sus opciones de mitigación.
Copias de seguridad de volúmenes de StorSimple

StorSimple ofrece copias de seguridad diferenciales en el nivel de los volúmenes. Los
recursos compartidos de archivos de Azure también tienen esta capacidad, denominada
"instantáneas de recurso compartido". Los trabajos de migración solo pueden migrar
copias de seguridad, no datos del volumen activo. Por lo tanto, la copia de seguridad
más reciente siempre debe estar en la lista de copias de seguridad que se han
trasladado en una migración.
Decida si necesita trasladar alguna copia de seguridad anterior durante la migración. El

procedimiento recomendado consiste en mantener esta lista lo más breve posible, de
modo que los trabajos de migración se completen más rápido.
Para identificar las copias de seguridad críticas que se deben migrar, realice una lista de
comprobación de las directivas de copia de seguridad. Por ejemplo:
La copia de seguridad más reciente. (Nota: la copia de seguridad más reciente

siempre debe formar parte de esta lista).
Una copia de seguridad al mes durante 12 meses.
Una copia de seguridad al año durante tres años.
Más adelante, al crear los trabajos de migración, puede usar esta lista para identificar las
copias de seguridad del volumen de StorSimple exactas que se deben migrar para
cumplir los requisitos de la lista.
Ｕ Precaución
No se admite la selección de más de 50 copias de seguridad de volumen de
StorSimple. Los trabajos de migración solo pueden migrar copias de seguridad,
nunca datos del volumen activo. Por lo tanto, la copia de seguridad más reciente es
más cercana a los datos activos y, por lo tanto, debe formar parte de la lista de
copias de seguridad que se trasladarán en una migración.
Ｕ Precaución
Es mejor suspender todas las directivas de retención de copia de seguridad de

StorSimple antes de seleccionar una copia de seguridad para la migración.
La migración de las copias de seguridad tarda varios días o semanas. StorSimple
ofrece directivas de retención de copias de seguridad que eliminarán las copias de
seguridad. Las copias de seguridad que ha seleccionado para esta migración
pueden eliminarse antes de que tuvieran la oportunidad de migrarse.
Asignación de volúmenes de StorSimple a recursos




considerable.
 Sugerencia


asignación.


de Azure.
 Sugerencia
Azure por servidor.
） Importante

para crecer.


archivos


instalar el agente.

archivos de
Azure de destino
(igual que
anteriormente)

recursos origen.
compartidos de
archivos.
Mantenga el
número de
elementos por
grupo de
sincronización
por debajo de
100 millones de
elementos
(archivos y
carpetas) por
recurso
compartido.
Idealmente, es
mejor
permanecer por
debajo de 20 o
30 millones por
recurso
compartido.

cuenta de cuenta de
(asignación de
1:1) elementos por
grupo de
sincronización
por debajo de
100 millones de
elementos
(archivos y
carpetas) por
recurso
compartido.
Idealmente, es
mejor
permanecer por
debajo de 20 o
30 millones por
recurso
compartido.

recurso archivos de
Aunque un
grupo de
sincronización
puede tener
puntos de
conexión de
servidor en
distintos
servidores de
archivos, los
archivos no
pueden ser
distintos.



Número de cuentas de almacenamiento

Es probable que la migración se beneficie de una implementación de varias cuentas de
almacenamiento, cada una con un número de recursos compartidos de archivos de
Azure más reducido.
Si tiene recursos compartidos muy activos (utilizados por muchos usuarios o

aplicaciones), dos recursos compartidos de archivos de Azure podrían alcanzar el límite
de rendimiento de una cuenta de almacenamiento. Por este motivo, el procedimiento
recomendado es migrar a varias cuentas de almacenamiento, cada una con sus propios
recursos compartidos de archivos y, por lo general, no más de dos o tres recursos
compartidos por cuenta de almacenamiento.

de archivos de Azure en la misma cuenta de almacenamiento, en caso de que tenga
recursos compartidos de archivo.

Azure) que a Azure File Sync. Si tiene pensado usar exclusivamente Azure File Sync en
estos recursos compartidos, es correcta la agrupación de varios en una sola cuenta de
almacenamiento de Azure. En el futuro, se recomienda migrar mediante lift-and-shift
una aplicación a la nube que, a continuación, tendrá acceso directo a un recurso
compartido de archivos, ya que este escenario se beneficiará de tener más IOPS y
rendimiento. También puede empezar a usar un servicio de Azure que también se
beneficiará de tener un mayor IOPS y rendimiento.
Si ha creado una lista de recursos compartidos, asigne cada recurso compartido a la

cuenta de almacenamiento en la que residirá.
） Importante
Seleccione una región de Azure y asegúrese de que cada cuenta de

almacenamiento y recurso de Azure File Sync coinciden con la región que ha
seleccionado. No configure ahora las opciones de la red y del firewall para las
cuentas de almacenamiento. Realizar estas configuraciones en este momento haría
imposible la migración. Configure estas opciones de Azure Storage una vez
completada la migración.
Configuración de cuentas de almacenamiento

Hay muchas configuraciones que puede realizar en una cuenta de almacenamiento. La
siguiente lista de comprobación se debe usar para confirmar las configuraciones de la
cuenta de almacenamiento. Puede cambiar, por ejemplo, la configuración de red una
vez completada la migración.
＂ Recursos compartidos de archivos grandes: Habilitado. Los recursos compartidos de

archivos grandes mejoran el rendimiento y permiten almacenar hasta 100 TiB en un
recurso compartido. Esta configuración se aplica a las cuentas de almacenamiento
de destino con recursos compartidos de archivos de Azure.
＂ Firewall y redes virtuales: Deshabilitado. No configure restricciones de IP ni limite el
acceso de la cuenta de almacenamiento a una red virtual específica. El punto de
conexión público de la cuenta de almacenamiento se usa durante la migración. Se
deben permitir todas las direcciones IP de las máquinas virtuales de Azure. Es mejor
configurar las reglas de firewall en la cuenta de almacenamiento después de la
migración. Configure las cuentas de almacenamiento de origen y de destino de esta
manera.
＂ Puntos de conexión privados: Admitido. Puede habilitar puntos de conexión
privados, pero el punto de conexión público se usa para la migración y debe
permanecer disponible. Esta consideración se aplica a las cuentas de
almacenamiento de origen y de destino.
Resumen de la fase 1
Al final de la fase 1:
Conocerá bien sus volúmenes y dispositivos de StorSimple.

El servicio de Data Manager estará listo para acceder a los volúmenes de
StorSimple en la nube, ya que ha recuperado la "clave de cifrado de datos del
servicio" de cada dispositivo de StorSimple.
Tendrá un plan para el que se deben migrar los volúmenes y las copias de
seguridad (si hay alguno después de los más recientes).
Sabrá cómo asignar los volúmenes al número adecuado de recursos compartidos
de archivo y cuentas de almacenamiento de Azure.

migración y almacenamiento de Azure
En esta sección se explican las consideraciones sobre la implementación de los
diferentes tipos de recursos que se necesitan en Azure. Algunos contendrán los datos
después de la migración y otros solo se necesitan para la migración. No empiece a
implementar recursos hasta que haya finalizado el plan de implementación. Es difícil, y a
veces imposible, cambiar determinados aspectos de los recursos de Azure una vez que
se han implementado.
En este vídeo se describe la implementación de:
Cuentas de almacenamiento
Suscripciones y grupos de recursos
Cuentas de almacenamiento
Tipos y nombres
Rendimiento y tamaño de recurso compartido
Tipos de ubicación y replicación
Recursos compartidos de archivos de Azure
Servicio de StorSimple Data Manager
Implementación de cuentas de almacenamiento

Probablemente, tendrá que implementar varias cuentas de Azure Storage. Cada una de
ellas contendrá un número menor de recursos compartidos de archivos de Azure, según
el plan de implementación, completado en la sección anterior de este artículo. Vaya a
Azure Portal para implementar las cuentas de almacenamiento planeadas. Considere la
posibilidad de seguir la configuración básica de a continuación en cualquier cuenta de
almacenamiento nueva.
） Importante
No configure ahora las opciones de la red y del firewall para sus cuentas de
almacenamiento. Realizar esas configuraciones en este momento haría imposible la
migración. Configure estas opciones de Azure Storage una vez completada la
migración.
Subscription
Puede usar la misma suscripción que usó para la implementación de StorSimple o una
diferente. La única limitación es que la suscripción debe estar en el mismo inquilino de
Azure Active Directory que la suscripción de StorSimple. Considere la posibilidad de
mover la suscripción a StorSimple al inquilino adecuado antes de iniciar una migración.
Solo puede trasladar la suscripción en su conjunto; los recursos individuales de
StorSimple no se pueden trasladar a otro inquilino o suscripción.
Resource group
Los grupos de recursos ayudan con la organización de recursos y permisos de
administración de administradores. Obtenga más información sobre los grupos de
recursos de Azure.
Nombre de la cuenta de almacenamiento

El nombre de la cuenta de almacenamiento pasará a formar parte de una dirección URL
y tendrá ciertas limitaciones de caracteres. En su convención de nomenclatura, tenga en
cuenta que los nombres de las cuentas de almacenamiento deben ser únicos, tener solo
letras en minúsculas y números, contener entre 3 y 24 caracteres y no usar caracteres
especiales como guiones o caracteres de subrayado. Para obtener más información,
consulte Reglas de nomenclatura de recursos de almacenamiento de Azure.
Location
La ubicación o la región de Azure de una cuenta de almacenamiento son muy
importantes. Si usa Azure File Sync, todas las cuentas de almacenamiento deben estar
en la misma región que el recurso del servicio de sincronización de almacenamiento. La
región de Azure que elija debe ser cercana a los servidores y usuarios locales o ubicarse
en un punto céntrico. Una vez implementado el recurso, no se puede cambiar su región.
Puede elegir una región distinta de la ubicación en la que residen los datos de
StorSimple (cuenta de almacenamiento).
） Importante
Si elige una región diferente de la ubicación actual de la cuenta de almacenamiento

de StorSimple, se aplicarán cargos de salida durante la migración. Los datos
dejarán la región de StorSimple y entrarán en la nueva región de la cuenta de
almacenamiento. No se aplican cargos de ancho de banda si permanece dentro de
la misma región de Azure.
Rendimiento
Tiene la opción de elegir Premium Storage (SSD) para recursos compartidos de archivos
de Azure o almacenamiento estándar. El almacenamiento estándar incluye varios niveles
para un recurso compartido de archivos. Standard Storage es la opción adecuada para la
mayoría de los clientes que migran desde StorSimple.
¿Todavía no está seguro?
Elija Premium Storage si necesita el rendimiento de un recurso compartido de

archivos Premium de Azure.
Elija almacenamiento estándar para cargas de trabajo de servidor de archivos de
uso general, incluidos los datos de acceso frecuente y los datos de archivo. Elija
también almacenamiento estándar si la única carga de trabajo en el recurso
compartido en la nube será Azure File Sync.
En el caso de los recursos compartidos de archivos premium, elija Recursos
compartidos de archivos en el asistente para crear cuentas de almacenamiento.
Replicación
Hay varias configuraciones de replicación disponibles. Obtenga más información sobre

los diferentes tipos de replicación.
Solo tiene que elegir una de las dos opciones siguientes:
Almacenamiento con redundancia local (LRS) .

Almacenamiento con redundancia de zona (ZRS) , que no está disponible en todas
las regiones de Azure.
７ Nota
Solo los tipos de redundancia LRS y ZRS son compatibles con los recursos
compartidos de archivos de Azure de gran tamaño, de 100 TiB de capacidad.
El almacenamiento con redundancia geográfica (GRS) en todas las variaciones no se

admite actualmente. Puede cambiar el tipo de redundancia más tarde y a GRS cuando la
compatibilidad con este tipo llegue a Azure.
Habilitación de recursos compartidos de archivos de 100 TiB de

capacidad
Imagen que muestra la pestaña Opciones avanzadas en Azure Portal para la creación
de una cuenta de almacenamiento.
En la sección Opciones avanzadas del Asistente para nuevas cuentas de

almacenamiento de Azure Portal, puede habilitar la compatibilidad con recursos
compartidos de archivos grandes en esta cuenta de almacenamiento. Si esta opción no
está disponible, lo más probable es que haya seleccionado el tipo de redundancia
equivocado. Asegúrese de seleccionar solo LRS o ZRS para que esta opción esté
disponible.
Optar por los recursos compartidos de archivos de gran tamaño de 100 TiB tiene varias
ventajas:
El rendimiento aumenta considerablemente en comparación con los recursos

compartidos de archivos de menor capacidad, de 5 TiB (por ejemplo, 10 veces con
respecto a IOPS).
La migración finalizará mucho más rápido.
Asegúrese de que un recurso compartido de archivos tenga suficiente capacidad
para contener todos los datos que va a migrar a él, incluida la capacidad de
almacenamiento que requieren las copias de seguridad diferenciales.
El crecimiento futuro está cubierto con esta opción.
） Importante
No aplique redes especiales a la cuenta de almacenamiento antes ni durante la

migración. El punto de conexión público debe ser accesible en las cuentas de
almacenamiento de origen y de destino. No se admite ninguna limitación a
intervalos IP o redes virtuales específicos. Puede cambiar las configuraciones de red
de la cuenta de almacenamiento después de la migración.
Recursos compartidos de archivos de Azure

Una vez creadas las cuentas de almacenamiento, puede ir a la sección Recurso
compartido de archivos de la cuenta de almacenamiento e implementar el número
adecuado de recursos compartidos de archivos de Azure según el plan de migración de
la fase 1. Considere la posibilidad de usar la siguiente configuración básica para los
nuevos recursos compartidos de archivos de Azure.
Se admiten letras en minúsculas, números y guiones.
En este caso la cuota es comparable a una cuota fija de SMB en una instancia de
Windows Server. El procedimiento recomendado es no establecer una cuota en este
caso, ya que la migración y otros servicios producirán un error cuando se alcance.
Seleccione
para el nuevo recurso compartido de archivos. Durante la migración, se producirán
muchas transacciones. Es más rentable cambiar el nivel más adelante al nivel más
adecuado para la carga de trabajo.
StorSimple Data Manager

El recurso de Azure que contendrá los trabajos de migración se llama StorSimple Data
Manager. Seleccione Nuevo recurso y búsquelo. Seleccione Crear.
Este recurso temporal se usa para la orquestación. Se desaprovisiona una vez finalizada
la migración. Debe implementarse en la misma suscripción, grupo de recursos y región
que la cuenta de almacenamiento de StorSimple.
Azure File Sync
Con Azure File Sync, puede agregar almacenamiento en caché local de los archivos a los
que se accede con más frecuencia. De forma similar a las funcionalidades de
almacenamiento en caché de StorSimple, la característica de nube por niveles de Azure
File Sync ofrece latencia de acceso local en combinación con el control mejorado de la
funcionalidad de caché disponible en la instancia de Windows Server y en la
sincronización de varios sitios. Si el objetivo es tener una caché local, prepare una
máquina virtual de Windows Server (también se admiten servidores físicos y clústeres de
conmutación por error) en su red local con capacidad de almacenamiento conectado
directamente suficiente.
） Importante
No configure Azure File Sync todavía. Es mejor hacerlo después de completar la

migración del recurso compartido. La implementación de Azure File Sync no debe
iniciarse antes de la fase 4 de una migración.
Al final de la fase 2, habrá implementado sus cuentas de almacenamiento y todos los
recursos compartidos de archivos de Azure en ellas. También tendrá un recurso
StorSimple Data Manager. Usará este último en la fase 3, cuando configure los trabajos
de migración.
Fase 3: Creación y ejecución de un trabajo de

migración
En esta sección se describe cómo configurar un trabajo de migración y asignar
cuidadosamente los directorios de un volumen de StorSimple que debe copiarse en el
recurso compartido de archivos de Azure de destino que seleccione.
El vídeo trata de:
Creación de un trabajo de migración
Resumen
Source
Selección de copias de seguridad de volumen para migrar
Destino
Asignación de directorios
Reglas semánticas
Ejecución de un trabajo de migración
Ejecución de a definición de trabajo
Visualización del estado del trabajo
Ejecución de trabajos en paralelo
Interpretación de los archivos de registro
Para empezar, vaya a StorSimple Data Manager, busque Definiciones de trabajo en el

menú y seleccione + Definición de trabajo. El tipo de almacenamiento de destino
correcto es el valor predeterminado: Recurso compartido de archivos de Azure.
Nombre de definición de trabajoEste nombre indica el conjunto de archivos que se van
a mover. Le recomendamos que le asigne un nombre similar al recurso compartido de
archivos de Azure.
Al seleccionar una región, debe seleccionar la misma que la cuenta de almacenamiento

de StorSimple o, si no está disponible, otra cercana a ella.
Source
Suscripción de origenSeleccione la suscripción en la que almacena el recurso de
StorSimple Device Manager.
Seleccione la instancia de StorSimple Device Manager en la que el dispositivo esté

registrado.
Consulte
en caso de que no localice la clave en sus registros.
Seleccione el dispositivo de StorSimple que contiene el volumen que desee migrar.
Seleccione el volumen de origen. Más adelante decidirá si desea migrar el volumen o los
subdirectorios completos al recurso compartido de archivos de Azure de destino.
Volumen de copias de seguridad

Puede seleccionar Seleccionar volumen de las copias de seguridad para escoger copias
de seguridad específicas para mover como parte de esta tarea. En una sección específica
de este artículo se describe más adelante el proceso de manera detallada.
Destino
Seleccione la suscripción, la cuenta de almacenamiento y el recurso compartido de
archivos de Azure como destino de este trabajo de migración.
En una sección dedicada de este artículo, se describen todos los detalles pertinentes.
Selección de copias de seguridad de volumen para migrar

Hay algunos aspectos importantes relacionados con la elección de las copias de
seguridad que se deben migrar:
Los trabajos de migración solo pueden migrar copias de seguridad, no datos de un

volumen activo. Por lo tanto, la copia de seguridad más reciente es más cercana a
los datos activos y siempre debe incluirse en la lista de copias de seguridad que se
han trasladado en una migración. Al abrir el cuadro de diálogo Backup selection
(Selección de copia de seguridad), se selecciona de forma predeterminada.
Asegúrese de que la última copia de seguridad sea reciente para mantener el
tamaño del delta en el recurso compartido activo lo más pequeño posible. Podría
ser conveniente desencadenar y completar manualmente otra copia de seguridad
del volumen antes de crear un trabajo de migración. Un pequeño delta en el
recurso compartido activo mejorará la experiencia de migración. Si este delta
puede ser cero, significa que no se realizaron más cambios en el volumen de
StorSimple después de que se tomó la copia de seguridad más reciente de la lista.
Por lo tanto, la fase 5: migración total de los usuarios será significativamente más
sencilla y rápida.
Las copias de seguridad se deben reproducir en el recurso compartido de archivos
de Azure de la más antigua a la más reciente. Una copia de seguridad antigua no
se puede "ordenar" en la lista de copias de seguridad del recurso compartido de
archivos de Azure una vez que se ha ejecutado un trabajo de migración. Por lo
tanto, debe asegurarse de que la lista de copias de seguridad se ha completado
antes de crear un trabajo.
Esta lista de copias de seguridad de un trabajo no se puede modificar cuando se
ha creado el trabajo, si este nunca se ejecutó.
Para seleccionar copias de seguridad, el volumen de StorSimple que se quiere
migrar debe estar en línea.
Para seleccionar copias de seguridad del volumen de StorSimple para el trabajo de

migración, seleccione la opción Select volume backups (seleccionar copias de seguridad
del volumen) en el formulario de creación de trabajos.

Cuando se abre la hoja de selección de copias de seguridad, está dividida en dos listas.
En la primera lista, se muestran todas las copias de seguridad disponibles. Puede
expandir y reducir el conjunto de resultados al usar un intervalo de tiempo específico
como filtro. (Véase la siguiente sección)
Una copia de seguridad seleccionada se mostrará atenuada y se agregará a una

segunda lista en la parte inferior de la hoja. La segunda lista muestra todas las copias de
seguridad seleccionadas para la migración. Una copia de seguridad seleccionada
accidentalmente también se puede volver a quitar.
Ｕ Precaución
Debe seleccionar todas las copias de seguridad que quiera migrar. No se pueden
agregar copias de seguridad más antiguas después. No se puede modificar el
trabajo para cambiar la selección una vez que se ha creado el trabajo.

De manera predeterminada, la lista se filtra para mostrar las copias de seguridad de

volúmenes de StorSimple de los últimos siete días. La copia de seguridad más reciente
está seleccionada de manera predeterminada aunque no se haya hecho en los últimos
siete días. Para las copias de seguridad anteriores, use el filtro de intervalo de tiempo en
la parte superior de la hoja. Puede seleccionar uno de los filtros existentes o establecer
un intervalo de tiempo personalizado para filtrar solo las copias de seguridad realizadas
durante ese período.
Ｕ Precaución
No se admite la selección de más de 50 copias de seguridad de volumen de

StorSimple. Se puede producir un error en los trabajos con un gran número de
copias de seguridad. ¡Asegúrese de que las directivas de retención de copia de
seguridad no eliminen una copia de seguridad seleccionada antes de poder
migrarla!
La asignación de directorios es opcional para el trabajo de migración. Si deja la sección
vacía, todos los archivos y las carpetas de la raíz del volumen de StorSimple se moverán
a la raíz del recurso compartido de archivos de Azure de destino. En la mayoría de los
casos, almacenar el contenido de un volumen completo en un recurso compartido de
archivos de Azure no es el mejor enfoque. A menudo, es mejor dividir el contenido de
un volumen en varios recursos compartidos de archivos de Azure. Si aún no ha hecho
un plan, consulte antes Asignación del volumen de StorSimple a recursos compartidos
Como parte del plan de migración, es posible que haya decidido que las carpetas de un
volumen de StorSimple deben dividirse en varios recursos compartidos de archivos de
Azure. En ese caso, puede realizar esa división de la siguiente manera:
1. Definiendo varios trabajos para migrar las carpetas de un volumen, cada uno
tendrá el mismo origen de volumen de StorSimple, pero un recurso compartido de
archivos de Azure diferente como destino.
2. Especificando con precisión qué carpetas del volumen de StorSimple se deben
migrar al recurso compartido de archivos especificado, mediante la sección de
asignación de directorios del formulario de creación del trabajo y siguiendo la
semántica de asignación específica.
） Importante
Las rutas de acceso y las expresiones de asignación de este formulario no se

pueden validar cuando se envía el formulario. Si se especifican las asignaciones
incorrectamente, puede producirse un error en el trabajo o un resultado no
deseado. En ese caso, suele ser mejor eliminar el recurso compartido de archivos
de Azure, volver a crearlo y, a continuación, corregir las instrucciones de asignación
en un nuevo trabajo de migración del recurso compartido. La ejecución de un
nuevo trabajo con instrucciones de asignación fija puede corregir carpetas omitidas
y colocarlas en el recurso compartido existente. Sin embargo, solo las carpetas que
se omitieron debido a errores de escritura en la ruta de acceso se pueden
solucionar de esta manera.
Elementos semánticos
Una asignación se expresa de izquierda a derecha: [\ruta de acceso de origen] > [\ruta
de acceso de destino].
Carácter semántico Significado
\ Indicador de nivel raíz.
> Operador de asignación de [origen] y [destino].
| o RETURN (nueva línea) Separador de dos instrucciones de asignación de carpetas.

También puede omitir este carácter y seleccionar
para obtener la siguiente expresión de asignación en su propia línea.
Ejemplos
Mueve el contenido de la carpeta Datos de usuario a la raíz del recurso compartido de
archivos de destino:
Consola
\User data > \
Mueve todo el contenido del volumen a una nueva ruta de acceso en el recurso
compartido de archivos de destino:
Consola
\ > \Apps\HR tracker
Mueve el contenido de la carpeta de origen a una nueva ruta de acceso en el recurso

compartido de archivos de destino:
Consola
\HR resumes-Backup > \Backups\HR\resumes
Ordena varias ubicaciones de origen en una nueva estructura de directorios:
Consola
\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker

\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived
Reglas semánticas
Especifique siempre las rutas de acceso de la carpeta en relación con el nivel raíz.
Comience cada ruta de acceso de carpeta con un indicador de nivel de raíz "\".
No incluya letras de unidad.
Si especifica varias rutas de acceso, las rutas de origen o destino no se pueden
superponer:
Ejemplo de superposición de ruta de origen no válida:
Ejemplo de superposición de ruta de destino no válida:

>
Se omitirán las carpetas de origen que no existen.

Se crearán las estructuras de carpetas que no existen en el destino.
Al igual que Windows, los nombres de carpeta no distinguen mayúsculas de
minúsculas, pero sí se conservan.
７ Nota
El trabajo de migración no copiará el contenido de la carpeta \System Volume

Information y $Recycle.Bin en el volumen de StorSimple.
Ejecución de un trabajo de migración

Los trabajos de migración aparecen debajo de Definiciones de trabajos en el recurso de
Data Manager que ha implementado en un grupo de recursos. En la lista de definiciones
de trabajos, seleccione el trabajo que quiere ejecutar.
En la hoja de trabajo que se abre, puede ver el estado actual del trabajo y una lista de
las copias de seguridad que ha seleccionado. La lista de copias de seguridad se ordena
de más antigua a más reciente y se migrará al recurso compartido de archivos de Azure
en este orden.
Inicialmente, el trabajo de migración tendrá el estado: Never ran (Nunca ejecutado).

Cuando esté listo, puede iniciar este trabajo de migración. (Seleccione la imagen de una
versión con mayor resolución).
Cuando se haya migrado correctamente una copia de seguridad, se realizará una
instantánea automática del recurso compartido de archivos de Azure. La fecha de la
copia de seguridad original de StorSimple se colocará en la sección Comentarios de la
instantánea del recurso compartido de archivos de Azure. El uso de este campo le
permitirá ver cuándo se ha realizado originalmente la copia de seguridad de los datos
en comparación con el momento en que se hizo la instantánea del recurso compartido
de archivos.
Ｕ Precaución
Las copias de seguridad deben procesarse de más antigua a más reciente. Una vez
creado un trabajo de migración, no se puede cambiar la lista de copias de
seguridad de volúmenes StorSimple seleccionados. No inicie el trabajo si la lista de
copias de seguridad es incorrecta o está incompleta. Elimine el trabajo y realice uno
nuevo con las copias de seguridad correctas seleccionadas. Para cada copia de
seguridad seleccionada, compruebe las programaciones de retención. ¡Es posible
que una o varias de las directivas de retención eliminen las copias de seguridad
antes de que puedan migrarse!
Per-item errors (Errores por elemento)

Los trabajos de migración tienen dos columnas en la lista de copias de seguridad que
enumeran cualquier problema que se pueda haber producido durante la copia:
Errores de copia
En esta columna se enumeran los archivos o carpetas que no se han copiado pero
deberían haberlo hecho. Estos errores suelen ser recuperables. Cuando una copia
de seguridad muestra problemas de elementos en esta columna, revise los
registros de copia. Si necesita migrar estos archivos, seleccione Retry backup
(Reintentar copia de seguridad). Esta opción estará disponible una vez que finalice
el procesamiento de la copia de seguridad. En la sección Managing a migration job
(Administración de un trabajo de migración) se explican las opciones con más
detalle.
Archivos no admitidos
En esta columna se enumeran los archivos o carpetas que no se pueden migrar.
Azure Storage tiene limitaciones en los nombres de archivo, las longitudes de ruta
de acceso y los tipos de archivo que no se pueden almacenar actualmente o de
forma lógica en un recurso compartido de archivos de Azure. Un trabajo de
migración no se pausará ante este tipo de errores. Volver a intentar la migración
de la copia de seguridad no cambiará el resultado. Cuando una copia de seguridad
muestra problemas de elementos en esta columna, revise los registros de copia y
tome nota de ellos. Si estos problemas surgen en la última copia de seguridad y en
el registro de la copia observa que el error se debió a un nombre de archivo, una
longitud de ruta de acceso u otro problema sobre el que tiene influencia, es
posible que quiera solucionar el problema en el volumen StorSimple activo, hacer
una copia de seguridad del volumen StorSimple y crear un nuevo trabajo de
migración solo con esa copia de seguridad. A continuación, migrará este espacio
de nombres corregido y se convertirá en la versión activa/más reciente del recurso
compartido de archivos de Azure. Se trata de un proceso manual y lento. Revise
cuidadosamente los registros de copia y evalúe si merece la pena.
Estos registros son archivos *.csv en los que se muestran los elementos de espacio de
nombres correctos y los elementos que no se han podido copiar. Los errores se dividen
aún más en las categorías que se han analizado anteriormente. En la ubicación del
archivo de registro, puede buscar registros de archivos con errores buscando "error". El
resultado debería ser un conjunto de registros de los archivos que no se pudieron
copiar. Ordene estos registros por tamaño. Puede haber registros adicionales generados
con un tamaño de 17 bytes. Están vacíos y se pueden omitir. Mediante la ordenación,
puede concentrarse en los registros con contenido.
El mismo proceso se aplica a los archivos de registro que graban copias correctas.
Administración de un trabajo de migración

Los trabajos de migración tienen los siguientes estados:
Nunca ejecutadoNuevo trabajo que se ha definido, pero que no se ha ejecutado

hasta el momento.
En esperaUn trabajo en este estado está esperando a que los recursos se
aprovisionen en el servicio de migración. Cambiará automáticamente a un estado
diferente cuando esté listo.
Con errorUn trabajo ha generado un error irrecuperable que impide que se
procesen más copias de seguridad. No se espera que un trabajo entre en este
estado. La mejor forma de actuar es enviar una solicitud de soporte técnico.
CanceladoCancelandoEs posible cancelar un trabajo de migración completo o
copias de seguridad específicas dentro del trabajo. Las copias de seguridad
canceladas no se procesarán; un trabajo de migración cancelado dejará de
procesar más copias de seguridad. Tenga en cuenta que la cancelación de un
trabajo llevará mucho tiempo. Esto no impedirá que cree un nuevo trabajo. Tenga
paciencia para permitir que un trabajo llegue completamente al estado Cancelado.
Puede ignorar los trabajos con errores/cancelados o eliminarlos más adelante. No
tendrá que eliminar trabajos antes de poder eliminar el recurso Data Manager al
final de la migración de StorSimple.

En ejecución
Un trabajo en ejecución es aquel que está procesando una copia de seguridad. Consulte
la tabla de la mitad inferior de la hoja para ver qué copia de seguridad se está
procesando actualmente y cuáles pueden haber sido ya migradas.
Las copias de seguridad ya migradas tienen una columna con un vínculo a un registro
de copia. Si se notifican errores para una copia de seguridad, debe revisar su registro de
copia.
En pausa
Un trabajo de migración se pausa cuando se necesita tomar una decisión. Esta situación
habilita dos botones de comando en la parte superior de la hoja:
Elija
cuando la copia de seguridad muestre los archivos que deberían haberse movido pero
no lo hicieron (columna Errores de copia).
Elija
cuando no haya una copia de seguridad (la ha eliminado la directiva al crear el trabajo
de migración) o cuando la copia de seguridad esté dañada. Puede encontrar
información de error detallada en la hoja que se abre al hacer clic en la copia de
seguridad fallida.
Si
o
la copia de seguridad en curso, el servicio de migración creará una instantánea en el
recurso compartido de archivos de Azure de destino. Quizá quiera eliminar la anterior
más adelante, es probable que esté incompleta.
Completado y Completado con advertenciasUn trabajo de migración aparece como

Completado cuando todas las copias de seguridad del trabajo se han procesado
correctamente.
es un estado que se da en las siguientes situaciones:

Una copia de seguridad tuvo un problema recuperable. Esta copia de seguridad se
marca como parcialmente correcta o con errores.
Ha decidido continuar con el trabajo en pausa omitiendo la copia de seguridad
con estos problemas. (Eligió Omitir la copia de seguridad en lugar de Retry backup
[Reintentar copia de seguridad])
Si el trabajo de migración se completa con advertencias, siempre debe revisar el registro
de copia de las copias de seguridad pertinentes.
Ejecución de trabajos en paralelo
Es probable que tenga varios volúmenes de StorSimple, cada uno con sus propios
recursos compartidos que deben migrarse a un recurso compartido de archivos de
Azure. Es importante que comprenda cuánto puede hacer en paralelo. Hay limitaciones
que no se aplican en la experiencia del usuario y que degradarán o impedirán una
migración completa si los trabajos se ejecutan al mismo tiempo.
No hay límites en la definición de trabajos de migración. Puede definir el mismo
volumen de origen de StorSimple, el mismo recurso compartido de archivos de Azure,
en el mismo o en distintos dispositivos StorSimple. Sin embargo, su ejecución tiene
limitaciones:
Solo se puede ejecutar un trabajo de migración con el mismo volumen de origen

de StorSimple al mismo tiempo.
Solo se puede ejecutar al mismo tiempo un trabajo de migración con el mismo
recurso compartido de archivos de Azure de destino.
Antes de iniciar el siguiente trabajo, debe asegurarse de que cualquiera de los
trabajos anteriores se encuentra en copy stage y muestra el progreso del
movimiento de archivos durante al menos 30 minutos.
Puede ejecutar hasta cuatro trabajos de migración en paralelo por administrador
de dispositivos de StorSimple, siempre que también cumpla las reglas anteriores.
Al intentar iniciar un trabajo de migración, se comprueban las reglas anteriores. Si hay

trabajos en ejecución, es posible que no pueda iniciar el trabajo actual. Recibirá una
alerta que muestra el nombre de los trabajos que se están ejecutando actualmente que
deben finalizar antes de poder iniciar el nuevo trabajo.
 Sugerencia
Es una buena idea comprobar periódicamente los trabajos de migración en la

pestaña Definición de trabajo del recurso Data Manager para ver si alguno de ellos
se ha pausado y necesita una acción por su parte para completarse.
Al final de la fase 3, habrá ejecutado al menos uno de los trabajos de migración desde
los volúmenes de StorSimple en recursos compartidos de archivos de Azure. Con la
ejecución, habrá migrado las copias de seguridad especificadas a las instantáneas del
recurso compartido de archivos de Azure. Ahora puede centrarse en la configuración de
Azure File Sync del recurso compartido (cuando se hayan completado los trabajos de
migración de un recurso compartido) o el direccionamiento del acceso compartido para
las aplicaciones y los trabajadores de la información al recurso compartido de archivos
de Azure.
Fase 4: Acceso a los recursos compartidos de

archivos de Azure
Hay dos estrategias principales para acceder a los recursos compartidos de archivos de
Azure:
Azure File Sync: implementar Azure File Sync en una instancia de Windows Server
local. Azure File Sync tiene todas las ventajas de una memoria caché local, al igual
que StorSimple.
Acceso directo a recursos compartidos: Implementación de acceso directo a
recursos compartidos. Use esta estrategia si su escenario de acceso para un
recurso compartido de archivos de Azure determinado no se beneficiará del
almacenamiento en caché local o ya no es posible hospedar una instancia de
Windows Server. Aquí, los usuarios y las aplicaciones seguirán teniendo acceso a
los recursos compartidos de SMB a través del protocolo SMB. Estos recursos
compartidos ya no están en un servidor local, sino directamente en la nube.
Ya debe haber decidido qué opción es la más adecuada en la fase 1 de esta guía.
El resto de esta sección se centra en las instrucciones de implementación.
El vídeo trata de:

Enfoques para acceder a recursos compartidos de archivos de Azure
Azure File Sync
Acceso directo a recursos compartidos
Implementación del recurso de nube de Azure File Sync
Implementación de una instancia de Windows Server local
Preparación de la instancia de Windows Server para la sincronización de archivos
Configuración de Azure File Sync en la instancia de Windows Server
Supervisión de la sincronización inicial
Probar Azure File Sync
Creación de recursos compartidos SMB
Es el momento de implementar una parte de Azure File Sync.
1. Cree el recurso de nube de Azure File Sync.

2. Implemente el agente de Azure File Sync en el servidor local.
3. Registre el servidor con el recurso de nube.
No cree todavía ningún grupo de sincronización. La configuración de la sincronización

con un recurso compartido de archivos de Azure solo debe realizarse una vez que se
hayan completado los trabajos de migración a un recurso compartido de archivos de
Azure. Si empezó a usar Azure File Sync antes de que se complete la migración, hará
que la migración sea innecesariamente difícil, ya que no es fácil saber cuándo es el
momento de iniciar un recorte.
Implementación del recurso de nube de Azure File Sync


almacenamiento.

 Sugerencia
Si desea cambiar la región de Azure en la que residen los datos cuando se realiza la
migración, implemente el servicio de sincronización de almacenamiento en la
misma región que las cuentas de almacenamiento de destino para esta migración.
Implementación de una instancia de Windows Server local

Cree un servidor de Windows Server 2019 (como mínimo de la edición 2012 R2),
como una máquina virtual o un servidor físico. También se admite un clúster de
conmutación por error de Windows Server. No reutilice el servidor que tenga
delante de StorSimple 8100 u 8600.
Aprovisione o agregue almacenamiento de conexión directa. No se admite el
almacenamiento conectado a la red.
Es un procedimiento recomendado otorgar a la nueva instancia de Windows Server una

cantidad igual o superior de almacenamiento de la que dispone la aplicación
StorSimple 8100 o 8600 localmente para el almacenamiento en caché. Usará la instancia
de Windows Server del mismo modo que usó el dispositivo StorSimple. Si tiene la
misma cantidad de almacenamiento que el dispositivo, la experiencia de
almacenamiento en caché debe ser similar, si no es la misma. Puede agregar o eliminar
almacenamiento de la instancia de Windows Server según lo desee. Esto le permitirá
escalar el tamaño del volumen local y la cantidad de almacenamiento local disponible
para el almacenamiento en caché.
Preparación de la instancia de Windows Server para la

sincronización de archivos
Windows Server.

problema.
PowerShell

File Sync.
Configuración de Azure File Sync en la instancia de Windows Server

） Importante
Antes de continuar, debe completar la migración de archivos y carpetas de
StorSimple en el recurso compartido de archivos de Azure. Asegúrese de que no
haya más cambios en el recurso compartido de archivos.

） Importante
Asegúrese de activar la nube por niveles. La nube por niveles es la característica de

Azure File Sync que permite al servidor local tener menos capacidad de
almacenamiento de la que está almacenada en la nube y, a pesar de ello, disponer
de todo el espacio de nombres. Los datos localmente interesantes también se
almacenan en caché para conseguir un rendimiento rápido y de acceso local. Otro
motivo para activar la nube por niveles en este paso es que no queremos
sincronizar el contenido del archivo en esta fase. En este momento solo se debe
mover el espacio de nombres.
Implementación de acceso directo a recursos

compartidos
Al final de esta fase ha creado y ejecutado varios trabajos de migración en StorSimple
Data Manager. Esos trabajos han migrado los archivos y carpetas y sus copias de
seguridad a recursos compartidos de archivos de Azure. También ha implementado
Azure File Sync o preparado las cuentas de red y almacenamiento para el acceso directo
a recursos compartidos.

Esta fase se centra simplemente en resumir la migración:
Planee el tiempo de inactividad.

Póngase al día con cualquier cambio que los usuarios y las aplicaciones hayan
generado en StorSimple mientras se han estado ejecutando los trabajos de
migración en la fase 3.
Conmute por error a los usuarios a la nueva instancia de Windows Server con
Azure File Sync o los recursos compartidos de archivos de Azure a través del
acceso directo a recursos compartidos.
El vídeo trata de:

Pasos que se deben realizar antes de la transición de la carga de trabajo
Ejecución de la transición
Pasos posteriores a la migración
Planeación del tiempo de inactividad

Este enfoque de migración requiere cierto tiempo de inactividad para los usuarios y las
aplicaciones. El objetivo es mantener un tiempo de inactividad mínimo. Las siguientes
consideraciones pueden ayudar:
Mantenga los volúmenes de StorSimple disponibles mientras ejecuta los trabajos

de migración.
Cuando haya terminado de ejecutar los trabajos de migración de datos de un
recurso compartido, podrá quitar el acceso de usuario (al menos el acceso de
escritura) de los volúmenes o recursos compartidos de StorSimple. Un comando
RoboCopy final pondrá en marcha el recurso compartido de archivos de Azure.
Después, podrá migrar a los usuarios. El lugar en el que se ejecute RoboCopy
dependerá de si ha elegido usar Azure File Sync o el acceso directo a recursos
compartidos. En la próxima sección sobre RoboCopy se explica este asunto.
Una vez completada la puesta al día de RoboCopy, está listo para exponer la nueva
ubicación a los usuarios mediante el recurso compartido de archivos de Azure
directamente o un recurso compartido de SMB en una instancia de
Windows Server con Azure File Sync. A menudo, una implementación de DFS-N lo
ayudará a realizar una migración rápida y eficaz. Mantendrá coherentes las
direcciones de los recursos compartidos actuales y llevará a cabo la redirección a
una nueva ubicación que contenga los archivos y carpetas migrados.
Para los datos de archivo, es un enfoque totalmente viable tomar el tiempo de

inactividad en el volumen de StorSimple (o subcarpeta), hacer una copia de seguridad
más del volumen de StorSimple, migrar y, a continuación, abrir el destino de la
migración para que los usuarios y las aplicaciones puedan acceder a ellos. Esto le
ahorrará la necesidad de una copia de seguridad de RoboCopy como se describe en
esta sección. Sin embargo, este enfoque conlleva un período de tiempo de inactividad
prolongado que podría extenderse a varios días o más dependiendo del número de
archivos y copias de seguridad que necesite migrar. Es probable que esto solo sea una
opción para las cargas de trabajo de archivo que puedan prescindir del acceso de
escritura durante períodos prolongados de tiempo.
Determinación de si el espacio de nombres se ha

sincronizado por completo en el servidor
Cuando se usa Azure File Sync para un recurso compartido de archivos de Azure, es
importante que se determine que todo el espacio de nombres ha terminado de
descargarse en el servidor antes de iniciar cualquier comando RoboCopy local. El tiempo
necesario para descargar el espacio de nombres depende del número de elementos del
recurso compartido de archivos de Azure. Existen dos métodos para determinar si el
espacio de nombres se ha trasladado por completo al servidor.
Azure portal
Puede usar Azure Portal para ver cuándo ha llegado por completo el espacio de
nombres.
Inicie sesión en Azure Portal y vaya al grupo de sincronización. Compruebe el

estado de sincronización del grupo de sincronización y el punto de conexión del
servidor.
Se descarga la dirección de interés. Si el punto de conexión del servidor se ha
aprovisionado recientemente, se mostrará la sincronización inicial, que indica que
el espacio de nombres sigue estando disponible. Una vez que cambia el estado a
cualquier valor excepto el de sincronización inicial, el espacio de nombres se
rellenará por completo en el servidor. Está listo para continuar con un comando
RoboCopy local.
Visor de eventos de Windows Server
También puede usar el Visor de eventos en la instancia de Windows Server para saber
cuándo se ha trasladado por completo el espacio de nombres.
1. Abra el Visor de eventos y vaya a Aplicaciones y servicios.

2. Vaya a Microsoft\FileSync\Agent\Telemetry y ábralo.
3. Busque el evento 9102 más reciente, el cual se corresponde con una sesión de
sincronización completada.
4. Seleccione Detalles y confirme que está examinando un evento en el que el valor
SyncDirection es Descargar.
5. En el momento en que el espacio de nombres ha finalizado su descarga en el
servidor, habrá un único evento con Escenario, valor FullGhostedSync y HResult0.
6. Si no está ese evento, también puede buscar otros eventos 9102 con
SyncDirectionDescargar y Escenario"RegularSync". La búsqueda de uno de estos
eventos también indica que el espacio de nombres se ha terminado de descargar y
la sincronización ha progresado a sesiones regulares de sincronización, haya o no
algo que sincronizar, en este momento.
Un comando RoboCopy final.

En este momento, hay diferencias entre el servidor de la instancia de Windows Server
local y la aplicación StorSimple 8100 u 8600.
1. Debe ponerse al día con los cambios que los usuarios o las aplicaciones generan
en StorSimple mientras la migración estaba en curso.
2. En los casos en los que se usa Azure File Sync: La aplicación StorSimple tiene una
memoria caché llena en comparación con la instancia de Windows Server que, en
este momento, solo tiene un espacio de nombres sin ningún contenido de
archivos almacenado localmente. Por lo tanto, el comando RoboCopy final puede
ayudar a iniciar la memoria caché de Azure File Sync local al extraer tanto
contenido del archivo almacenado en memoria caché local como esté disponible y
puede ajustarse al servidor de Azure File Sync.
3. Es posible que el trabajo de migración haya omitido algunos archivos debido a
caracteres no válidos. Si es así, cópielos en la instancia de Windows Server
habilitada para Azure File Sync. Más adelante, puede ajustarlos para que se
sincronicen. Si no usa Azure File Sync para un recurso compartido determinado, es
mejor cambiar el nombre de los archivos por caracteres no válidos en el volumen
de StorSimple. Después, ejecute RoboCopy directamente en el recurso compartido
２ Advertencia
En la actualidad, Robocopy en Windows Server 2019 experimenta un problema que

provocará que los archivos organizados por niveles con Azure File Sync en el
servidor de destino se copien nuevamente desde el origen y se vuelvan a cargar en
Azure cuando se usa la función /MIR de Robocopy. Es indispensable que use
Robocopy en una versión de Windows Server que no sea 2019. La mejor opción es
Windows Server 2016. Esta nota se actualizará en caso de que el problema se
resuelva a través de Windows Update.
２ Advertencia
No debe iniciar RoboCopy antes de que el servidor tenga el espacio de nombres de

un recurso compartido de archivos de Azure descargado completamente. Para
obtener más información, consulte Determinación de si el espacio de nombres se
ha sincronizado por completo en el servidor.
Solo desea copiar los archivos que se cambiaron después de la última vez que se
ejecutó el trabajo de migración y los archivos que no se trasladaron antes a través de
estos trabajos. Puede solucionar el problema por el que no se trasladaron al servidor,
una vez que haya finalizado la migración. Para más información, vea Solución de
problemas de Azure File Sync.
RoboCopy tiene varios parámetros. El siguiente ejemplo muestra un comando

terminado y una lista de razones para elegir estos parámetros.
Consola

<FilePathAndName>
Modificador Significado

un buen rendimiento, pero solo si los procesadores pueden mantenerlos activos al
mismo tiempo.

espera que causaron errores en el pasado. Esto puede ser más habitual a través de
vínculos WAN. Elija no reintentarlo o un valor de uno si cree que el archivo no se
pudo copiar porque estaba en uso de forma activa. Volver a intentarlo unos


destino.

Azure.




Information oculta. Si se usa como está previsto, toda la información que contiene
es específica del volumen exacto en este sistema exacto y se puede recompilar a
petición. Copiar esta información no será útil en la nube ni cuando los datos se
vuelvan a copiar en otro volumen Windows. Dejar este contenido atrás no debe
considerarse una pérdida de datos.


relacionados.

） Importante
Cuando configure las ubicaciones de origen y de destino del comando RoboCopy,

asegúrese de revisar la estructura de origen y de destino para asegurarse de que
coinciden. Si usó la característica de asignación de directorios del trabajo de migración,
la estructura del directorio raíz puede ser diferente de la estructura del volumen de
StorSimple. En ese caso, puede que necesite varios trabajos de RoboCopy, uno para
cada subdirectorio. Si no está seguro de si el comando se ejecutará según lo previsto,
puede usar el parámetro /L, que simulará el comando sin realizar realmente ningún
cambio.
Este comando RoboCopy usa /MIR, por lo que no moverá archivos que sean iguales
(archivos en capas, por ejemplo). Pero si obtiene incorrectamente la ruta de acceso de
origen y destino, /MIR también purga las estructuras de directorio en su instancia de
Windows Server o en el recurso compartido de archivos de Azure que no están
presentes en la ruta de acceso de origen de StorSimple. Deben coincidir exactamente
para que el trabajo de RoboCopy alcance su objetivo de actualizar el contenido migrado
con los últimos cambios realizados durante la migración.
Consulte los archivos de registro de RoboCopy para ver si se han omitido archivos. Si
existen problemas, corríjalos y vuelva a ejecutar el comando RoboCopy. No
desaprovisione los recursos de StorSimple antes de corregir los problemas pendientes
de los archivos o carpetas que le interesan.
Si no usa Azure File Sync para almacenar en caché el recurso compartido de archivos de
Azure en cuestión, sino que ha optado por el acceso directo a recursos compartidos:
1. Monte el recurso compartido de archivos de Azure como una unidad de red en

una máquina local de Windows.
2. Ejecute el comando de RoboCopy entre StorSimple y el recurso compartido de
archivos de Azure montado. Si los archivos no se copian, corrija sus nombres en
StorSimple para quitar los caracteres no válidos. A continuación, vuelva a intentar
la ejecución de RoboCopy. El comando RoboCopy de la lista anterior se puede
ejecutar varias veces sin provocar una recuperación innecesaria en StorSimple.
Solución de problemas y optimización

de varios factores:

nombres.

IOPS.
transferencia.
Ｕ Precaución





determinada.


 Sugerencia
copia.


intentarlo.

importante:
Windows Server 2022 y RoboCopy LFSM

El modificador RoboCopy /LFSM se puede usar para evitar que un trabajo de RoboCopy
produzca un error tipo Volumen lleno. RoboCopy se pondrá en pausa siempre que una
copia de archivo haga que el espacio disponible del volumen de destino se sitúe por
debajo de un valor mínimo.
Use RoboCopy con Windows Server 2022. Solo esta versión de RoboCopy contiene
correcciones de errores importantes y características que hacen que el conmutador sea
compatible con marcas adicionales necesarias en la mayoría de las migraciones. Por
ejemplo, compatibilidad con la marca /B .
/B ejecuta Robocopy en el mismo modo que usaría una aplicación de copia de
seguridad. Este conmutador permite que Robocopy mueva los archivos para los que el
usuario actual no tiene permisos.
Normalmente, RoboCopy se puede ejecutar en el origen, en el destino o en una tercera

máquina.
） Importante
Si tiene previsto usar /LFSM , RoboCopy debe ejecutarse en el servidor de Azure File
Sync con Windows Server 2022 de destino.
Tenga en cuenta también que, con /LFSM , también debe usar una ruta de acceso local
para el destino, no una UNC. Por ejemplo, como ruta de acceso de destino, debe usar
E:\NombreDeLaCarpeta en lugar de una ruta de acceso UNC como
\\ServerName\NombreDeLaCarpeta.
Ｕ Precaución
La versión disponible actualmente de RoboCopy en Windows Server 2022 tiene un

error que hace que las pausas se incluyan en el recuento de errores por archivo.
Aplique la siguiente solución alternativa.
Las marcas recomendadas /R:2 /W:1 aumentan la probabilidad de que se produzca un

error en un archivo debido a una pausa /LFSM inducida. En este ejemplo, un archivo que
no se copió después de tres pausas porque /LFSM provocó la pausa, hará que
RoboCopy produzca un error incorrecto en el archivo. La solución alternativa para esto
es usar valores mayores para /R:n y /W:n . Un buen ejemplo es /R:10 /W:1800
(10 reintentos de 30 minutos cada uno). Esto debe dar tiempo al algoritmo de niveles de
Azure File Sync para crear espacio en el volumen de destino.
Este error se ha corregido, pero la corrección aún no está disponible públicamente.

Compruebe este párrafo en busca de actualizaciones de disponibilidad de la corrección
y cómo implementarla.
Migración total de los usuarios

Si usa Azure File Sync, es probable que tenga que crear los recursos compartidos de
SMB en esa instancia de Windows Server habilitada para Azure File Sync que coincida
con los recursos compartidos que tenía en los volúmenes de StorSimple. Puede
adelantar este paso y hacerlo antes para no perder tiempo aquí. Pero debe asegurarse
de que antes de este punto nadie tenga acceso para realizar cambios en la instancia de
Windows Server.
Si tiene una implementación de DFS-N, puede apuntar los espacios de nombres de DFN
a las nuevas ubicaciones de carpetas del servidor. Si no tiene una implementación de
DFS-N y ha adelantado el dispositivo 8100/8600 localmente con una instancia de
Windows Server, puede desconectar el servidor del dominio. Después, únase al dominio
nuevo en la instancia de Windows Server habilitada para Azure File Sync. Durante ese
proceso, asigne al servidor el mismo nombre de servidor y los nombres de los recursos
compartidos que en el servidor anterior, de modo que el acceso directo sea
transparente para los usuarios, la directiva de grupo y los scripts.
Más información sobre DFS-N.
Fase 6: Desaprovisionar
Cuando se desaprovisiona un recurso, se pierde el acceso a la configuración de ese
recurso, así como a sus datos. El aprovisionamiento no se puede deshacer. No continúe
hasta que haya confirmado que:
La migración se ha completado.
No hay ninguna dependencia en los archivos, carpetas o copias de seguridad del
volumen de StorSimple que está a punto de desaprovisionar.
Antes de empezar, es un procedimiento recomendado observar la nueva

implementación de Azure File Sync en producción durante un tiempo. Esto le ofrece la
oportunidad de corregir los problemas que puedan surgir. Una vez que haya observado
la implementación de Azure File Sync durante al menos unos días, puede empezar a
desaprovisionar los recursos en este orden:
1. Desaprovisione el recurso de StorSimple Data Manager a través de Azure Portal.

Todos los trabajos de DTS se eliminarán con él. No podrá recuperar fácilmente los
registros de copia. Si es importante para los registros, puede recuperarlos antes de
desaprovisionarlos.
2. Asegúrese de que se han migrado las aplicaciones físicas de StorSimple y, a
continuación, anule su registro. Si no está seguro de que se han migrado, no
continúe. Si quita el aprovisionamiento de estos recursos mientras siguen siendo
necesarios, no podrá recuperar los datos ni su configuración.
Opcionalmente, puede desaprovisionar primero el recurso de volumen de
StorSimple, lo cual limpiará los datos del dispositivo. Este proceso puede tardar
varios días y no pondrá a cero los datos del dispositivo de manera forense. Si esto
es importante para usted, administre la puesta a cero del disco por separado del
desaprovisionamiento de recursos y de acuerdo con sus directivas.
3. Si no quedan más dispositivos registrados en StorSimple Device Manager, puede
continuar para quitar ese recurso de Device Manager.
4. Ahora es el momento de eliminar la cuenta de almacenamiento de StorSimple en
Azure. Una vez más, deténgase en este punto y confirme que la migración se ha
completado y no hay nada que dependa de estos datos antes de continuar.
5. Desconecte el dispositivo físico de StorSimple del centro de datos.
6. Si es el propietario del dispositivo de StorSimple, puede reciclar el equipo. Si el
dispositivo está concedido, informe al arrendador y devuélvalo según corresponda.
La migración se ha completado.
７ Nota
¿Todavía tiene preguntas o ha detectado algún problema?

Estamos aquí para ayudarle:
Al usar el servicio de migración de StorSimple Data Manager, es posible que se
produzca un error en un trabajo de migración completo o en archivos individuales por
varios motivos. La sección de fidelidad de archivos tiene más detalles sobre los
escenarios admitidos o no admitidos. En las tablas siguientes se enumeran los códigos
de error, los detalles de error y, siempre que sea posible, las opciones de mitigación.
Errores de nivel de trabajo
Fase Error Detalles / mitigación
Backup No se pudo La copia de seguridad seleccionada para la ejecución del

encontrar una copia trabajo no se encuentra en el momento de "Estimación" o
de seguridad de los "Copia". Asegúrese de que la copia de seguridad todavía
parámetros está presente en el catálogo de copia de seguridad de
especificados StorSimple. A veces, las directivas de retención de copia
de seguridad automáticas eliminan copias de seguridad
en los pasos intermedios entre seleccionar las copias para
migración y ejecutar el trabajo de migración para su
volcado. Considere la posibilidad de deshabilitar cualquier
programación de retención de copia de seguridad antes
de iniciar una migración.
Configuración Hubo un error en la Su clave de cifrado de datos de servicio es incorrecta.

de instalación de las Revise la sección de clave de cifrado de este artículo para
la estimación claves de cifrado más detalles y ayuda para recuperar la clave correcta.
del proceso
Error de lote Es posible que iniciar toda la infraestructura interna

necesaria para realizar una migración produzca una
incidencia. Muchos otros servicios están implicados en
este proceso. Por lo general, estos problemas se resuelven
por sí solos al intentar volver a ejecutar el trabajo.
StorSimple Manager Este error genérico tiene varias causas, pero una de las
encontró un error posibilidades es que el administrador de dispositivos de
interno. Espere unos StorSimple alcanzó el límite de 50 dispositivos.
minutos y vuelva a Compruebe si los trabajos de ejecución más recientes en
intentar la el administrador de dispositivos se han iniciado
operación. Si el repentinamente para producir este error, lo que sugeriría
problema persiste, que este es el problema. La mitigación de este problema
póngase en en particular consiste en quitar los dispositivos sin
contacto con el conexión de StorSimple 8001 que el servicio de
Soporte técnico de Data Manager ha creado y usado. Puede presentar una
Microsoft. (Código incidencia de soporte técnico o eliminarlas manualmente
de error: en el portal. Asegúrese de eliminar solo los dispositivos
1074161829) sin conexión de la serie 8001.
Cálculo de Error en el trabajo Este error probablemente indica que especificó una copia
archivos de clonación de de seguridad que estaba dañada de alguna manera. El
volumen servicio de migración no puede montarlo ni leerlo. Puede
probar la copia de seguridad manualmente o abrir una
incidencia de soporte técnico.
No se puede Solo el servicio de migración puede usar volúmenes NTFS,

continuar porque el habilitados sin eliminación de réplicas. Si tiene un
volumen está en volumen con formato diferente, como ReFS o un formato
formato no NTFS de terceros, el servicio de migración no podrá migrar este
volumen. Consulte la sección sobre las Restricciones
conocidas.
Póngase en El disco de StorSimple que se supone que tiene el

contacto con el volumen especificado para la migración no parece tener
servicio de soporte una partición para dicho volumen. Esto es inusual y puede
técnico. No se indicar daños o mala alineación de la administración. La
encontró ninguna única opción para investigar aún más esta incidencia es
partición adecuada presentar una incidencia de soporte técnico.
en el disco
Tiempo de espera La fase de estimación que produce un error en tiempo de

agotado espera suele ser una incidencia con el dispositivo
StorSimple, o que la copia de seguridad del volumen de
origen es lenta y a veces incluso está dañada. Si volver a
ejecutar la copia de seguridad no lo soluciona, la
presentación de una incidencia de soporte técnico es la
mejor opción.
No se encontró la La definición del trabajo permite proporcionar una

<ruta de acceso> subruta de acceso de origen. Este error se muestra
del archivo cuando esa ruta de acceso no existe. Por ejemplo: \Share1
No se encontró una > \Share\Share1
parte de la ruta de En este ejemplo ha especificado \Share1 como subruta de
acceso acceso en el origen, que asigna otra subruta de acceso en
el destino. Pero la ruta de acceso de origen no existe (¿se
ha escrito mal?). Nota: Windows conserva mayúsculas y
minúsculas, pero no depende de ellas. Lo que significa
que especificar \Share1 y \share1 es equivalente. Además:
las rutas de acceso de destino que no existen se crearán
de forma automática.
Esta solicitud no Este error muestra cuándo la cuenta de almacenamiento

está autorizada a de StorSimple de origen o la cuenta de almacenamiento
realizar esta de destino con el recurso compartido de archivos de
operación Azure tiene habilitada una configuración de firewall. Debe
permitir el tráfico a través del punto de conexión público y
no restringirlo con más reglas de firewall. De lo contrario,
el servicio de transformación de datos no podrá acceder a
ninguna cuenta de almacenamiento, incluso si lo autorizó.
Deshabilite las reglas de firewall y vuelva a ejecutar el
trabajo.
Copia de La cuenta a la que Se trata de un error de Azure Files que se está

archivos se está accediendo corrigiendo. La mitigación temporal consiste en
no admite HTTP deshabilitar el enrutamiento de Internet en la cuenta de
almacenamiento de destino o usar el punto de conexión
de enrutamiento de Microsoft.
El recurso Si el destino es un recurso compartido de archivos

compartido premium de Azure, asegúrese de que ha aprovisionado
especificado está suficiente capacidad para el recurso compartido. El
lleno sobreaprovisionamiento temporal es una práctica común.
Si el destino es un recurso compartido de archivos de
Azure estándar, compruebe que el recurso compartido de
destino tiene habilitada la característica "large file share"
(recurso compartido de archivo grande). El
almacenamiento Estándar crece a medida que se usa el
recurso compartido. Pero si usa una cuenta de
almacenamiento antigua como destino, es posible que
encuentre un límite de recursos compartidos de 5 TiB.
Tendrá que habilitar manualmente la característica
"Recurso compartido de archivos grande". Corrija los
límites en el destino y vuelva a ejecutar el trabajo.
Errores de nivel de elemento
Durante la fase de copia de una ejecución de trabajo de migración, los elementos de
espacio de nombres individuales (archivos y carpetas) pueden detectar errores. En la
tabla siguiente se enumeran los errores más comunes y se sugieren opciones de
mitigación cuando sea posible.
Fase Error Mitigación
Copiar -2146233088 Vuelva a ejecutar el trabajo si hay demasiados errores. Si solo hay
El servidor unos pocos errores, puede intentar volver a ejecutar el trabajo, pero
está a menudo una copia manual de los elementos con errores es más
ocupado. rápida. Después, reanude la migración omitiendo el procesamiento
de la siguiente copia de seguridad.
-2146233088 Vuelva a ejecutar el trabajo si hay demasiados errores. Si solo hay

La operación unos pocos errores, puede intentar volver a ejecutar el trabajo, pero
no se pudo a menudo una copia manual de los elementos con errores es más
completar en rápida. Después, reanude la migración omitiendo el procesamiento
el tiempo de la siguiente copia de seguridad.
especificado.
Se agotó el Vuelva a ejecutar el trabajo si hay demasiados errores. Si solo hay

tiempo de unos pocos errores, puede intentar volver a ejecutar el trabajo, pero
espera de la a menudo una copia manual de los elementos con errores es más
carga o no se rápida. Después, reanude la migración omitiendo el procesamiento
inició la de la siguiente copia de seguridad.
copia
-2146233029 Vuelva a ejecutar el trabajo si hay demasiados errores. Si solo hay

Se canceló la unos pocos errores, puede intentar volver a ejecutar el trabajo, pero
operación. a menudo una copia manual de los elementos con errores es más
rápida. Después, reanude la migración omitiendo el procesamiento
de la siguiente copia de seguridad.
1920 Este es un error común cuando el motor de migración encuentra un

El sistema no punto de repetición de análisis, un vínculo o una unión. No se
tiene acceso admiten. Estos tipos de archivos no se pueden copiar. Revise la
al archivo. sección Restricciones conocidas y la sección Fidelidad de archivos
de este artículo.
-2147024891 Se trata de un error para los archivos que se cifran de forma que no
Acceso se puede acceder a ellos en el disco. Los archivos que se pueden
denegado leer desde el disco, pero simplemente tienen contenido cifrado, no
se ven afectados y se pueden copiar. La única opción es copiarlos
de forma manual. Puede encontrar estos elementos mediante el
montaje del volumen afectado y la ejecución del siguiente
comando: get-childitem <path> [-Recurse] -Force -ErrorAction
SilentlyContinue | Where-Object {$_.Attributes -ge "Encrypted"}
| format-list fullname, attributes
No es un En este caso, se puede tener acceso al archivo, pero no se puede

parámetro evaluar para la copia porque una marca de tiempo de la que
FileTime de depende el motor de migración está dañada o está escrita por una
Win32 aplicación en un formato incorrecto. No hay mucho que pueda
válido. hacer, ya que no puede cambiar la marca de tiempo de la copia de
Nombre del seguridad. Si conservar este archivo es importante, quizás en la
parámetro: versión más reciente (última copia de seguridad que contiene este
fileTime archivo), copie manualmente el archivo, corrija la marca de tiempo
y, después, muévala al recurso compartido de archivos de Azure de
destino. Esta opción no se escala muy bien, pero es una opción
para los archivos de alto valor en los que desea tener al menos una
versión conservada en el destino.
-2146232798 A menudo, un error transitorio. Vuelva a ejecutar el trabajo si hay

Se ha demasiados errores. Si solo hay unos pocos errores, puede intentar
cerrado el volver a ejecutar el trabajo, pero a menudo una copia manual de
controlador los elementos con errores es más rápida. Después, reanude la
seguro migración omitiendo el procesamiento de la siguiente copia de
seguridad.
-2147024413 Este es un error poco frecuente y, de hecho, no se notifica para un

Error de dispositivo físico, sino más bien para las aplicaciones virtualizadas
hardware de la serie 8001 que usa el servicio de migración. El dispositivo tuvo
irrecuperable un problema. Los archivos con este error no impedirán que la
del migración continúe con la siguiente copia de seguridad. Esto hace
dispositivo que sea difícil realizar una copia manual o volver a intentar la copia
de seguridad que contiene archivos con este error. Si los archivos
que dejan atrás son muy importantes o hay un gran número de
archivos, es posible que tenga que volver a iniciar la migración de
todas las copias de seguridad. Abra una incidencia de soporte
técnico para una investigación más detallada.
Eliminación El directorio Este error se produce cuando el modo de migración se establece en

(purga de especificado reflejo y el proceso que quita los elementos del recurso compartido
reflejo) no está vacío. de archivos de Azure generó un problema que impidió que
eliminara elementos. La eliminación solo se produce en el recurso
compartido activo, no en las instantáneas anteriores. La eliminación
es necesaria porque los archivos afectados no están en la copia de
seguridad actual y, por tanto, deben quitarse del recurso
compartido activo antes de la siguiente instantánea. Hay dos
opciones: Opción 1: montar el recurso compartido de archivos de
Azure de destino y eliminar los archivos con este error de forma
manual. Opción 2: puede omitir estos errores y continuar
procesando la siguiente copia de seguridad con una expectativa de
que el destino no es idéntico al origen y tiene algunos elementos
adicionales que no estaban en la copia de seguridad de StorSimple
original.
Solicitud Este error indica que el archivo de origen tiene ciertas

incorrecta características que no se pudieron copiar en el recurso compartido
de archivos de Azure. En particular, podría haber caracteres de
control invisibles en un nombre de archivo o 1 byte de un carácter
de doble byte en el nombre de archivo o la ruta de acceso del
archivo. Puede usar los registros de copia para obtener nombres de
ruta de acceso, copiar los archivos en una ubicación temporal,
cambiar el nombre de las rutas de acceso para quitar los caracteres
no admitidos y, luego, volver a usar robocopy en el recurso
compartido de archivos de Azure. Después, puede reanudar la
migración omitiendo la siguiente copia de seguridad que se va a
procesar.
Pasos siguientes
Familiarícese con Azure File Sync: aka.ms/AFS.
Obtenga información sobre la flexibilidad de las directivas de nube por niveles.
Habilite Azure Backup en los recursos compartidos de archivos de Azure para
programar instantáneas y definir programaciones de retención de copia de
seguridad.
Si ve en Azure Portal que algunos archivos no se sincronizan de forma
permanente, revise la guía de solución de problemas para conocer los pasos
necesarios para resolverlos.
Migración de StorSimple 1200 a Azure
File Sync
Artículo • 22/03/2023
StorSimple de la serie 1200 es una aplicación virtual que se ejecuta en un centro de

datos local. Los datos de esta aplicación se pueden migrar a un entorno de Azure File
Sync. Azure File Sync es el servicio de Azure a largo plazo, estratégico y predeterminado
al que se pueden migrar los dispositivos StorSimple. En este artículo se proporcionan los
conocimientos básicos y los pasos de migración necesarios para realizar una migración
correcta a Azure File Sync.
７ Nota
El servicio StorSimple (incluido el Administrador de dispositivos de StorSimple para

las series 8000 y 1200 y StorSimple Data Manager) ha llegado al final de la fase de
soporte técnico. El final del soporte técnico de StorSimple se publicó en 2019 en las
páginas Política del ciclo de vida de Microsoft y Comunicaciones de Azure . Se
enviaron notificaciones adicionales por correo electrónico y se publicaron en Azure
Portal y en la información general de StorSimple. Póngase en contacto con el
servicio de Soporte técnico de Microsoft para obtener más información.
Se aplica a
Azure File Sync

Azure File Sync es un servicio en la nube de Microsoft, que se basa en dos componentes
principales:
Sincronización de archivos y nube por niveles.

Recursos compartidos de archivos como almacenamiento nativo en Azure, a los
que se puede acceder a través de varios protocolos, como SMB y REST de archivos.
Un recurso compartido de archivos de Azure es comparable a uno de un servidor
de Windows Server y este último se puede montar de forma nativa como una
unidad de red. Admite aspectos importantes de la fidelidad de los archivos, como
atributos, permisos y marcas de tiempo. A diferencia de StorSimple, no se requiere
ninguna aplicación ni ningún servicio para interpretar los archivos y las carpetas
almacenados en la nube. Enfoque ideal y más flexible para almacenar los datos del
servidor de archivos de uso general, así como algunos datos de aplicaciones, en la
nube.
Este artículo se centra en los pasos de migración. Si antes de la migración desea obtener
más información sobre Azure File Sync, se recomienda consultar los siguientes artículos:

Guía de implementación de Azure File Sync
El objetivo es garantizar la integridad de los datos de producción, así como la
disponibilidad. Esta última requiere que el tiempo de inactividad sea mínimo, para
ajustarse o solo superar ligeramente las ventanas de mantenimiento regulares.
Ruta de migración de StorSimple 1200 a Azure

File Sync
Se requiere un servidor de Windows Server local para ejecutar un agente de Azure File
Sync. La edición de Windows Server debe ser como mínimo 2012 R2, pero lo ideal es
que sea Windows Server 2019.
Existen numerosas rutas de acceso de migración alternativas y se necesitaría un artículo

demasiado largo para documentarlas e ilustrar por qué implican riesgos o desventajas
sobre la ruta sugerida como procedimiento recomendado en este artículo.
En la imagen anterior se muestran los pasos que corresponden a las secciones de este
artículo.
Paso 1: Aprovisionar el almacenamiento y servidor de

Windows Server locales
1. Cree un servidor de Windows Server 2019 (como mínimo de la edición 2012 R2),
como una máquina virtual o un servidor físico. También se admite un clúster de
conmutación por error de Windows Server.
2. Aprovisione o agregue almacenamiento de conexión directa (DAS frente a NAS,
que no se admite). El tamaño del almacenamiento de Windows Server debe ser
igual o mayor que el tamaño de la capacidad disponible de la aplicación virtual
StorSimple 1200.
Paso 2: Configurar el almacenamiento de Windows Server

En este paso, debe asignar la estructura de almacenamiento de StorSimple (volúmenes y
recursos compartidos) a la estructura de almacenamiento de Windows Server. Si tiene
previsto realizar cambios en la estructura de almacenamiento, es decir, el número de
volúmenes, la asociación de carpetas de datos a volúmenes o la estructura de
subcarpetas encima o debajo de los recursos compartidos de SMB/NFS actuales, ahora
es el momento de tener en cuenta estos cambios. Cambiar la estructura de archivos y
carpetas después de configurar Azure File Sync, es un proceso complicado que debe
evitarse. En este artículo se supone que realiza una asignación 1:1, por lo que debe tener
en cuenta los cambios de asignación al seguir los pasos de este artículo.
Ninguno de los datos de producción debe acabar en el volumen del sistema de
Windows Server. La nube por niveles no se admite en los volúmenes del sistema.
Sin embargo, esta característica es necesaria para la migración, así como para las
operaciones continuas como reemplazo de StorSimple.
Aprovisione el mismo número de volúmenes en el servidor de Windows Server que
tiene en la aplicación virtual StorSimple 1200.
Defina los roles, las características y las configuraciones de Windows Server que
necesite. Se recomienda participar en las actualizaciones de Windows Server para
mantener el sistema operativo protegido y actualizado. Del mismo modo, se
recomienda optar por Microsoft Update para mantener las aplicaciones de
Microsoft actualizadas, incluido el agente de Azure File Sync.
No configure carpetas ni recursos compartidos antes de leer los pasos siguientes.
Paso 3: Implementar el primer recurso de nube de Azure

File Sync

almacenamiento.

Paso 4: Conciliar la estructura de carpetas y el volumen

local con los recursos de Azure File Sync y los recursos



considerable.
 Sugerencia


asignación.


de Azure.
 Sugerencia
Azure por servidor.
） Importante

para crecer.


archivos


instalar el agente.

archivos de
Azure de destino
(igual que
anteriormente)

recursos origen.
compartidos de
archivos.
Mantenga el
número de
elementos por
grupo de
sincronización
por debajo de
100 millones de
elementos
(archivos y
carpetas) por
recurso
compartido.
Idealmente, es
mejor
permanecer por
debajo de 20 o
30 millones por
recurso
compartido.

cuenta de cuenta de
(asignación de
1:1) elementos por
grupo de
sincronización
por debajo de
100 millones de
elementos
(archivos y
carpetas) por
recurso
compartido.
Idealmente, es
mejor
permanecer por
debajo de 20 o
30 millones por
recurso
compartido.

recurso archivos de
Aunque un
grupo de
sincronización
puede tener
puntos de
conexión de
servidor en
distintos
servidores de
archivos, los
archivos no
pueden ser
distintos.



Paso 5: Aprovisionar los recursos compartidos de archivos

de Azure
rendimiento.


ellas.

Ｕ Precaución

homólogos locales.
Configuración de cuentas de almacenamiento
Hay muchas configuraciones que puede realizar en una cuenta de almacenamiento. La

siguiente lista de comprobación se debe usar para las configuraciones de la cuenta de
almacenamiento. Puede cambiar, por ejemplo, la configuración de red una vez
completada la migración.
＂ Recursos compartidos de archivos grandes: Habilitado. Los recursos compartidos de

archivos grandes mejoran el rendimiento y permiten almacenar hasta 100 TiB en un
recurso compartido.
＂ Firewall y redes virtuales: Deshabilitado. No configure restricciones de IP ni limite el
acceso de la cuenta de almacenamiento a una red virtual específica. El punto de
conexión público de la cuenta de almacenamiento se usa durante la migración. Se
deben permitir todas las direcciones IP de las máquinas virtuales de Azure. Es mejor
configurar las reglas de firewall en la cuenta de almacenamiento después de la
migración.
＂ Puntos de conexión privados: Admitido. Puede habilitar puntos de conexión
privados, pero el punto de conexión público se usa para la migración y debe
permanecer disponible.
Paso 6: Configurar las carpetas de destino de Windows

Server
En los pasos anteriores, ha tenido en cuenta todos los aspectos que determinarán los
componentes de las topologías de sincronización. Ahora es el momento de preparar el
servidor para recibir los archivos para la carga.
Cree todas las carpetas, cada una de las cuales se sincronizará con su propio recurso
compartido de archivos de Azure. Es importante seguir la estructura de carpetas que ha
documentado anteriormente. Si, por ejemplo, ha decidido sincronizar varios recursos
compartidos de SMB locales en un único recurso compartido de archivos de Azure,
deberá colocarlos en una carpeta raíz común en el volumen. Cree esta carpeta raíz de
destino en el volumen ahora.
El número de recursos compartidos de archivos de Azure que ha aprovisionado debe

coincidir con el número de carpetas que ha creado en este paso y con el número de
volúmenes que sincronizará en el nivel raíz.
Paso 7: Implementar el agente de Azure File Sync
Windows Server.

problema.
PowerShell


File Sync.
Paso 8: Configurar la sincronización


２ Advertencia
Asegúrese de activar la nube por niveles. Esta acción es necesaria si el servidor

local no tiene espacio suficiente para almacenar el tamaño total de los datos en el
almacenamiento en la nube de StorSimple. De forma temporal para realizar la
migración, establezca la directiva de almacenamiento por niveles en el 99 % de
espacio disponible en el volumen.
recursos compartidos de archivos de Azure o las ubicaciones del servidor, que deban
Paso 9: Copiar los archivos

El enfoque de migración básico es una ejecución de RoboCopy de la aplicación virtual
StorSimple a Windows Server y Azure File Sync a recursos compartidos de archivos de
Azure.
Identifique la primera ubicación en la aplicación virtual StorSimple.

Identifique la carpeta coincidente en el servidor de Windows Server, que ya tiene
Inicie la copia con RoboCopy.
El siguiente comando RoboCopy recuperará los archivos del almacenamiento de

StorSimple en Azure al almacenamiento de StorSimple local y, a continuación, los
moverá a la carpeta de destino de Windows Server. Windows Server los sincronizará con
los recursos compartidos de archivos de Azure. A medida que el volumen local de
Windows Server se llena, la nube por niveles se iniciará y organizará por niveles los
archivos que ya se han sincronizado correctamente. La nube por niveles generará
espacio suficiente para continuar con la copia desde la aplicación virtual StorSimple. La
nube por niveles realiza comprobaciones cada hora para averiguar qué se ha
sincronizado y para liberar espacio en disco para alcanzar el 99 % de espacio libre del
volumen.
Consola

<FilePathAndName>

un buen rendimiento, pero solo si los procesadores pueden mantenerlos activos al
mismo tiempo.

espera que causaron errores en el pasado. Esto puede ser más habitual a través de
vínculos WAN. Elija no reintentarlo o un valor de uno si cree que el archivo no se
pudo copiar porque estaba en uso de forma activa. Volver a intentarlo unos


destino.

Azure.




Information oculta. Si se usa como está previsto, toda la información que contiene
es específica del volumen exacto en este sistema exacto y se puede recompilar a
petición. Copiar esta información no será útil en la nube ni cuando los datos se
vuelvan a copiar en otro volumen Windows. Dejar este contenido atrás no debe
considerarse una pérdida de datos.


relacionados.

） Importante
Al ejecutar el comando de RoboCopy por primera vez, los usuarios y las aplicaciones
siguen accediendo a los archivos y las carpetas de StorSimple y pueden realizar
cambios. Es posible que RoboCopy haya procesado un directorio, pase al siguiente y, a
continuación, un usuario de la ubicación de origen (StorSimple) agregue, cambie o
elimine un archivo que no se procesará en la ejecución de RoboCopy actual. No hay
problema.
La primera ejecución consiste en mover la mayor parte de los datos de nuevo al entorno
local, a través de Windows Server, y realizar una copia de seguridad en la nube a través
de Azure File Sync. Esta operación puede tardar mucho tiempo, dependiendo de lo
siguiente:

La velocidad de recuperación del servicio en la nube de StorSimple.
El número de elementos (archivos y carpetas) que debe procesar cada servicio.
posteriores a la última ejecución. Es probable que estos cambios ya sean locales para
StorSimple, porque son recientes. Esto reduce aún más el tiempo, ya que se reduce la
necesidad de la recuperación de la nube. Durante esta segunda ejecución, todavía se
pueden acumular nuevos cambios.
Repita este proceso hasta que considere que la cantidad de tiempo que tarda en
completarse es un tiempo de inactividad aceptable.
Cuando considere el tiempo de inactividad aceptable y esté preparado para dejar sin
conexión la ubicación de StorSimple, hágalo. Por ejemplo, quite el recurso compartido
de SMB para que ningún usuario pueda acceder a la carpeta o realice cualquier otro
paso adecuado que impida que el contenido cambie en esta carpeta en StorSimple.
haberse omitido. El tiempo necesario para realizar este último paso dependerá de la
anterior.

de StorSimple.

un volumen o una raíz comunes. (En función de lo que haya asignado y decidido que
debe incluirse en el mismo recurso compartido de archivos de Azure).
２ Advertencia
Cuando haya movido todos los datos de su instancia de StorSimple a

Windows Server y se haya completado la migración, vuelva a todos los grupos de
sincronización de Azure Portal y ajuste el valor porcentual de espacio libre en el
volumen de la nube por niveles a un valor más adecuado para el uso de la memoria
caché, por ejemplo, un 20 %.

de espacio libre en disco, lo que hará que la memoria caché local no funcione según lo
previsto. A menos que sea su objetivo tener solamente el espacio de nombres para un
volumen que solo contiene datos de archivo a los que se accede con poca frecuencia.
El problema que puede experimentar más probablemente, es que el comando de
RoboCopy produzca el error "Volumen lleno" en el lado de Windows Server. En ese caso,
es probable que la velocidad de descarga sea mejor que la de carga. La nube por niveles
actúa una vez cada hora para evacuar el contenido del disco local de Windows Server,
que se ha sincronizado.

Cuando Windows Server tenga capacidad suficiente disponible, el problema se resolverá

al volver a ejecutar el comando. Si se da esta situación, no se interrumpe nada y puede
avanzar con confianza. La única consecuencia es el inconveniente de tener que volver a
ejecutar el comando.
También puede experimentar otros problemas de Azure File Sync. Si esto sucede,
consulte Guía de solución de problemas de Azure File Sync.

de varios factores:

nombres.

IOPS.
transferencia.
Ｕ Precaución






determinada.


 Sugerencia
copia.

intentarlo.

importante:
Windows Server 2022 y RoboCopy LFSM

El modificador RoboCopy /LFSM se puede usar para evitar que un trabajo de RoboCopy
produzca un error tipo Volumen lleno. RoboCopy se pondrá en pausa siempre que una
copia de archivo haga que el espacio disponible del volumen de destino se sitúe por
debajo de un valor mínimo.
Use RoboCopy con Windows Server 2022. Solo esta versión de RoboCopy contiene
correcciones de errores importantes y características que hacen que el conmutador sea
compatible con marcas adicionales necesarias en la mayoría de las migraciones. Por
ejemplo, compatibilidad con la marca /B .
/B ejecuta Robocopy en el mismo modo que usaría una aplicación de copia de
seguridad. Este conmutador permite que Robocopy mueva los archivos para los que el
usuario actual no tiene permisos.
Normalmente, RoboCopy se puede ejecutar en el origen, en el destino o en una tercera

máquina.
） Importante
Si tiene previsto usar /LFSM , RoboCopy debe ejecutarse en el servidor de Azure File
Sync con Windows Server 2022 de destino.
Tenga en cuenta también que, con /LFSM , también debe usar una ruta de acceso local
para el destino, no una UNC. Por ejemplo, como ruta de acceso de destino, debe usar
E:\NombreDeLaCarpeta en lugar de una ruta de acceso UNC como
\\ServerName\NombreDeLaCarpeta.
Ｕ Precaución
La versión disponible actualmente de RoboCopy en Windows Server 2022 tiene un

error que hace que las pausas se incluyan en el recuento de errores por archivo.
Aplique la siguiente solución alternativa.
Las marcas recomendadas /R:2 /W:1 aumentan la probabilidad de que se produzca un

error en un archivo debido a una pausa /LFSM inducida. En este ejemplo, un archivo que
no se copió después de tres pausas porque /LFSM provocó la pausa, hará que
RoboCopy produzca un error incorrecto en el archivo. La solución alternativa para esto
es usar valores mayores para /R:n y /W:n . Un buen ejemplo es /R:10 /W:1800
(10 reintentos de 30 minutos cada uno). Esto debe dar tiempo al algoritmo de niveles de
Azure File Sync para crear espacio en el volumen de destino.
Este error se ha corregido, pero la corrección aún no está disponible públicamente.

Compruebe este párrafo en busca de actualizaciones de disponibilidad de la corrección
y cómo implementarla.
７ Nota
¿Todavía tiene preguntas o ha detectado algún problema?

Estamos aquí para ayudar:
Vínculos pertinentes
Contenido de migración:
Guía de migración de StorSimple serie 8000
Contenido de Azure File Sync:

Guía de solución de problemas de Azure File Sync
Configuración de las cadenas de
conexión de Azure Storage
Artículo • 21/10/2023
Una cadena de conexión incluye la información de autorización que requiere la

aplicación para acceder a los datos de una cuenta de Azure Storage en tiempo de
ejecución mediante autorización de clave compartida. Las cadenas de conexión se
pueden configurar para:
Conectarse al emulador de almacenamiento Azurite.

Acceder a la cuenta de Azure Storage.
Acceder a recursos especificados en Azure a través de una firma de acceso
compartido (SAS).
Para información sobre cómo ver las claves de acceso a la cuenta y copiar una cadena
de conexión, consulte Administración de las claves de acceso de la cuenta de
almacenamiento.
Protección de las claves de acceso

Las claves de acceso de la cuenta de almacenamiento proporcionan acceso total a la
configuración de una cuenta de almacenamiento, así como a los datos. Siempre debe
proteger las claves de acceso. Use Azure Key Vault para administrar y rotar las claves de
forma segura. El acceso a la clave compartida concede a un usuario acceso total a la
configuración de una cuenta de almacenamiento y sus datos. El acceso a las claves
compartidas debe estar cuidadosamente limitado y supervisado. Use tokens de SAS con
un ámbito limitado de acceso en escenarios en los que no se puede usar la autorización
basada en Microsoft Entra ID. Evite codificar de forma rígida las claves de acceso o
guardarlas en cualquier lugar en texto sin formato que sea accesible a otras personas.
Rote las claves si cree que se pudieron haber puesto en peligro.
） Importante
Microsoft recomienda usar Microsoft Entra ID para autorizar solicitudes de datos de

blobs, colas y tablas si es posible, en lugar de usar las claves de cuenta
(autorización con clave compartida). La autorización con Microsoft Entra ID
proporciona más seguridad y facilidad de uso que la autorización con clave
compartida. Para obtener más información sobre el uso de la autorización de
Microsoft Entra desde las aplicaciones, consulte Cómo autenticar aplicaciones
.NET con servicios de Azure. En el caso de los recursos compartidos de archivos
SMB de Azure, Microsoft recomienda usar la integración de Active Directory
Domain Services (AD DS) local o la autenticación Kerberos de Microsoft Entra.
Para evitar que los usuarios accedan a los datos de la cuenta de almacenamiento
con una clave compartida, puede impedir la autorización con clave compartida
para la cuenta de almacenamiento. Se recomienda un acceso granular a los datos
con privilegios mínimos necesarios como procedimiento recomendado de
seguridad. La autorización basada en Microsoft Entra ID se debe usar para
escenarios que admiten OAuth. Kerberos o SMTP se deben usar para Azure Files a
través de SMB. Para Azure Files a través de REST, se pueden usar tokens de SAS. El
acceso a la clave compartida debe deshabilitarse si no es necesario para evitar su
uso accidental. Para obtener más información, consulte Impedir la autorización
con clave compartida para una cuenta de Azure Storage.
Para proteger una cuenta de Azure Storage con las directivas de acceso condicional
de Microsoft Entra, no debe permitir la autorización de clave compartida para la
Si ha deshabilitado el acceso con claves compartidas y está viendo la autorización

de clave compartida notificada en los registros de diagnóstico, esto indica que se
usa el acceso de confianza para acceder al almacenamiento. Para obtener más
detalles, consulte Acceso de confianza para los recursos registrados en su
suscripción.
Almacenamiento de una cadena de conexión

La aplicación necesita acceder a la cadena de conexión en tiempo de ejecución para
autorizar las solicitudes realizadas a Azure Storage. Tiene varias opciones para
almacenar las claves de acceso o la cadena de conexión de su cuenta:
Puede almacenar las claves de la cuenta de forma segura en Azure Key Vault. Para
obtener más información, consulte Acerca de las claves de cuentas de
almacenamiento administradas de Azure Key Vault.
Puede almacenar la cadena de conexión en una variable de entorno.
Una aplicación puede almacenar la cadena de conexión en un archivo app.config o
web.config. Agregue la cadena de conexión a la sección AppSettings en estos
archivos.
２ Advertencia
Almacenar las claves de acceso o la cadena de conexión de su cuenta en texto no
cifrado supone un riesgo de seguridad y no se recomienda. Almacene las claves de
la cuenta en un formato cifrado o migre las aplicaciones para usar la autorización
de Microsoft Entra para acceder a la cuenta de almacenamiento.
Configuración de una cadena de conexión para

Azurite
El emulador es compatible con una sola cuenta fija y una clave de autenticación ya
conocida para la autenticación de clave compartida. Esta cuenta y clave son las únicas
credenciales de clave compartida que se admiten para su uso con el emulador. Son las
siguientes:
Account name: devstoreaccount1

Account key:
Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KB
HBeksoGMGw==
７ Nota
La clave de autenticación admitida por el emulador está pensada para comprobar

únicamente la funcionalidad de su código de autenticación de cliente. No responde
a ningún propósito de seguridad. No puede utilizar la cuenta de almacenamiento y
la clave de producción con el emulador. Se debe tener en cuenta que no se puede
utilizar la cuenta de desarrollo con datos de producción.
El emulador admite solo la conexión a través de HTTP. Sin embargo, HTTPS es el

protocolo recomendado para obtener acceso a recursos en una cuenta de
producción de Azure Storage.
Conexión a la cuenta del emulador mediante el acceso directo
La manera más fácil de conectarse al emulador desde la aplicación consiste en

configurar, dentro del archivo de configuración de la aplicación, una cadena de
conexión que haga referencia al acceso directo UseDevelopmentStorage=true . El acceso
directo equivale a la cadena de conexión completa para el emulador, que especifica el
nombre de la cuenta, la clave de cuenta y los puntos de conexión del emulador para
cada uno de los servicios de Azure Storage:
DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;
AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1
SZFPTOtr/KBHBeksoGMGw==;
BlobEndpoint=http://127.0.0.1:10000/devstoreaccount1;
QueueEndpoint=http://127.0.0.1:10001/devstoreaccount1;
TableEndpoint=http://127.0.0.1:10002/devstoreaccount1;
El siguiente fragmento de código de .NET muestra cómo se puede usar el acceso directo
desde un método que toma una cadena de conexión. Por ejemplo, el constructor
BlobContainerClient(String, String) toma una cadena de conexión.
C#
BlobContainerClient blobContainerClient = new

BlobContainerClient("UseDevelopmentStorage=true", "sample-container");
blobContainerClient.CreateIfNotExists();
Asegúrese de que el emulador se está ejecutando antes de llamar al código del

fragmento.
Para obtener más información sobre Azurite, consulte Uso del emulador de Azurite para
el desarrollo local de Azure Storage.
Configuración de una cadena de conexión para

una cuenta de Azure Storage
Para crear una cadena de conexión para una cuenta de Azure Storage, use el siguiente
formato. Indique si desea conectarse a la cuenta de almacenamiento a través de HTTPS
(recomendado) o HTTP, reemplace myAccountName por el nombre de la cuenta de
almacenamiento y reemplace myAccountKey por la clave de acceso a la cuenta:
DefaultEndpointsProtocol=
[http|https];AccountName=myAccountName;AccountKey=myAccountKey
Por ejemplo, la cadena de conexión podría ser similar a la siguiente:
DefaultEndpointsProtocol=https;AccountName=storagesample;AccountKey=<account-key>
Aunque Azure Storage admite HTTP y HTTPS en una cadena de conexión, se recomienda
encarecidamente utilizar HTTPS.
 Sugerencia
Las cadenas de conexión de la cuenta de almacenamiento se pueden encontrar en

Azure Portal . Vaya a Seguridad y redes>Claves de acceso en la configuración de
la cuenta de almacenamiento para ver las cadenas de conexión de las claves de
acceso principal y secundaria.
Creación de una cadena de conexión con una

firma de acceso compartido
Si posee una dirección URL de firma de acceso compartido (SAS) que le concede acceso
a los recursos de una cuenta de almacenamiento, puede utilizar la SAS en una cadena
de conexión. Dado que SAS incluye la información necesaria para autenticar la solicitud,
una cadena de conexión con un SAS proporciona el protocolo, el punto de conexión de
servicio y las credenciales necesarias para acceder al recurso.
Para crear una cadena de conexión que incluya una firma de acceso compartido,
especifique la cadena con el siguiente formato:
BlobEndpoint=myBlobEndpoint;
QueueEndpoint=myQueueEndpoint;
TableEndpoint=myTableEndpoint;
FileEndpoint=myFileEndpoint;
SharedAccessSignature=sasToken
Cada punto de conexión de servicio es opcional, aunque la cadena de conexión debe

contener al menos uno.
７ Nota
Se recomienda usar HTTPS con SAS.
Si está especificando SAS en una cadena de conexión en un archivo de

configuración, debe codificar caracteres especiales en la dirección URL.
Ejemplo de SAS de servicio
Este es un ejemplo de una cadena de conexión que incluye un SAS de servicio para el
almacenamiento de blobs:
BlobEndpoint=https://storagesample.blob.core.windows.net;
SharedAccessSignature=sv=2015-04-05&sr=b&si=tutorial-policy-
635959936145100803&sig=9aCzs76n0E7y5BpEi2GvsSv433BZa22leDOZXX%2BXXIU%3D
Aquí se muestra un ejemplo de la misma cadena de conexión con codificación de

dirección URL:
SharedAccessSignature=sv=2015-04-05&sr=b&si=tutorial-policy-
635959936145100803&sig=9aCzs76n0E7y5BpEi2GvsSv433BZa22leDOZXX%2BXXIU%3D
Ejemplo de SAS de cuenta

Este es un ejemplo de una cadena de conexión que incluye un SAS de cuenta para el
almacenamiento de blobs y archivos: Tenga en cuenta que se especifican los puntos de
conexión para ambos servicios:
FileEndpoint=https://storagesample.file.core.windows.net;
SharedAccessSignature=sv=2015-07-
08&sig=iCvQmdZngZNW%2F4vw43j6%2BVz6fndHF5LI639QJba4r8o%3D&spr=https&st=2016-
04-12T03%3A24%3A31Z&se=2016-04-13T03%3A29%3A31Z&srt=s&ss=bf&sp=rwl
Aquí se muestra un ejemplo de la misma cadena de conexión con codificación de

dirección URL:
FileEndpoint=https://storagesample.file.core.windows.net;
SharedAccessSignature=sv=2015-07-
08&sig=iCvQmdZngZNW%2F4vw43j6%2BVz6fndHF5LI639QJba4r8o%3D&spr=https&
amp;st=2016-04-12T03%3A24%3A31Z&se=2016-04-
13T03%3A29%3A31Z&srt=s&ss=bf&sp=rwl
Creación de una cadena de conexión para un
punto de conexión de Storage explícito
En una cadena de conexión se pueden especificar puntos de conexión de servicio
explícitos, en lugar de usar los predeterminados. Para crear una cadena de conexión que
especifique un punto de conexión explícito, especifique el punto de conexión de servicio
completo para cada servicio, incluida la especificación de protocolo (HTTPS
(recomendado) o HTTP) con el formato siguiente:
DefaultEndpointsProtocol=[http|https];
BlobEndpoint=myBlobEndpoint;
FileEndpoint=myFileEndpoint;
QueueEndpoint=myQueueEndpoint;
TableEndpoint=myTableEndpoint;
AccountName=myAccountName;
AccountKey=myAccountKey
Un escenario en el que puede desear especificar un punto de conexión explícito es

cuando ha asignado un punto de conexión de Blob Storage a un dominio personalizado.
En ese caso, puede especificar un punto de conexión personalizado para Blob Storage
en la cadena de conexión. También puede especificar los puntos de conexión
predeterminados para los demás servicios, en caso de que la aplicación los use.
Este es un ejemplo de una cadena de conexión que especifica un punto de conexión

explícito para Blob service:
# Blob endpoint only

DefaultEndpointsProtocol=https;
BlobEndpoint=http://www.mydomain.com;
AccountName=storagesample;
AccountKey=<account-key>
Este ejemplo especifica puntos de conexión explícitos para todos los servicios, lo que
incluye un dominio personalizado para Blob service:
# All service endpoints

BlobEndpoint=http://www.mydomain.com;
FileEndpoint=https://myaccount.file.core.windows.net;
QueueEndpoint=https://myaccount.queue.core.windows.net;
TableEndpoint=https://myaccount.table.core.windows.net;
AccountKey=<account-key>
Los valores del punto de conexión de una cadena de conexión se usan para construir los
identificadores URI de solicitud para los servicios de Storage e indicar el formato de los
identificadores URI que se devuelven al código.
Si ha asignado un punto de conexión de Storage a un dominio personalizado y omite

dicho punto en una cadena de conexión, no podrá usarla para acceder a los datos de
dicho servicio desde el código.
Para más información sobre cómo configurar un dominio personalizado para Azure
Storage, consulte Asignación de un dominio personalizado a un punto de conexión de
Azure Blob Storage.
） Importante
Los valores del punto de conexión de servicio de las cadenas de conexión deben
ser identificadores URI con el formato correcto, entre los que se incluyen https://
(recomendado) o http:// .
Creación de una cadena de conexión con el sufijo de un

punto de conexión
Para crear una cadena de conexión para un servicio de almacenamiento en regiones o
instancias con sufijos de punto final diferentes, como para Microsoft Azure operado por
21Vianet o Azure Government, utilice el siguiente formato de cadena de conexión.
Indique si desea conectarse a la cuenta de almacenamiento a través de HTTP
(recomendado) o HTTPS, reemplace myAccountName por el nombre de la cuenta de
almacenamiento, reemplace myAccountKey por la clave de acceso a la cuenta y
reemplace mySuffix por el sufijo del identificador URI:
DefaultEndpointsProtocol=[http|https];
AccountName=myAccountName;
AccountKey=myAccountKey;
EndpointSuffix=mySuffix;
He aquí un ejemplo de cadena de conexión para servicios de almacenamiento en Azure
operados por 21Vianet:
AccountKey=<account-key>;
EndpointSuffix=core.chinacloudapi.cn;
Autorización del acceso con una clave

compartida
Para obtener información sobre cómo autorizar el acceso a Azure Storage con la clave
de la cuenta o con una cadena de conexión, consulte alguno de los siguientes artículos:
Autorización del acceso y conexión a Blob Storage con .NET

Autorización del acceso y conexión a Blob Storage con Java
Autorización del acceso y conexión a Blob Storage con JavaScript
Autorización del acceso y conexión a Blob Storage con Python
Pasos siguientes
Grant limited access to Azure Storage resources using shared access signatures
(SAS) (Otorgar acceso limitado a recursos de Azure Storage con firmas de acceso
compartido [SAS])
Uso del emulador Azurite para el desarrollo local de Azure Storage
Desarrollo para Azure Files con .NET
Artículo • 06/05/2023
Aprenda los conceptos básicos de desarrollar aplicaciones .NET que usen Azure Files
para almacenar datos. En este artículo se muestra cómo crear una aplicación de consola
simple para hacer lo siguiente con .NET y Azure Files:
Obtenga el contenido de un archivo.

Establezca la cuota o tamaño máximo para un recurso compartido de archivos.
Cree una firma de acceso compartido (SAS) para un archivo.
Copie un archivo en otro en la misma cuenta de almacenamiento.
Copie un archivo en un blob en la misma cuenta de almacenamiento.
Cree una instantánea de un recurso compartido de archivos.
Restaure un archivo desde una instantánea de recurso compartido.
Use las métricas de Azure Storage para solucionar problemas.
Para obtener más información acerca de Azure Files, consulte ¿Qué es Azure Files?.
 Sugerencia
Extraer del repositorio ejemplos de código de Azure Storage
Para encontrar ejemplos de código de Azure Storage de un extremo a otro y fáciles

de usar que se pueden descargar y ejecutar, consulte nuestra lista de ejemplos de
Azure Storage.
Se aplica a
Descripción de las API de .NET

Azure Files proporciona dos enfoques generales para las aplicaciones cliente: bloque de
mensajes del servidor (SMB) y REST. Dentro de. NET, las API System.IO y
Azure.Storage.Files.Shares extraen estos métodos.
API Cuándo se usa Notas
System.IO Su aplicación: La E/S de archivos de Azure Files a través

Es necesario leer de SMB normalmente es igual que la E/S
o escribir con cualquier recurso compartido de red o
archivos dispositivo de almacenamiento local. Para
mediante SMB obtener una introducción a una serie de
Se ejecuta en un características en .NET, incluida la E/S de
dispositivo que archivos, consulte Aplicación de consola.
tenga acceso a
través del puerto
445 a su cuenta
de Azure Files
No es necesario
administrar
cualquiera de las
opciones
administrativas
del recurso
compartido de
archivos
Azure.Storage.Files.Shares Su aplicación: Este artículo muestra el uso de

No se puede Azure.Storage.Files.Shares para la E/S de
tener acceso a archivos con REST (en lugar de SMB) y la
Azure Files administración del recurso compartido de
mediante SMB archivos.
en el puerto 445
debido a
restricciones de
ISP o firewall
Requiere
funcionalidad
administrativa,
como la
capacidad de
establecer la
cuota de un
recurso
compartido de
archivo o crear
una firma de
acceso
compartido
Creación de la aplicación de consola y
obtención del ensamblado
Puede usar la biblioteca cliente de Azure Files en cualquier tipo de aplicación .NET. Estas
aplicaciones incluyen la nube de Azure, la Web, el escritorio y aplicaciones móviles. En
esta guía, creamos una aplicación de consola para hacerlo más sencillo.
En Visual Studio, cree una nueva aplicación de consola de Windows. Los siguientes
pasos muestran cómo crear una aplicación de consola en Visual Studio 2019. Los pasos
son similares en otras versiones de Visual Studio.
1. Inicie Visual Studio y seleccione Crear un proyecto.

2. En Crear un proyecto, elija Aplicación de consola (.NET Framework) para C# y
3. En Configure su nuevo proyecto, escriba un nombre para la app y seleccione
Crear.
Agregue todos los ejemplos de código en este artículo a la clase Program en el archivo
Program.cs.
Uso de NuGet para instalar los paquetes

necesarios
Consulte estos paquetes en el proyecto:
Biblioteca de Azure Core para .NET : este paquete es la implementación de la

canalización de clientes de Azure.
Biblioteca cliente de blob de Azure Storage para .NET : Este paquete proporciona
acceso mediante programación a los recursos de blob de la cuenta de
almacenamiento.
Biblioteca cliente de archivos de Azure Storage para .NET : Este paquete
proporciona acceso mediante programación a los recursos de archivo de la cuenta
de almacenamiento.
Biblioteca de Configuration Manager del sistema para .NET : este paquete
proporciona una clase que almacena y recupera valores en un archivo de
configuración.
Puede usar NuGet para obtener los paquetes. Siga estos pasos:
1. En el Explorador de soluciones, haga clic con el botón derecho en el proyecto y

seleccione Administrar paquetes de NuGet.
2. En Administrador de paquetes NuGet, seleccione Examinar. A continuación,
busque y elija Azure.Core, y, después, seleccione Instalar.
En este paso se instala el paquete y sus dependencias.
3. Busque e instale estos paquetes:
Azure.Storage.Blobs
Azure.Storage.Files.Shares
System.Configuration.ConfigurationManager
Guardar las credenciales de la cuenta de

almacenamiento en el archivo app.config
A continuación, guardará las credenciales en el archivo App.config del proyecto. En el
Explorador de soluciones, haga doble clic en App.config y edite el archivo para que sea
similar al ejemplo siguiente.
Reemplace myaccount por el nombre de la cuenta de almacenamiento y mykey por la

clave de la cuenta de almacenamiento.
XML
<?xml version="1.0" encoding="utf-8"?>

<configuration>
<appSettings>
<add key="StorageConnectionString"
value="DefaultEndpointsProtocol=https;AccountName=myaccount;AccountKey=mykey
;EndpointSuffix=core.windows.net" />
<add key="StorageAccountName" value="myaccount" />
<add key="StorageAccountKey" value="mykey" />
</appSettings>
</configuration>
７ Nota
El emulador de almacenamiento de Azurite no admite Azure Files actualmente. La

cadena de conexión debe hacer referencia a una cuenta de Azure Storage en la
nube para trabajar con Azure Files.
Adición de directivas using

En el Explorador de soluciones, abra el archivo Program.cs y agregue lo siguiente
mediante directivas al principio del archivo.
C#
using System;
using System.Configuration;
using System.IO;
using System.Threading.Tasks;
using Azure;
using Azure.Storage;
using Azure.Storage.Blobs;
using Azure.Storage.Files.Shares;
using Azure.Storage.Files.Shares.Models;
using Azure.Storage.Sas;
Obtener acceso al recurso compartido de

archivos mediante programación
En el archivo Program.cs, agregue el código siguiente para obtener acceso al recurso
compartido de archivos mediante programación.
El método siguiente crea un recurso compartido de archivos si aún no existe. El método

se inicia creando un objeto ShareClient a partir de una cadena de conexión. A
continuación, en el ejemplo se intenta descargar un archivo que creamos anteriormente.
Llame a este método desde Main() .
C#
//-------------------------------------------------
// Create a file share
//-------------------------------------------------
public async Task CreateShareAsync(string shareName)
{
// Get the connection string from app settings
string connectionString =
ConfigurationManager.AppSettings["StorageConnectionString"];
// Instantiate a ShareClient which will be used to create and manipulate

the file share
ShareClient share = new ShareClient(connectionString, shareName);
// Create the share if it doesn't already exist

await share.CreateIfNotExistsAsync();
// Ensure that the share exists

if (await share.ExistsAsync())
{
Console.WriteLine($"Share created: {share.Name}");
// Get a reference to the sample directory

ShareDirectoryClient directory =
share.GetDirectoryClient("CustomLogs");
// Create the directory if it doesn't already exist

await directory.CreateIfNotExistsAsync();
// Ensure that the directory exists

if (await directory.ExistsAsync())
{
// Get a reference to a file object
ShareFileClient file = directory.GetFileClient("Log1.txt");
// Ensure that the file exists

if (await file.ExistsAsync())
{
Console.WriteLine($"File exists: {file.Name}");
// Download the file

ShareFileDownloadInfo download = await file.DownloadAsync();
// Save the data to a local file, overwrite if the file

already exists
using (FileStream stream =
File.OpenWrite(@"downloadedLog1.txt"))
{
await download.Content.CopyToAsync(stream);
await stream.FlushAsync();
stream.Close();
// Display where the file was saved

Console.WriteLine($"File downloaded: {stream.Name}");
}
}
}
}
else
{
Console.WriteLine($"CreateShareAsync failed");
}
}
Establecer el tamaño máximo para un recurso

A partir de la versión 5.x de la biblioteca cliente de Azure Files, se puede establecer la
cuota (tamaño máximo) de un recurso compartido de archivos. También puede
comprobar cuántos datos se almacenan actualmente en el recurso compartido.
Al establecer la cuota para un recurso compartido, se limita el tamaño total de los
archivos almacenados en el recurso compartido. Si el tamaño total de los archivos del
recurso compartido supera la cuota, los clientes no pueden aumentar el tamaño de los
archivos existentes. Los clientes tampoco pueden crear archivos nuevos, a menos que
estén vacíos.
En el ejemplo siguiente se muestra cómo comprobar el uso actual de un recurso

compartido y cómo establecer la cuota para el recurso compartido.
C#
//-------------------------------------------------
// Set the maximum size of a share
//-------------------------------------------------
public async Task SetMaxShareSizeAsync(string shareName, int
increaseSizeInGiB)
{
const long ONE_GIBIBYTE = 10737420000; // Number of bytes in 1 gibibyte

// Instantiate a ShareClient which will be used to access the file share

ShareClient share = new ShareClient(connectionString, shareName);
// Create the share if it doesn't already exist

await share.CreateIfNotExistsAsync();

{
// Get and display current share quota
ShareProperties properties = await share.GetPropertiesAsync();
Console.WriteLine($"Current share quota: {properties.QuotaInGB}
GiB");
// Get and display current usage stats for the share

ShareStatistics stats = await share.GetStatisticsAsync();
Console.WriteLine($"Current share usage: {stats.ShareUsageInBytes}
bytes");
// Convert current usage from bytes into GiB

int currentGiB = (int)(stats.ShareUsageInBytes / ONE_GIBIBYTE);
// This line sets the quota to be the current

// usage of the share plus the increase amount
await share.SetQuotaAsync(currentGiB + increaseSizeInGiB);
// Get the new quota and display it

properties = await share.GetPropertiesAsync();
Console.WriteLine($"New share quota: {properties.QuotaInGB} GiB");
}
}
Generar una firma de acceso compartido para un archivo

o recurso compartido de archivos
A partir de la versión 5.x de la biblioteca cliente de Azure Files, puede generar una firma
de acceso compartido (SAS) para un recurso compartido de archivos o para un archivo
individual.
El método de ejemplo siguiente devuelve una SAS en un archivo del recurso compartido
especificado.
C#
//-------------------------------------------------
// Create a SAS URI for a file
//-------------------------------------------------
public Uri GetFileSasUri(string shareName, string filePath, DateTime
expiration, ShareFileSasPermissions permissions)
{
// Get the account details from app settings
string accountName =
ConfigurationManager.AppSettings["StorageAccountName"];
string accountKey =
ConfigurationManager.AppSettings["StorageAccountKey"];
ShareSasBuilder fileSAS = new ShareSasBuilder()

{
ShareName = shareName,
FilePath = filePath,
// Specify an Azure file resource

Resource = "f",
// Expires in 24 hours
ExpiresOn = expiration
};
// Set the permissions for the SAS

fileSAS.SetPermissions(permissions);
// Create a SharedKeyCredential that we can use to sign the SAS token

StorageSharedKeyCredential credential = new
StorageSharedKeyCredential(accountName, accountKey);
// Build a SAS URI

UriBuilder fileSasUri = new
UriBuilder($"https://{accountName}.file.core.windows.net/{fileSAS.ShareName}
/{fileSAS.FilePath}");
fileSasUri.Query = fileSAS.ToSasQueryParameters(credential).ToString();
// Return the URI

return fileSasUri.Uri;
}
Para más información sobre la creación y el uso de firmas de acceso compartido,

consulte Funcionamiento de una firma de acceso compartido.
Copiar archivos
A partir de la versión 5.x de la biblioteca cliente de Azure Files, puede copiar un archivo
en otro, un archivo en un blob o un blob en un archivo.
También puede usar AzCopy para copiar un archivo en otro o para copiar un blob en un
archivo o viceversa. Consulte Introducción a AzCopy.
７ Nota
Si va a copiar un blob en un archivo o un archivo en un blob, debe usar una firma

de acceso compartido (SAS) para autorizar el acceso al objeto de origen, incluso si
está copiando en la misma cuenta de almacenamiento.
Copiar un archivo en otro

En el ejemplo siguiente se copia un archivo en otro en el mismo recurso compartido.
Puede usar la autenticación de clave compartida para realizar la copia porque en esta
operación se copian archivos de la misma cuenta de almacenamiento.
C#
//-------------------------------------------------
// Copy file within a directory
//-------------------------------------------------
public async Task CopyFileAsync(string shareName, string sourceFilePath,
string destFilePath)
{
// Get a reference to the file we created previously

ShareFileClient sourceFile = new ShareFileClient(connectionString,
shareName, sourceFilePath);
// Ensure that the source file exists
if (await sourceFile.ExistsAsync())
{
// Get a reference to the destination file
ShareFileClient destFile = new ShareFileClient(connectionString,
shareName, destFilePath);
// Start the copy operation

await destFile.StartCopyAsync(sourceFile.Uri);
if (await destFile.ExistsAsync())
{
Console.WriteLine($"{sourceFile.Uri} copied to {destFile.Uri}");
}
}
}
Copiar un archivo en un blob

En el ejemplo siguiente se crea un archivo y se copia en un blob de la misma cuenta de
almacenamiento. El ejemplo crea una SAS para el archivo de origen, que el servicio usa
para autorizar el acceso al archivo de origen durante la operación de copia.
C#
//-------------------------------------------------
// Copy a file from a share to a blob
//-------------------------------------------------
public async Task CopyFileToBlobAsync(string shareName, string
sourceFilePath, string containerName, string blobName)
{
// Get a file SAS from the method created ealier
Uri fileSasUri = GetFileSasUri(shareName, sourceFilePath,
DateTime.UtcNow.AddHours(24), ShareFileSasPermissions.Read);
// Get a reference to the file we created previously

ShareFileClient sourceFile = new ShareFileClient(fileSasUri);
// Ensure that the source file exists

if (await sourceFile.ExistsAsync())
{
// Get a reference to the destination container

BlobContainerClient container = new
BlobContainerClient(connectionString, containerName);
// Create the container if it doesn't already exist

await container.CreateIfNotExistsAsync();
BlobClient destBlob = container.GetBlobClient(blobName);
await destBlob.StartCopyFromUriAsync(sourceFile.Uri);
if (await destBlob.ExistsAsync())
{
Console.WriteLine($"File {sourceFile.Name} copied to blob
{destBlob.Name}");
}
}
}
Puede copiar un blob en un archivo de la misma manera. Si el objeto de origen es un

blob, cree una SAS para autorizar el acceso a dicho blob durante la operación de copia.

A partir de la versión 8.5 de la biblioteca cliente de Azure Files, se puede crear una
instantánea de recurso compartido. Las instantáneas de recursos compartidos también
se pueden enumerar, explorar y eliminar. Una vez creadas, las instantáneas de recursos
compartidos son de solo lectura.

En el siguiente ejemplo se crea una instantánea de recurso compartido.
C#
//-------------------------------------------------
// Create a share snapshot
//-------------------------------------------------
public async Task CreateShareSnapshotAsync(string shareName)
{
// Instatiate a ShareServiceClient
ShareServiceClient shareServiceClient = new
ShareServiceClient(connectionString);
// Instantiate a ShareClient which will be used to access the file share

ShareClient share = shareServiceClient.GetShareClient(shareName);

{
// Create a snapshot
ShareSnapshotInfo snapshotInfo = await share.CreateSnapshotAsync();
Console.WriteLine($"Snapshot created: {snapshotInfo.Snapshot}");
}
}
Enumerar instantáneas del recurso compartido

En el ejemplo siguiente se enumeran las instantáneas de un recurso compartido.
C#
//-------------------------------------------------
// List the snapshots on a share
//-------------------------------------------------
public void ListShareSnapshots()
{
ShareServiceClient shareServiceClient = new
// Display each share and the snapshots on each share

foreach (ShareItem item in shareServiceClient.GetShares(ShareTraits.All,
ShareStates.Snapshots))
{
if (null != item.Snapshot)
{
Console.WriteLine($"Share: {item.Name}\tSnapshot:
{item.Snapshot}");
}
}
}
Enumeración de archivos y directorios en instantáneas de

recursos compartidos
En el ejemplo siguiente se examinan los archivos y directorios de instantáneas de
recursos compartidos.
C#
//-------------------------------------------------
// List the snapshots on a share
//-------------------------------------------------
public void ListSnapshotContents(string shareName, string snapshotTime)
{
ShareServiceClient shareService = new
// Get a ShareClient
ShareClient share = shareService.GetShareClient(shareName);
Console.WriteLine($"Share: {share.Name}");
// Get as ShareClient that points to a snapshot

ShareClient snapshot = share.WithSnapshot(snapshotTime);
// Get the root directory in the snapshot share

ShareDirectoryClient rootDir = snapshot.GetRootDirectoryClient();
// Recursively list the directory tree

ListDirTree(rootDir);
}
//-------------------------------------------------
// Recursively list a directory tree
//-------------------------------------------------
public void ListDirTree(ShareDirectoryClient dir)
{
// List the files and directories in the snapshot
foreach (ShareFileItem item in dir.GetFilesAndDirectories())
{
if (item.IsDirectory)
{
Console.WriteLine($"Directory: {item.Name}");
ShareDirectoryClient subDir =
dir.GetSubdirectoryClient(item.Name);
ListDirTree(subDir);
}
else
{
Console.WriteLine($"File: {dir.Name}\\{item.Name}");
}
}
}
Restauración de recursos compartidos de archivos o

archivos desde instantáneas de recursos compartidos
La toma de una instantánea de un recurso compartido de archivos permite recuperar
archivos individuales o todo el recurso compartido de archivos.
Para restaurar un archivo de una instantánea del recurso compartido de archivos,

consulte las instantáneas de recursos compartidos de un recurso compartido de
archivos. Después, puede recuperar un archivo que pertenezca a una instantánea de
recurso compartido determinada. Use esa versión para leer directamente el archivo o
restaurarlo.
C#
//-------------------------------------------------
// Restore file from snapshot
//-------------------------------------------------
public async Task RestoreFileFromSnapshot(string shareName, string
directoryName, string fileName, string snapshotTime)
{
// Get as ShareClient that points to a snapshot

ShareClient snapshot = share.WithSnapshot(snapshotTime);
// Get a ShareDirectoryClient, then a ShareFileClient to the snapshot

file
ShareDirectoryClient snapshotDir =
snapshot.GetDirectoryClient(directoryName);
ShareFileClient snapshotFile = snapshotDir.GetFileClient(fileName);
// Get a ShareDirectoryClient, then a ShareFileClient to the live file

ShareDirectoryClient liveDir = share.GetDirectoryClient(directoryName);
ShareFileClient liveFile = liveDir.GetFileClient(fileName);
// Restore the file from the snapshot

ShareFileCopyInfo copyInfo = await
liveFile.StartCopyAsync(snapshotFile.Uri);
// Display the status of the operation

Console.WriteLine($"Restore status: {copyInfo.CopyStatus}");
}
Eliminación de instantáneas de recursos compartidos

En el siguiente ejemplo se elimina una instantánea de recurso compartido.
C#
//-------------------------------------------------
// Delete a snapshot
//-------------------------------------------------
public async Task DeleteSnapshotAsync(string shareName, string snapshotTime)
{
// Get a ShareClient that points to a snapshot

ShareClient snapshotShare = share.WithSnapshot(snapshotTime);
try
{
// Delete the snapshot
await snapshotShare.DeleteIfExistsAsync();
}
catch (RequestFailedException ex)
{
Console.WriteLine($"Exception: {ex.Message}");
Console.WriteLine($"Error code: {ex.Status}\t{ex.ErrorCode}");
}
}
Solución de problemas de Azure Files mediante

métricas
Azure Storage Analytics admite métricas para Azure Files. Con los datos de las métricas,
es posible seguir paso a paso las solicitudes y diagnosticar problemas.
Puede habilitar las métricas para Azure Files mediante Azure Portal . La métrica
también se puede habilitar mediante programación. Para ello, hay que llamar a la
operación Set File Service Properties con la API de REST o una de sus análogas de la
biblioteca cliente de Azure Files.
En el siguiente ejemplo de código se muestra cómo usar la biblioteca cliente de .NET a

fin de habilitar las métricas para Azure Files.
C#
//-------------------------------------------------
// Use metrics
//-------------------------------------------------
public async Task UseMetricsAsync()
{
// Set metrics properties for File service

await shareService.SetPropertiesAsync(new ShareServiceProperties()
{
// Set hour metrics
HourMetrics = new ShareMetrics()
{
Enabled = true,
IncludeApis = true,
Version = "1.0",
RetentionPolicy = new ShareRetentionPolicy()

{
Enabled = true,
Days = 14
}
},
// Set minute metrics

MinuteMetrics = new ShareMetrics()
{
Enabled = true,
IncludeApis = true,
Version = "1.0",
RetentionPolicy = new ShareRetentionPolicy()

{
Enabled = true,
Days = 7
}
}
});
// Read the metrics properties we just set

ShareServiceProperties serviceProperties = await
shareService.GetPropertiesAsync();
// Display the properties

Console.WriteLine();
Console.WriteLine($"HourMetrics.InludeApis:
{serviceProperties.HourMetrics.IncludeApis}");
Console.WriteLine($"HourMetrics.RetentionPolicy.Days:
{serviceProperties.HourMetrics.RetentionPolicy.Days}");
Console.WriteLine($"HourMetrics.Version:
{serviceProperties.HourMetrics.Version}");
Console.WriteLine($"MinuteMetrics.InludeApis:
{serviceProperties.MinuteMetrics.IncludeApis}");
Console.WriteLine($"MinuteMetrics.RetentionPolicy.Days:
{serviceProperties.MinuteMetrics.RetentionPolicy.Days}");
Console.WriteLine($"MinuteMetrics.Version:
{serviceProperties.MinuteMetrics.Version}");
}
Si encuentra algún problema, consulte Solución de problemas de Azure Files.
Pasos siguientes
Para más información acerca de Azure Files, consulte los siguientes recursos:
Artículos y vídeos conceptuales

Azure Files: un sistema de archivos SMB en la nube sin dificultades para Windows y
Linux
Uso de Azure Files con Linux
Compatibilidad de herramientas con el almacenamiento

de archivos
Introducción a AzCopy
Referencia
API de Azure Storage para .NET
File Service REST API (API de REST de File Service)
Para obtener ejemplos de código relacionados con los SDK de .NET versión 11.x en
desuso, consulte Ejemplos de código con la versión 11.x de .NET.
Desarrollo con Java para Azure Files
Artículo • 06/05/2023
Aprenda los conceptos básicos de desarrollar aplicaciones de Java que usen Azure Files
para almacenar datos. Cree una aplicación de consola y aprenda las acciones básicas
sobre el uso de las API de Azure Files:
Crear y eliminar recursos compartidos de archivos de Azure

Crear y eliminar directorios
Enumerar los archivos y directorios de un recurso compartido de Azure File
Cargar, descargar y eliminar un archivo
 Sugerencia
Extraer del repositorio ejemplos de código de Azure Storage
Para encontrar ejemplos de código de Azure Storage de un extremo a otro y fáciles

de usar que se pueden descargar y ejecutar, consulte nuestra lista de ejemplos de
Azure Storage.
Se aplica a
Creación de una aplicación Java

Para compilar las muestras, se necesitará el Kit de desarrollo de Java (JDK) y el SDK de
Azure Storage para Java . También deberá haber creado una cuenta de
Configuración de la aplicación para usar Azure

Files
Para utilizar las API de Azure Files, agregue el siguiente código al principio del archivo
Java desde el que desea acceder a Azure Files.
Java
// Include the following imports to use Azure Files APIs

import com.azure.storage.file.share.*;
Configuración de una cadena de conexión de

Almacenamiento de Azure
Para usar Azure Files, debe conectarse a su cuenta de almacenamiento de Azure.
Configure una cadena de conexión y úsela para conectarse a su cuenta de
almacenamiento. Defina una variable estática que contenga la cadena de conexión.
Reemplace <your_storage_account_name> y <your_storage_account_key> por los valores

reales de la cuenta de almacenamiento.
Java
// Define the connection-string.

// Replace the values, including <>, with
// the values from your storage account.
public static final String connectStr =
"DefaultEndpointsProtocol=https;" +
"AccountName=<storage_account_name>;" +
"AccountKey=<storage_account_key>";
Acceso a un recurso compartido de archivos de

Azure
Para acceder a Azure Files, cree un objeto ShareClient. Use la clase ShareClientBuilder
para crear un nuevo objeto ShareClient.
Java
ShareClient shareClient = new ShareClientBuilder()

.connectionString(connectStr).shareName(shareName)
.buildClient();

Todos los archivos y directorios de Azure Files se almacenan en un contenedor
denominado recurso compartido.
El método ShareClient.create produce una excepción si el recurso compartido ya existe.

Coloque la llamada a create en un bloque try/catch y controle la excepción.
Java
public static Boolean createFileShare(String connectStr, String shareName)

{
try
{
.buildClient();
shareClient.create();
return true;
}
catch (Exception e)
{
System.out.println("createFileShare exception: " + e.getMessage());
return false;
}
}

archivos
En el siguiente código de ejemplo se elimina un recurso compartido de archivos.
Elimine un recurso compartido llamando al método ShareClient.delete.
Java
public static Boolean deleteFileShare(String connectStr, String shareName)

{
try
{
.buildClient();
shareClient.delete();
return true;
}
catch (Exception e)
{
System.out.println("deleteFileShare exception: " + e.getMessage());
return false;
}
}
Para organizar el almacenamiento, coloque los archivos en los subdirectorios, en lugar
de mantenerlos todos en el directorio raíz.
En el código siguiente se crea un directorio llamando a ShareDirectoryClient.create. El

método de ejemplo devuelve un valor Boolean que indica si se el directorio creó
correctamente.
Java
public static Boolean createDirectory(String connectStr, String shareName,

String dirName)
{
try
{
ShareDirectoryClient dirClient = new ShareFileClientBuilder()
.resourcePath(dirName)
.buildDirectoryClient();
dirClient.create();
return true;
}
catch (Exception e)
{
System.out.println("createDirectory exception: " + e.getMessage());
return false;
}
}
Eliminación de un directorio
Eliminar un directorio es una tarea sencilla. No se puede eliminar un directorio que
todavía contenga archivos o subdirectorios.
El método ShareDirectoryClient.delete produce una excepción si el directorio no existe o

no está vacío. Coloque la llamada a delete en un bloque try/catch y controle la
excepción.
Java
public static Boolean deleteDirectory(String connectStr, String shareName,
String dirName)
{
try
{
dirClient.delete();
return true;
}
catch (Exception e)
{
System.out.println("deleteDirectory exception: " + e.getMessage());
return false;
}
}
Enumerar los archivos y directorios de un

recurso compartido de Azure File
Obtenga una lista de archivos y directorios llamando
ShareDirectoryClient.listFilesAndDirectories. El método devuelve una lista de objetos
ShareFileItem en los que puede efectuar la iteración. En el código siguiente se
enumeran los archivos y directorios del directorio especificado por el parámetro
dirName.
Java
public static Boolean enumerateFilesAndDirs(String connectStr, String

shareName,
String dirName)
{
try
{
dirClient.listFilesAndDirectories().forEach(
fileRef -> System.out.printf("Resource: %s\t Directory? %b\n",
fileRef.getName(), fileRef.isDirectory())
);
return true;
}
catch (Exception e)
{
System.out.println("enumerateFilesAndDirs exception: " +
e.getMessage());
return false;
}
}
Cargar un archivo
Obtenga información sobre cómo cargar un archivo desde el almacenamiento local.
El código siguiente carga un archivo local en Azure Files mediante una llamada al
método ShareFileClient.uploadFromFile. El método de ejemplo siguiente devuelve un
valor Boolean que indica si el archivo especificado se cargó correctamente.
Java
public static Boolean uploadFile(String connectStr, String shareName,

String dirName, String fileName)
{
try
{
ShareFileClient fileClient = dirClient.getFileClient(fileName);

fileClient.create(1024);
fileClient.uploadFromFile(fileName);
return true;
}
catch (Exception e)
{
System.out.println("uploadFile exception: " + e.getMessage());
return false;
}
}
Una de las operaciones más frecuentes es descargar archivos de un recurso compartido
En el siguiente ejemplo se descarga el archivo especificado en el directorio local
especificado en el parámetro destDir. El método de ejemplo hace que el nombre de
archivo descargado sea único al anteponer la fecha y la hora.
Java
public static Boolean downloadFile(String connectStr, String shareName,

String dirName, String destDir,
String fileName)
{
try
{
// Create a unique file name

String date = new java.text.SimpleDateFormat("yyyyMMdd-
HHmmss").format(new java.util.Date());
String destPath = destDir + "/"+ date + "_" + fileName;
fileClient.downloadToFile(destPath);
return true;
}
catch (Exception e)
{
System.out.println("downloadFile exception: " + e.getMessage());
return false;
}
}
Eliminación de un archivo
Otra operación habitual en Azure Files es la eliminación de archivos.
En el código siguiente se elimina el archivo especificado. En primer lugar, el ejemplo

crea un método ShareDirectoryClient basándose en el parámetro dirName. A
continuación, el código obtiene un ShareFileClient desde el cliente de directorio, basado
en el parámetro fileName. Por último, el método de ejemplo llama a
ShareFileClient.delete para eliminar el archivo.
Java
public static Boolean deleteFile(String connectStr, String shareName,

String dirName, String fileName)
{
try
{

fileClient.delete();
return true;
}
catch (Exception e)
{
System.out.println("deleteFile exception: " + e.getMessage());
return false;
}
}
Pasos siguientes
Si desea obtener más información acerca de otras API de almacenamiento de Azure,
siga estos vínculos.
Azure para desarrolladores de Java

SDK de Azure para Java
SDK de Azure para Android
Referencia del SDK de la biblioteca cliente de recursos compartidos de archivos de
Azure para Java
API de REST de servicios de Azure Storage
Blog del equipo de Azure Storage
Transferencia de datos con la utilidad en línea de comandos AzCopy
Para ver ejemplos de código relacionados que usan SDK de la versión 8 de Java en
desuso, consulte Ejemplos de código que usan la versión 8 de Java.
Desarrollo con C++ para Azure Files
Artículo • 30/03/2023
 Sugerencia
Probar el Explorador de Microsoft Azure Storage
El Explorador de Microsoft Azure Storage es una aplicación independiente y

gratuita de Microsoft que permite trabajar visualmente con los datos de Azure
Storage en Windows, macOS y Linux.
Se aplica a
Acerca de este tutorial

En este tutorial aprenderá a realizar operaciones básicas en Azure Files con C++. Si es la
primera vez que usa Azure Files, le resultará útil repasar los conceptos de las secciones
siguientes para comprender los ejemplos. Algunos de los ejemplos tratados son:
Crear y eliminar recursos compartidos de archivos de Azure

Crear y eliminar directorios
Establecer y enumerar los metadatos de un archivo
７ Nota
Dado que se puede acceder a Azure Files a través de SMB, es posible escribir
aplicaciones sencillas que accedan al recurso compartido de archivos de Azure
mediante las clases y funciones estándar de E/S de C++. En este artículo se
describe cómo escribir aplicaciones que utilizan el SDK de C++ de Azure Storage,
que usa la API de REST de archivos para comunicarse con Azure Files.
Requisitos previos
Suscripción de Azure
Cuenta de Almacenamiento de Azure
Compilador de C++
CMake
Vcpkg: administrador de paquetes de C y C++
Instalación
En esta sección se explica cómo preparar un proyecto para que funcione con la
versión 12 de la biblioteca cliente de Azure Blob Storage para C++.
Instalación de los paquetes

El comando vcpkg install instalará el SDK de Azure Storage Blobs para C++ y las
dependencias necesarias:
Consola
vcpkg.exe install azure-storage-files-shares-cpp:x64-windows
Para más información, visite GitHub para adquirir y crear el SDK de Azure para C++ .
Crear el proyecto
En Visual Studio, cree una aplicación de consola de C++ para Windows llamada
FilesShareQuickstartV12.
Copia de las credenciales desde Azure Portal
Cuando la aplicación de ejemplo realiza una solicitud a Azure Storage, debe estar
autorizada. Para autorizar una solicitud, agregue a la aplicación las credenciales de la
cuenta de almacenamiento en forma de cadena de conexión. Para ver las credenciales
de la cuenta de almacenamiento, siga estos pasos:
2. Busque su cuenta de almacenamiento.
3. En el panel del menú de la cuenta de almacenamiento, en Seguridad y redes,

seleccione Claves de acceso. Aquí puede ver las claves de acceso de la cuenta, así
como la cadena de conexión completa de cada clave.
4. En el panel Claves acceso, seleccione Mostrar claves.

5. En la sección key1, busque el valor de Cadena de conexión. Seleccione el icono
Copiar al portapapeles para copiar la cadena de conexión. En la siguiente sección,
agregará el valor de la cadena de conexión a una variable de entorno.
Configuración de la cadena de conexión de

almacenamiento.
Una vez que haya copiado la cadena de conexión, escríbala en una variable de entorno
nueva en la máquina local que ejecuta la aplicación. Para establecer la variable de
entorno, abra una ventana de consola y siga las instrucciones de su sistema operativo.
Reemplace <yourconnectionstring> por la cadena de conexión real.
Windows
Símbolo del sistema de Windows
setx AZURE_STORAGE_CONNECTION_STRING "<yourconnectionstring>"
Después de agregar la variable de entorno en Windows, debe iniciar una nueva instancia
de la ventana de comandos.
Reiniciar programas
Después de agregar la variable de entorno, reinicie todos los programas en ejecución
que necesiten leer esta variable. Por ejemplo, reinicie el entorno de desarrollo o el editor
antes de continuar.
Ejemplos de código
Estos fragmentos de código de ejemplo muestran cómo realizar las siguientes tareas
con la biblioteca cliente de recursos compartidos de archivos de Azure para C++:
Adición de archivos de inclusión

Obtención de la cadena de conexión
Carga de archivos en un recurso compartido de archivos
Establecimiento de los metadatos de un archivo
Enumeración de los metadatos de un archivo
Descarga de archivos
Eliminar un archivo
Eliminación de un recurso compartido de archivos
Adición de archivos de inclusión

Desde el directorio del proyecto:
1. Abra el archivo de soluciones FilesShareQuickstartV12.sln en Visual Studio.

2. En Visual Studio, abra el archivo de origen FilesShareQuickstartV12.cpp.
3. Quite todo el código incluido en main que se haya generado automáticamente.
4. Agregue las instrucciones #include .
C++
#include <iostream>
#include <stdlib.h>
#include <vector>
#include <azure/storage/files/shares.hpp>
Obtención de la cadena de conexión

El código siguiente recupera la cadena de conexión de la cuenta de almacenamiento de
la variable de entorno creada en Configuración de la cadena de conexión de
almacenamiento.
Agregue este código a main() :
C++
// Retrieve the connection string for use with the application. The
storage
// connection string is stored in an environment variable on the
machine
// running the application called AZURE_STORAGE_CONNECTION_STRING.
// Note that _MSC_VER is set when using MSVC compiler.
static const char* AZURE_STORAGE_CONNECTION_STRING =
"AZURE_STORAGE_CONNECTION_STRING";
#if !defined(_MSC_VER)
const char* connectionString =
std::getenv(AZURE_STORAGE_CONNECTION_STRING);
#else
// Use getenv_s for MSVC
size_t requiredSize;
getenv_s(&requiredSize, NULL, NULL,
AZURE_STORAGE_CONNECTION_STRING);
if (requiredSize == 0) {
throw std::runtime_error("missing connection string from env.");
}
std::vector<char> value(requiredSize);
getenv_s(&requiredSize, value.data(), value.size(),
AZURE_STORAGE_CONNECTION_STRING);
std::string connectionStringStr = std::string(value.begin(),
value.end());
const char* connectionString = connectionStringStr.c_str();
#endif

Cree una instancia de la clase ShareClient ; para ello, llame a la función
CreateFromConnectionString . Luego, llame a createIfNotExists para crear el recurso
compartido de archivos real en la cuenta de almacenamiento.
Agregue este código al final de main() :
C++
using namespace Azure::Storage::Files::Shares;
std::string shareName = "sample-share";
// Initialize a new instance of ShareClient

auto shareClient = ShareClient::CreateFromConnectionString(connectionString,
shareName);
// Create the files share. This will do nothing if the files share already
exists.
std::cout << "Creating files share: " << shareName << std::endl;
shareClient.CreateIfNotExists();
Carga de archivos en un recurso compartido de archivos

El siguiente fragmento de código:
1. Declara una cadena que contiene "Hello Azure!".

2. Obtiene una referencia a un objeto ShareFileClient al obtener el
ShareDirectoryClient raíz y llamar a GetFileClient en el recurso compartido de
archivos de la sección Creación de un recurso compartido de archivos.
3. Carga la cadena en el archivo mediante la llamada a la función UploadFrom . Esta
función crea el archivo, en caso de que no exista, o lo actualiza si existe.
C++
std::string fileName = "sample-file";

uint8_t fileContent[] = "Hello Azure!";
// Create the ShareFileClient

ShareFileClient fileClient =
shareClient.GetRootDirectoryClient().GetFileClient(fileName);
// Upload the file

std::cout << "Uploading file: " << fileName << std::endl;
fileClient.UploadFrom(fileContent, sizeof(fileContent));
Establecimiento de los metadatos de un archivo

Establezca las propiedades de los metadatos de un archivo mediante una llamada a la
función ShareFileClient.SetMetadata .
C++
Azure::Storage::Metadata fileMetadata = { {"key1", "value1"}, {"key2",

"value2"} };
fileClient.SetMetadata(fileMetadata);
Enumeración de los metadatos de un archivo

Establezca las propiedades de los metadatos de un archivo mediante una llamada a la
función ShareFileClient.GetProperties . Los metadatos están en el campo Metadata del
Value devuelto. Los metadatos serán un par clave-valor, similar al ejemplo de
Establecimiento de los metadatos de un archivo.
C++
// Retrieve the file properties

auto properties = fileClient.GetProperties().Value;
std::cout << "Listing blob metadata..." << std::endl;
for (auto metadata : properties.Metadata)
{
std::cout << metadata.first << ":" << metadata.second << std::endl;
}
Una vez recuperadas las propiedades del archivo en Enumeración de los metadatos de
un archivo, se crea un nuevo objeto std::vector<uint8_t> con las propiedades del
archivo cargado. Descargue el archivo que ha creado anteriormente en el nuevo objeto
std::vector<uint8_t> , para llo, llame a la función DownloadTo en la clase base
ShareFileClient . Por último, muestre los datos del archivo descargado.
C++
std::vector<uint8_t> fileDownloaded(properties.FileSize);
fileClient.DownloadTo(fileDownloaded.data(), fileDownloaded.size());
std::cout << "Downloaded file contents: " <<

std::string(fileDownloaded.begin(), fileDownloaded.end()) << std::endl;
El código siguiente elimina el archivo del recurso compartido de archivos de Azure
Storage, para lo que llama a la función ShareFileClient.Delete .
C++
std::cout << "Deleting file: " << fileName << std::endl;

fileClient.DeleteIfExists();
Eliminación de un recurso compartido de archivos

El código siguiente limpia los recursos que creó la aplicación; para ello, elimina todo el
recurso compartido de archivos mediante ShareClient.Delete .
C++
std::cout << "Deleting files share: " << shareName << std::endl;
shareClient.DeleteIfExists();
Ejecución del código
Esta aplicación crea un contenedor y carga un archivo de texto en Azure Blob Storage.
Luego, en el ejemplo se enumeran los blobs del contenedor, se descarga el archivo y se
muestra su contenido. Por último, la aplicación elimina tanto el blob como el
contenedor.
La salida de la aplicación es similar a la del ejemplo siguiente:
Resultados
Azure Files Shares storage v12 - C++ quickstart sample

Creating files share: sample-share
Uploading file: sample-file
Listing file metadata...
key1:value1
key2:value2
Downloaded file contents: Hello Azure!
Deleting file: sample-file
Deleting files share: sample-share
Pasos siguientes
En este inicio rápido ha aprendido a cargar, descargar y enumerar archivos mediante
C++. También ha aprendido a crear y eliminar un recurso compartido de archivos de
Azure Storage.
Para ver un ejemplo de Blob Storage para C++, siga estos pasos:
Ejemplos de SDK del recurso compartido de archivos de Azure Storage v12 para
C++
Desarrollo para Azure Files con Python
Artículo • 13/10/2023
Conozca los aspectos básicos del uso de Python para desarrollar aplicaciones o servicios
que usan Azure Files para almacenar datos de archivos. Cree una aplicación de consola y
aprenda a realizar acciones básicas con Python y Azure Files:
Crear recursos compartidos de archivos de Azure

Crear directorios
Enumerar los archivos y directorios de un recurso compartido de Azure File
Crear copias de seguridad de recursos compartidos de archivos mediante
instantáneas
７ Nota
Dado que se puede acceder a Azure Files a través de SMB, es posible escribir
aplicaciones simples que accedan al recurso compartido de archivos de Azure
mediante las clases y funciones estándar de E/S de Python. En este artículo se
describe cómo escribir aplicaciones que usen el SDK de Python de Azure Storage,
que emplea la API REST de Azure Files para comunicarse con Azure Files.
Se aplica a
Descarga e instalación del SDK de Azure

Storage para Python
７ Nota
Si va a actualizar desde el SDK de Azure Storage para Python 0.36 o una versión
anterior, desinstale el SDK anterior mediante pip uninstall azure-storage antes de
instalar el paquete más reciente.
La biblioteca cliente Azure Files para Python requiere Python 3.7+.
Instalación mediante PyPI

Para realizar la instalación mediante el índice de paquetes de Python (PyPI), escriba:
Consola
pip install azure-storage-file-share
Configuración de la aplicación para usar Azure

Files
Agregue el siguiente código cerca de la parte superior de un archivo de origen Python
para utilizar los fragmentos de código de este artículo.
Python
from azure.core.exceptions import (

ResourceExistsError,
ResourceNotFoundError
)
from azure.storage.fileshare import (

ShareServiceClient,
ShareClient,
ShareDirectoryClient,
ShareFileClient
)
Configuración de una conexión a Azure Files

ShareServiceClient le permite trabajar con recursos compartidos, directorios y archivos.
Este código crea un objeto ShareServiceClient con la cadena de conexión de la cuenta
de almacenamiento:
Python
# Create a ShareServiceClient from a connection string

service_client =
ShareServiceClient.from_connection_string(connection_string)

de Azure
En el siguiente código de ejemplo, puede usar un objeto ShareClient para crear el
recurso compartido, en caso de que no exista.
Python
def create_file_share(self, connection_string, share_name):

try:
# Create a ShareClient from a connection string
share_client = ShareClient.from_connection_string(
connection_string, share_name)
print("Creating share:", share_name)

share_client.create_share()
except ResourceExistsError as ex:

print("ResourceExistsError:", ex.message)
El método siguiente crea un directorio en la raíz del recurso compartido de archivos

especificado utilizando un objeto ShareDirectoryClient.
Python
def create_directory(self, connection_string, share_name, dir_name):

try:
# Create a ShareDirectoryClient from a connection string
dir_client = ShareDirectoryClient.from_connection_string(
connection_string, share_name, dir_name)
print("Creating directory:", share_name + "/" + dir_name)

dir_client.create_directory()

Cargar un archivo
En esta sección, aprenderá a cargar un archivo desde el almacenamiento local en
Azure Files.
El método siguiente carga el contenido del archivo especificado en el directorio que

está especificado en el recurso compartido de archivos de Azure especificado.
Python
def upload_local_file(self, connection_string, local_file_path, share_name,

dest_file_path):
try:
source_file = open(local_file_path, "rb")
data = source_file.read()
# Create a ShareFileClient from a connection string

file_client = ShareFileClient.from_connection_string(
connection_string, share_name, dest_file_path)
print("Uploading to:", share_name + "/" + dest_file_path)

file_client.upload_file(data)

except ResourceNotFoundError as ex:

print("ResourceNotFoundError:", ex.message)

Para enumerar los archivos y directorios de un subdirectorio, use el método
list_directories_and_files. Este método devuelve un objeto iterable de paginación
automática. El código siguiente genera el nombre de cada archivo y subdirectorio del
directorio especificado en la consola.
Python
def list_files_and_dirs(self, connection_string, share_name, dir_name):

try:
for item in list(share_client.list_directories_and_files(dir_name)):

if item["is_directory"]:
print("Directory:", item["name"])
else:
print("File:", dir_name + "/" + item["name"])

Para descargar los datos de un archivo, use download_file.
En el ejemplo siguiente se muestra cómo usar download_file para obtener el contenido

del archivo especificado y almacenarlo localmente con el valor DOWNLOADED-
antepuesto al nombre de archivo.
Python
def download_azure_file(self, connection_string, share_name, dir_name,

file_name):
try:
# Build the remote path
source_file_path = dir_name + "/" + file_name
# Add a prefix to the filename to

# distinguish it from the uploaded file
dest_file_name = "DOWNLOADED-" + file_name

connection_string, share_name, source_file_path)
print("Downloading to:", dest_file_name)
# Open a file for writing bytes on the local system

with open(dest_file_name, "wb") as data:
# Download the file from Azure into a stream
stream = file_client.download_file()
# Write the stream to the local file
data.write(stream.readall())


compartido
Puede crear una copia a un punto dado de todo el recurso compartido de archivos.
Python
def create_snapshot(self, connection_string, share_name):

try:
# Create a snapshot
snapshot = share_client.create_snapshot()
print("Created snapshot:", snapshot["snapshot"])
# Return the snapshot time so

# it can be accessed later
return snapshot["snapshot"]

Enumeración de recursos compartidos e

instantáneas
Puede enumerar todas las instantáneas para un recurso compartido determinado.
Python
def list_shares_snapshots(self, connection_string):

try:
# Create a ShareServiceClient from a connection string
service_client =
ShareServiceClient.from_connection_string(connection_string)
# List the shares in the file service

shares = list(service_client.list_shares(include_snapshots=True))
for share in shares:

if (share["snapshot"]):
print("Share:", share["name"], "Snapshot:",
share["snapshot"])
else:
print("Share:", share["name"])

Examinación de instantáneas de recurso
compartido
Puede examinar cada instantánea de recurso compartido para recuperar archivos y
directorios desde ese punto dado.
Python
def browse_snapshot_dir(self, connection_string, share_name, snapshot_time,

dir_name):
try:
snapshot = ShareClient.from_connection_string(
conn_str=connection_string, share_name=share_name,
snapshot=snapshot_time)
print("Snapshot:", snapshot_time)
for item in list(snapshot.list_directories_and_files(dir_name)):

if item["is_directory"]:
print("Directory:", item["name"])
else:
print("File:", dir_name + "/" + item["name"])

Obtención del archivo desde una instantánea

de recurso compartido
Puede descargar un archivo de una instantánea de recurso compartido, lo que le
permite restaurar una versión anterior de un archivo.
Python
def download_snapshot_file(self, connection_string, share_name,

snapshot_time, dir_name, file_name):
try:
# Build the remote path
source_file_path = dir_name + "/" + file_name
# Add a prefix to the local filename to

# indicate it's a file from a snapshot
dest_file_name = "SNAPSHOT-" + file_name

snapshot_file_client = ShareFileClient.from_connection_string(
conn_str=connection_string, share_name=share_name,
file_path=source_file_path, snapshot=snapshot_time)
print("Downloading to:", dest_file_name)
# Open a file for writing bytes on the local system

with open(dest_file_name, "wb") as data:
# Download the file from Azure into a stream
stream = snapshot_file_client.download_file()
# Write the stream to the local file
data.write(stream.readall())


compartido única
Puede eliminar una instantánea de recurso compartido única.
Python
def delete_snapshot(self, connection_string, share_name, snapshot_time):

try:
# Create a ShareClient for a snapshot
snapshot_client =
ShareClient.from_connection_string(conn_str=connection_string,
share_name=share_name, snapshot=snapshot_time)
print("Deleting snapshot:", snapshot_time)
# Delete the snapshot

snapshot_client.delete_share()

Para eliminar un archivo, llame a delete_file.
Python
def delete_azure_file(self, connection_string, share_name, file_path):

try:
connection_string, share_name, file_path)
print("Deleting file:", share_name + "/" + file_path)
# Delete the file

file_client.delete_file()

Eliminación de un recurso compartido cuando

existen instantáneas de recurso compartido
Para eliminar un recurso compartido que contenga instantáneas, llame a delete_share
con delete_snapshots=True .
Python
def delete_share(self, connection_string, share_name):

try:
print("Deleting share:", share_name)
# Delete the share and snapshots

share_client.delete_share(delete_snapshots=True)

Pasos siguientes
Ahora que ha aprendido a manipular Azure Files con Python, siga estos vínculos para
obtener más información.
Centro para desarrolladores de Python

API de REST de servicios de Azure Storage
SDK de Microsoft Azure Storage para Python
Para ver ejemplos de código relacionados que usan los SDK de la versión 2 en desuso
de Python, consulte Ejemplos de código que usan la versión 2 de Python.
Determinación del modelo de clave de
cifrado de Azure Storage que está en
uso para la cuenta de almacenamiento
Artículo • 01/06/2023
Azure Storage cifra automáticamente los datos de la cuenta de almacenamiento. El

cifrado de Azure Storage ofrece dos opciones para administrar claves de cifrado en el
nivel de la cuenta de almacenamiento:
Claves administradas por Microsoft. De forma predeterminada, Microsoft

administra las claves que se usan para cifrar su cuenta de almacenamiento.
Claves administradas por el cliente. Opcionalmente, puede elegir administrar las
claves de cifrado de su cuenta de almacenamiento. Las claves administradas por el
cliente se deben almacenar en Azure Key Vault.
Además, puede proporcionar una clave de cifrado en el nivel de una solicitud individual
para algunas operaciones de Blob Storage. Si se especifica una clave de cifrado en la
solicitud, esta invalida la clave de cifrado que está activa en la cuenta de
almacenamiento. Para más información, consulte Especificación de una clave
proporcionada por el cliente en una solicitud a Blob Storage.
Para más información sobre claves de cifrado, consulte Cifrado de Azure Storage para
datos en reposo.
Comprobación del modelo de clave de cifrado

de la cuenta de almacenamiento
Para determinar si una cuenta de almacenamiento usa claves administradas por
Microsoft o claves administradas por el cliente para el cifrado, use uno de los métodos
siguientes.
Azure Portal
Para comprobar el modelo de cifrado de la cuenta de almacenamiento mediante

Azure Portal, siga estos pasos:
1. En Azure Portal, vaya a la cuenta de almacenamiento.

2. Seleccione el valor de Cifrado y anótelo.
En la imagen siguiente se muestra una cuenta de almacenamiento cifrada con
claves administradas por Microsoft:
En la imagen siguiente se muestra una cuenta de almacenamiento cifrada con

claves administradas por el cliente:
Pasos siguientes
Configuración de claves administradas
por el cliente en el mismo inquilino para
una nueva cuenta de almacenamiento
Artículo • 23/03/2023
Azure Storage cifra todos los datos de las cuentas de almacenamiento en reposo. De
manera predeterminada, los datos se cifran con claves administradas por Microsoft. Para
tener un mayor control sobre las claves de cifrado, puede administrar sus propias claves.
Las claves administradas por el cliente deben estar almacenadas en Azure Key Vault o en
el modelo de seguridad de hardware (HSM) administrado de Azure Key Vault.
En este artículo se muestra cómo configurar el cifrado con claves administradas por el
cliente en el momento en que se crea una nueva cuenta de almacenamiento. Las claves
administradas por el cliente se almacenan en un almacén de claves.
Para aprender a configurar claves administradas por el cliente para una cuenta de
almacenamiento existente, consulte Configuración de claves administradas por el cliente
en un almacén de claves de Azure para una cuenta de almacenamiento existente.
７ Nota
Configuración del almacén de claves

Puede usar un almacén de claves nuevo o existente para almacenar las claves
administradas por el cliente. La cuenta de almacenamiento y el almacén de claves
pueden estar en distintas regiones o suscripciones del mismo inquilino. Para más
información sobre Azure Key Vault, consulte Introducción a Azure Key Vault y ¿Qué es
Azure Key Vault?
El uso de claves administradas del cliente con el cifrado de Azure Storage requiere la
eliminación temporal y la protección de purga estén habilitadas en el almacén de claves.
La eliminación temporal está habilitada de manera predeterminada al crear un almacén
de claves y no se puede deshabilitar. Puede habilitar la protección de purga cuando cree
el almacén de claves o después de crearlo.
Azure Key Vault admite la autorización con Azure RBAC mediante un modelo de
permisos de Azure RBAC. Microsoft recomienda usar el modelo de permisos de RBAC de
Azure sobre las directivas de acceso del almacén de claves. Para más información,
consulte Concesión de permisos a las aplicaciones para que accedan a una instancia de
Azure Key Vault mediante Azure RBAC.
Azure Portal
Para obtener información sobre cómo crear un almacén de claves con Azure Portal,
consulte Inicio rápido: Creación de un almacén de claves mediante Azure Portal. Al
crear el almacén de claves, seleccione Habilitar protección de purga, como se
muestra en la siguiente imagen.
Para habilitar la protección de purga en un almacén de claves existente, siga estos

pasos:
1. Vaya al almacén de claves en Azure Portal.

2. En Configuración, elija Propiedades.
3. En la sección Protección de purga, elija Habilitar protección de purga.
Adición de una clave
A continuación, agregue una clave al almacén de claves. Antes de agregar la clave,
asegúrese de que se le ha asignado el rol Key Vault Crypto Officer.
El cifrado de Azure Storage admite claves RSA y RSA-HSM de los tamaños

2048, 3072 y 4096. Para más información sobre los tipos de clave admitidos, consulte
Acerca de las claves.
Azure Portal
Para obtener información sobre cómo agregar una clave con Azure Portal, consulte
Inicio rápido: Establecimiento y recuperación de una clave de Azure Key Vault
mediante Azure Portal.
Uso de una identidad administrada asignada

por el usuario para autorizar el acceso a un
almacén de claves
Si habilita claves administradas por el cliente para una nueva cuenta de
almacenamiento, debe especificar una identidad administrada asignada por el usuario.
existente, puede usar una identidad administrada asignada por el usuario o asignada
por el sistema.
Al configurar claves administradas por el cliente con una identidad administrada

asignada por el usuario, la identidad administrada asignada por el usuario se usa para
autorizar el acceso al almacén de claves que contiene la clave. Debe crear la identidad
asignada por el usuario antes de configurar las claves administradas por el cliente.
Se crea una identidad administrada asignada por el usuario como recurso de Azure
independiente. Para más información sobre las identidades administradas asignadas por
el usuario, consulte Tipos de identidad administrada. Para más información sobre cómo
crear y administrar una identidad administrada asignada por el usuario, consulte
Administración de identidades administradas asignadas por el usuario.
La identidad administrada asignada por el usuario debe tener los permisos para acceder
a la clave en el almacén. Asigne el rol Usuario de cifrado del servicio criptográfico de
Key Vault a la identidad administrada asignada por el usuario con el ámbito del almacén
de claves para conceder estos permisos.
Azure Portal
Para poder configurar claves administradas por el cliente con una identidad
administrada asignada por el usuario, debe asignar el rol de usuario de cifrado de
servicios criptográficos Key Vault a la identidad administrada asignada por el
usuario, con ámbito en el almacén de claves. Este rol concede los permisos de
identidad administrada asignada por el usuario para acceder a la clave del almacén
de claves. Para más información sobre cómo asignar roles de Azure RBAC con Azure
Portal, consulte Asignación de roles de Azure mediante Azure Portal.
Al configurar las claves administradas por el cliente con Azure Portal, puede
seleccionar una identidad asignada por el usuario existente mediante la interfaz de
usuario del portal.
Configuración de claves administradas por el

cliente para una nueva cuenta de
almacenamiento
Al configurar el cifrado con claves administradas por el cliente para una nueva cuenta de
almacenamiento, puede optar por actualizar automáticamente la versión de la clave que
se usa para el cifrado de Azure Storage siempre que haya disponible una versión nueva
en el almacén de claves asociado. Como alternativa, puede especificar explícitamente la
versión de la clave que se usará para el cifrado hasta que la versión de la clave se
actualice manualmente.
Debe usar una identidad administrada asignada por el usuario existente para autorizar
el acceso al almacén de claves al configurar las claves administradas por el cliente
cuando crea la cuenta de almacenamiento. La identidad administrada asignada por el
usuario debe tener los permisos adecuados para acceder al almacén de claves. Para
obtener más información, consulte Autenticar en Azure Key Vault.
Configuración del cifrado para la actualización

automática de las versiones de clave
Azure Storage puede actualizar automáticamente la clave administrada por el cliente
que se usa para el cifrado, de modo que se use la versión más reciente de esta del
almacén de claves. Azure Storage comprueba el almacén de claves diariamente para
obtener una nueva versión de la clave. Cuando hay disponible una versión nueva, Azure
Storage empieza automáticamente a usar la versión más reciente de la clave para el
cifrado.
） Importante
Azure Storage comprueba solo una vez al día el almacén de claves para obtener
una nueva versión de la clave. Al girar una clave, asegúrese de esperar 24 horas
antes de deshabilitar la versión anterior.
Azure Portal
Para configurar las claves administradas por el cliente de una nueva cuenta de
almacenamiento con la actualización automática de la versión de clave, siga estos
pasos:
1. En Azure Portal, vaya a la página Cuentas de almacenamiento y seleccione el

botón Crear para crear una cuenta.
2. Siga los pasos descritos en Crear una cuenta de almacenamiento para rellenar
los campos de las pestañas Conceptos básicos, Opciones avanzadas, Redes y
Protección de datos.
3. En la pestaña Cifrado, indique para qué servicios desea habilitar la

compatibilidad con las claves administradas por el cliente en el campo Enable
support for customer-managed keys (Habilitar la compatibilidad con claves
administradas por el cliente).
4. En el campo Tipo de cifrado, seleccione Claves administradas por el cliente

(CMK).
5. En el campo Clave de cifrado, elija Seleccionar una clave y un almacén de

claves, y especifique la clave y el almacén de claves.
6. En el campo Identidad asignada por el usuario, seleccione una identidad

administrada asignada por el usuario existente.
7. Seleccione el botón Revisar para ejecutar la validación y crear la cuenta.
También puede configurar las claves administradas por el cliente con la

actualización manual de las versiones de la clave cuando crea una cuenta de
almacenamiento. Siga los pasos que se indican en Configuración del cifrado para la
actualización manual de las versiones de la clave.
Configuración del cifrado para la actualización manual de

las versiones de la clave
Si prefiere actualizar manualmente la versión de la clave, especifique de manera explícita
la versión cuando configure el cifrado con las claves administradas por el cliente al crear
la cuenta de almacenamiento. En este caso, Azure Storage no actualizará
automáticamente las versiones de la clave cuando se cree una nueva versión en el
almacén de claves. Para usar una nueva versión de clave, debe actualizar manualmente
la versión usada para el cifrado de Azure Storage.
Azure Portal
Para configurar las claves administradas por el cliente con la actualización manual
de la versión de clave en Azure Portal, especifique el URI de la clave, incluida la
versión, al momento de crear la cuenta de almacenamiento. Para especificar una
clave como URI, siga estos pasos:
1. En Azure Portal, vaya a la página Cuentas de almacenamiento y seleccione el

botón Crear para crear una cuenta.


(CMK).
5. Para buscar el URI de la clave en Azure Portal, vaya al almacén de claves y

seleccione la opción de configuración Claves. Seleccione la clave cuyas
versiones desee ver. Seleccione cualquiera de las versiones de clave para ver
su configuración.
6. Copie el valor del campo Identificador de clave, que proporciona el URI.

7. En las opciones de Clave de cifrado de la cuenta de almacenamiento, elija la
opción Escribir el URI de la clave.
8. Pegue el identificador URI que ha copiado en el campo URI de clave. Incluya

la versión de la clave en el URI para configurar la actualización manual de la
versión de la clave.
9. Para especificar una identidad administrada asignada por el usuario, elija el

vínculo Seleccionar una identidad.
Cambio de la clave
Puede cambiar la clave que usa para el cifrado de Azure Storage en cualquier momento.
７ Nota
Al cambiar la clave o la versión de la clave, la protección de la clave de cifrado raíz

momento. No se requiere ninguna acción adicional por su parte para asegurarse de
que los datos están protegidos. Cambiar la clave o rotar la versión de la clave no
afectará al rendimiento. No hay tiempo de inactividad asociado al cambio de clave
o a la rotación de la versión de la clave.
Azure Portal
Para cambiar la clave con Azure Portal, haga lo siguiente:
1. Vaya a la cuenta de almacenamiento y muestre las opciones de configuración

de cifrado.
2. Seleccione el almacén de claves y elija una clave nueva.
3. Guarde los cambios.
Si la nueva clave está en otro almacén de claves, debe conceder a la identidad

administrada acceso a la clave en el nuevo almacén. Si elige la actualización manual de
la versión de la clave, también deberá actualizar el URI del almacén de claves.

por el cliente
Para revocar temporalmente el acceso a una cuenta de almacenamiento que usa claves
administradas por el cliente, deshabilite la clave que se usa actualmente en el almacén
de claves. No hay ningún impacto en el rendimiento ni en el tiempo de inactividad
asociados con deshabilitar y volver a habilitar la clave.
leen o escriben en un blob o en sus metadatos. Para obtener información sobre qué
operaciones producirán errores, consulte Revocación del acceso a una cuenta de
Ｕ Precaución
Al deshabilitar la clave en el almacén de claves, los datos de la cuenta de

Azure Storage permanecerán cifrados, pero se volverán inaccesibles hasta que se
pueda volver a habilitar la clave.
Azure Portal
Para deshabilitar una clave administrada por el cliente con Azure Portal, siga estos
pasos:
1. Vaya al almacén de claves que contiene la clave.

2. En Objetos, seleccione Claves.
3. Haga clic con el botón derecho en la clave y seleccione Deshabilitar.
Al deshabilitar la clave, se producirá un error al intentar acceder a los datos de la cuenta

de almacenamiento con el código de error 403 (Prohibido). Para obtener una lista de las
operaciones de la cuenta de almacenamiento que se verán afectadas al deshabilitar la
clave, consulte Revocación del acceso a una cuenta de almacenamiento que usa claves
administradas por el cliente.
Volver a las claves administradas por Microsoft

Puede cambiar de claves administradas por el cliente a claves administradas por
Microsoft en cualquier momento, mediante Azure Portal, PowerShell o la CLI de Azure.
Azure Portal
Para cambiar de claves administradas por el cliente a claves administradas por

Microsoft en Azure Portal, siga estos pasos:
2. En Seguridad y redes, selecciona Cifrado.
3. Cambie el Tipo de cifrado a Claves administradas por Microsoft.

Pasos siguientes
Azure para una cuenta de almacenamiento existente
HSM administrado de Azure Key Vault.
por el cliente en el mismo inquilino para
una cuenta de almacenamiento
existente
Artículo • 07/11/2023
cliente para una cuenta de almacenamiento existente cuando la cuenta de
almacenamiento y el almacén de claves están en el mismo inquilino. Las claves
administradas por el cliente se almacenan en un almacén de claves.
Para aprender a configurar claves administradas por el cliente para una nueva cuenta de
almacenamiento, consulte Configuración de claves administradas por el cliente en un
almacén de claves de Azure para una cuenta de almacenamiento nueva.
Para obtener información sobre cómo configurar el cifrado con las claves administradas
por el cliente almacenadas en un HSM administrado, consulte Configuración del cifrado
con claves administradas por el cliente almacenadas en HSM administrado de Azure Key
Vault.
７ Nota
Configuración del almacén de claves

Puede usar un almacén de claves nuevo o existente para almacenar las claves
administradas por el cliente. La cuenta de almacenamiento y el almacén de claves
pueden estar en distintas regiones o suscripciones del mismo inquilino. Para más
información sobre Azure Key Vault, consulte Introducción a Azure Key Vault y ¿Qué es
Azure Key Vault?
El uso de claves administradas del cliente con el cifrado de Azure Storage requiere la
eliminación temporal y la protección de purga estén habilitadas en el almacén de claves.
La eliminación temporal está habilitada de manera predeterminada al crear un almacén
de claves y no se puede deshabilitar. Puede habilitar la protección de purga cuando cree
el almacén de claves o después de crearlo.
Azure Key Vault admite la autorización con Azure RBAC mediante un modelo de
permisos de Azure RBAC. Microsoft recomienda usar el modelo de permisos de RBAC de
Azure sobre las directivas de acceso del almacén de claves. Para más información,
consulte Concesión de permisos a las aplicaciones para que accedan a una instancia de
Azure Key Vault mediante Azure RBAC.
Azure Portal
Para obtener información sobre cómo crear un almacén de claves con Azure Portal,
consulte Inicio rápido: Creación de un almacén de claves mediante Azure Portal. Al
crear el almacén de claves, seleccione Habilitar protección de purga, como se
Para habilitar la protección de purga en un almacén de claves existente, siga estos
pasos:
1. Vaya al almacén de claves en Azure Portal.

2. En Configuración, elija Propiedades.
3. En la sección Protección de purga, elija Habilitar protección de purga.
Adición de una clave

A continuación, agregue una clave al almacén de claves. Antes de agregar la clave,
asegúrese de que se le ha asignado el rol Key Vault Crypto Officer.
El cifrado de Azure Storage admite claves RSA y RSA-HSM de los tamaños

2048, 3072 y 4096. Para más información sobre los tipos de clave admitidos, consulte
Acerca de las claves.
Azure Portal
Para obtener información sobre cómo agregar una clave con Azure Portal, consulte
Inicio rápido: Establecimiento y recuperación de una clave de Azure Key Vault
mediante Azure Portal.
Elección de una identidad administrada para

autorizar el acceso al almacén de claves
Al habilitar las claves administradas por el cliente para una cuenta de almacenamiento
existente, debe especificar una identidad administrada que se usará para autorizar el
acceso al almacén de claves que contiene la clave. La identidad administrada debe tener
permisos para acceder a la clave del almacén de claves.
La identidad administrada que autoriza el acceso al almacén de claves puede ser una
identidad administrada asignada por el usuario o por el sistema. Para más información
sobre los tipos de identidad administrada asignada por el sistema y asignada por el
usuario, consulte Tipos de identidad administrada.
Uso de una identidad administrada asignada por el

usuario para autorizar el acceso
Si habilita claves administradas por el cliente para una nueva cuenta de
almacenamiento, debe especificar una identidad administrada asignada por el usuario.
existente, puede usar una identidad administrada asignada por el usuario o asignada
por el sistema.
Al configurar claves administradas por el cliente con una identidad administrada

asignada por el usuario, la identidad administrada asignada por el usuario se usa para
autorizar el acceso al almacén de claves que contiene la clave. Debe crear la identidad
asignada por el usuario antes de configurar las claves administradas por el cliente.
Se crea una identidad administrada asignada por el usuario como recurso de Azure
independiente. Para más información sobre las identidades administradas asignadas por
el usuario, consulte Tipos de identidad administrada. Para más información sobre cómo
crear y administrar una identidad administrada asignada por el usuario, consulte
Administración de identidades administradas asignadas por el usuario.
a la clave en el almacén. Asigne el rol Usuario de cifrado del servicio criptográfico de
Key Vault a la identidad administrada asignada por el usuario con el ámbito del almacén
de claves para conceder estos permisos.
Azure Portal
Para poder configurar claves administradas por el cliente con una identidad
administrada asignada por el usuario, debe asignar el rol de usuario de cifrado de
servicios criptográficos Key Vault a la identidad administrada asignada por el
usuario, con ámbito en el almacén de claves. Este rol concede los permisos de
identidad administrada asignada por el usuario para acceder a la clave del almacén
Al configurar las claves administradas por el cliente con Azure Portal, puede
seleccionar una identidad asignada por el usuario existente mediante la interfaz de
usuario del portal.
Uso de una identidad administrada asignada por el

sistema para autorizar el acceso
Una identidad administrada asignada por el sistema está asociada a una instancia de un
servicio de Azure, en este caso una cuenta de Azure Storage. Debe asignar
explícitamente una identidad administrada asignada por el sistema a una cuenta de
almacenamiento para poder usar la identidad administrada asignada por el sistema para
autorizar el acceso al almacén de claves que contiene la clave administrada por el
cliente.
Solo las cuentas de almacenamiento existentes pueden usar una identidad asignada por
el sistema para autorizar el acceso al almacén de claves. Las nuevas cuentas de
almacenamiento deben usar una identidad asignada por el usuario si las claves
administradas por el cliente se configuran durante la creación de las cuentas.
a la clave del almacén de claves. Asigne el rol Usuario de cifrado de servicios
criptográficos de Key Vault a la identidad administrada asignada por el sistema con el
ámbito del almacén de claves para conceder estos permisos.
Azure Portal
Para poder configurar las claves administradas por el cliente con una identidad
administrada asignada por el sistema, debe asignar el rol Usuario de cifrado de
servicios criptográficos de Key Vault a la identidad administrada asignada por el
sistema, con ámbito en el almacén de claves. Este rol concede los permisos de
identidad administrada asignada por el sistema para acceder a la clave del almacén
Cuando configura claves administradas por el cliente con Azure Portal con una
identidad administrada asignada por el sistema, esta se asigna en segundo plano a
la cuenta de almacenamiento.

cliente para una cuenta existente
Al configurar el cifrado con claves administradas por el cliente para una cuenta de
almacenamiento existente, puede optar por actualizar automáticamente la versión de la
clave que se usa para el cifrado de Azure Storage siempre que haya disponible una
versión nueva en el almacén de claves asociado. Como alternativa, puede especificar
explícitamente la versión de la clave que se usará para el cifrado hasta que la versión de
la clave se actualice manualmente.
Cuando se cambia la versión de la clave, ya sea automáticamente o manualmente,

cambia la protección de la clave de cifrado raíz, pero los datos de la cuenta de
Azure Storage permanecen cifrados en todo momento. No se requiere ninguna acción
adicional por su parte para asegurarse de que los datos están protegidos. Rotar la
versión clave no afecta el rendimiento. No hay tiempo de inactividad asociado a la
rotación de la versión de la clave.
Puede usar una identidad administrada asignada por el sistema o por el usuario para
autorizar el acceso al almacén de claves al configurar las claves administradas por el
cliente para una cuenta de almacenamiento existente.
７ Nota
Para rotar una clave, cree una nueva versión de la misma en Azure Key Vault. Azure
Storage no controla la rotación de claves, por lo que deberá administrar la rotación
de la clave en el almacén de claves. Puede configurar la rotación automática de
claves en Azure Key Vault o rotar la clave de forma manual.
Configuración del cifrado para la actualización

automática de las versiones de clave
Azure Storage puede actualizar automáticamente la clave administrada por el cliente
que se usa para el cifrado, de modo que se use la versión más reciente de esta del
almacén de claves. Azure Storage comprueba el almacén de claves diariamente para
obtener una nueva versión de la clave. Cuando hay disponible una versión nueva, Azure
Storage empieza automáticamente a usar la versión más reciente de la clave para el
cifrado.
） Importante
una nueva versión de la clave. Al girar una clave, asegúrese de esperar 24 horas
antes de deshabilitar la versión anterior.
Azure Portal
Para configurar las claves administradas por el cliente para una cuenta existente con
la actualización automática de la versión de clave en Azure Portal, siga estos pasos:

2. En Seguridad y redes, selecciona Cifrado. De forma predeterminada, la
administración de claves está establecida en Claves administradas por
Microsoft, como se muestra en la siguiente imagen:
3. Seleccione la opción Claves administradas por el cliente. Si la cuenta se

configuró anteriormente para Claves administradas por el cliente con la
actualización manual de la versión de la clave, seleccione Cambiar clave cerca
de la parte inferior de la página.
4. Elija la opción Select from Key Vault (Seleccionar desde almacén de claves).
5. Elija Seleccione un almacén de claves y una clave.
6. Seleccione el almacén de claves que contiene la clave que desea usar. También
puede crear un almacén de claves.
7. Seleccione la clave en el almacén de claves. También puede crear una clave.

8. Seleccione el tipo de identidad que desea usar para autenticar el acceso al
almacén de claves. Las opciones incluyen Asignada por el sistema (el valor
predeterminado) o Asignada por el usuario. Para más información sobre cada
tipo de identidad administrada, consulte Tipos de identidad administrada.
a. Si selecciona Asignada por el sistema, la identidad administrada asignada
por el sistema para la cuenta de almacenamiento se crea en segundo
plano, en caso de que no exista.
b. Si selecciona Asignada por el usuario, debe seleccionar una identidad
existente asignada por el usuario que tenga permisos para acceder al
almacén de claves. Para aprender a crear una identidad asignada por el
usuario, consulte Administración de identidades administradas asignadas
por el usuario.
Después de especificar la clave, Azure Portal indica que está habilitada la

actualización automática de la versión de la clave y muestra la versión de la clave
actualmente en uso para el cifrado. El portal también muestra el tipo de identidad
administrada que se usa para autorizar el acceso al almacén de claves y el
identificador de entidad de seguridad de la identidad administrada.
Configuración del cifrado para la actualización manual de
las versiones de la clave
Si prefiere actualizar manualmente la versión de la clave, especifique de manera explícita
la versión en el momento en que configure el cifrado con las claves administradas por el
cliente. En este caso, Azure Storage no actualizará automáticamente las versiones de la
clave cuando se cree una nueva versión en el almacén de claves. Para usar una nueva
versión de clave, debe actualizar manualmente la versión usada para el cifrado de Azure
Storage.
Azure Portal
Para configurar las claves administradas por el cliente con la actualización manual
de la versión de clave en Azure Portal, especifique el URI de la clave, incluida la
versión. Para especificar una clave como URI, siga estos pasos:
1. Para buscar el URI de la clave en Azure Portal, vaya al almacén de claves y

seleccione la opción de configuración Claves. Seleccione la clave cuyas
versiones desee ver. Seleccione cualquiera de las versiones de clave para ver
su configuración.
2. Copie el valor del campo Identificador de clave, que proporciona el URI.
3. En las opciones de Clave de cifrado de la cuenta de almacenamiento, elija la

opción Escribir el URI de la clave.
4. Pegue el identificador URI que ha copiado en el campo URI de clave. Omita la

versión de la clave en el URI para habilitar las actualizaciones automáticas de
la versión de la clave.
5. Especifique el identificador de la suscripción que contiene el almacén de
claves.
6. Especifique una identidad administrada asignada por el sistema o el usuario.
Cambio de la clave
７ Nota

Azure Portal

de cifrado.
Si la nueva clave está en otro almacén de claves, debe conceder a la identidad

administrada acceso a la clave en el nuevo almacén. Si elige la actualización manual de
la versión de la clave, también deberá actualizar el URI del almacén de claves.

por el cliente
Ｕ Precaución

Azure Portal
pasos:


Azure Portal


Pasos siguientes
Azure para una nueva cuenta de almacenamiento
por el cliente entre inquilinos para una
Artículo • 21/10/2023
cliente en el momento en que se crea una nueva cuenta de almacenamiento. En el
escenario entre inquilinos, la cuenta de almacenamiento reside en un inquilino
administrado por un ISV, mientras que la clave usada para el cifrado de esa cuenta de
almacenamiento reside en un almacén de claves de un inquilino administrado por el
cliente.
Para aprender a configurar claves administradas por el cliente para una cuenta de
almacenamiento, consulte Configuración de claves administradas por el cliente entre
inquilinos para una cuenta de almacenamiento existente.
７ Nota
Información sobre las claves administradas por

el cliente entre inquilinos
Muchos proveedores de servicios que crean ofertas de software como servicio (SaaS) en
Azure quieren ofrecer a sus clientes la opción de administrar sus propias claves de
cifrado. Las claves administradas por el cliente permiten a un proveedor de servicios
cifrar los datos del cliente mediante una clave de cifrado administrada por el cliente del
proveedor de servicios y a la que no puede acceder el proveedor de servicios. En Azure,
el cliente del proveedor de servicios puede usar Azure Key Vault para administrar sus
claves de cifrado en su propio inquilino y suscripción de Microsoft Entra.
Los servicios y recursos de la plataforma Azure que pertenecen al proveedor de servicios

y que residen en el inquilino del proveedor de servicios requieren acceso a la clave del
inquilino del cliente para realizar las operaciones de cifrado y descifrado.
En la imagen siguiente se muestra un cifrado de datos en reposo con identidad

federada en un flujo de trabajo de CMK entre inquilinos que abarca un proveedor de
servicios y su cliente.
En el ejemplo anterior, hay dos inquilinos de Microsoft Entra: el inquilino de un

proveedor de servicios independiente (Inquilino 1) y el inquilino de un cliente (Inquilino
2). Inquilino 1 hospeda los servicios de la plataforma Azure y Inquilino 2 hospeda el
almacén de claves del cliente.
El proveedor de servicios crea un registro de aplicación multiinquilino en Inquilino 1. El

proveedor de servicios configura una credencial de identidad federada en esta
aplicación mediante una identidad administrada asignada por el usuario. A
continuación, el nombre y el identificador de la aplicación se comparten con el cliente.
Un usuario con los permisos adecuados instala la aplicación del proveedor de servicios
en el inquilino del cliente Inquilino 2. A continuación, un usuario concede a la entidad de
servicio asociada a la aplicación instalada acceso al almacén de claves del cliente. El
cliente también almacena la clave de cifrado, o la clave administrada por el cliente, en el
almacén de claves. El cliente comparte la ubicación de la clave (la dirección URL de la
clave) con el proveedor de servicios.
El proveedor de servicios ahora tiene lo siguiente:

Un id. de aplicación para una aplicación multiinquilino instalada en el inquilino del
cliente, a la que se le ha concedido acceso a la clave administrada por el cliente.
Una identidad administrada configurada como credencial en la aplicación
multiinquilino.
La ubicación de la clave en el almacén de claves del cliente.
Con estos tres parámetros, el proveedor de servicios aprovisiona recursos de Azure en

Inquilino 1 que se pueden cifrar con la clave administrada por el cliente en Inquilino 2.
Vamos a dividir la solución de un extremo a otro anterior en tres fases:
1. El proveedor de servicios configura identidades.

2. El cliente concede a la aplicación multiinquilino del proveedor de servicios acceso
a una clave de cifrado en Azure Key Vault.
3. El proveedor de servicios cifra los datos de un recurso de Azure mediante la CMK.
Las operaciones de la fase 1 serán una configuración única para la mayoría de las
aplicaciones del proveedor de servicios. Las operaciones de las fases 2 y 3 se repetirán
para cada cliente.
Fase 1: el proveedor de servicios configura una aplicación

de Microsoft Entra
Paso Descripción Rol mínimo en Rol mínimo en

RBAC de Azure RBAC de
Microsoft Entra
1. Cree un nuevo registro de aplicación de Microsoft None Desarrollador de

Entra multiinquilino o comience con un registro de aplicaciones
aplicación existente. Anote el id. de la aplicación
(id. de cliente) del registro de la aplicación
mediante Azure Portal, Microsoft Graph API, Azure
2. Cree una identidad administrada asignada por el Colaborador de None

usuario (que se usará como credencial de identidad
identidad federada). administrada
Azure Portal / CLI de Azure / Azure PowerShell/
Plantillas de Azure Resource Manager
3. Configure la identidad administrada asignada por None Propietario de la

el usuario como credencial de identidad federada aplicación
en la aplicación para que pueda suplantar la
identidad de la aplicación.
Referencia de Graph API / Azure Portal/ CLI de
Azure/ Azure PowerShell
Paso Descripción Rol mínimo en Rol mínimo en
RBAC de Azure RBAC de
Microsoft Entra
4. Comparta el nombre y el id. de la aplicación con el None None

cliente para que pueda instalar y autorizar la
aplicación.
Consideraciones para proveedores de servicio

No se recomiendan las plantillas de Azure Resource Manager (ARM) para crear
aplicaciones de Microsoft Entra.
Se puede usar la misma aplicación multiinquilino para acceder a las claves en
diversos inquilinos, como Inquilino 2, Inquilino3, Inquilino4, etc. En cada inquilino,
se crea una instancia independiente de la aplicación que tiene el mismo id. de
aplicación, pero un id. de objeto diferente. Por lo tanto, cada instancia de esta
aplicación se autoriza de forma independiente. Tenga en cuenta cómo se usa el
objeto de aplicación para esta característica a fin de crear particiones de la
aplicación en todos los clientes.
La aplicación puede tener un máximo de veinte credenciales de identidad
federada, lo que requiere que un proveedor de servicios comparta las
identidades federadas entre sus clientes. Para más información sobre las
consideraciones y restricciones del diseño de identidades federadas, consulte
Configuración de una aplicación para confiar en un proveedor de identidades
externo
En escenarios poco frecuentes, un proveedor de servicios puede usar un único
objeto de aplicación por cada cliente, pero eso implica costes de mantenimiento
considerables para administrar las aplicaciones a gran escala en todos los clientes.
En el inquilino del proveedor de servicios, no es posible automatizar la
comprobación del publicador.
Fase 2: el cliente autoriza el acceso al almacén de claves
Paso Descripción Roles de RBAC de Azure con Roles de

privilegios mínimos Microsoft Entra
con privilegios
mínimos
1. Recomendado: envíe al usuario None Usuarios con

para iniciar sesión en la aplicación. permisos para
Si el usuario puede iniciar sesión, instalar
existe una entidad de servicio para aplicaciones
la aplicación en su inquilino.
privilegios mínimos Microsoft Entra
con privilegios
mínimos
Use Microsoft Graph, Microsoft

Graph PowerShell, Azure PowerShell
o la CLI de Azure para crear la
entidad de servicio.
Construya una dirección URL de
consentimiento del administrador y
conceda consentimiento para todo
el inquilino para crear la entidad de
servicio mediante el id. de
aplicación.
2. Cree una instancia de Azure Key Se debe asignar a un usuario el None

Vault y una clave usada como clave rol Colaborador de Key Vault
administrada por el cliente. para crear el almacén de claves
Se debe asignar a un usuario el

rol Agente criptográfico de Key
Vault para agregar una clave al
almacén de claves.
3. Conceda a la identidad de la Para asignar el rol Usuario del None

aplicación consentida acceso al cifrado del servicio de cifrado
almacén de claves de Azure de Key Vault a la aplicación,
mediante la asignación del rol debe tener asignado el rol
Usuario del cifrado del servicio de Administrador de acceso de
cifrado de Key Vault. usuario.
4. Copie la dirección URL del almacén None None

de claves y el nombre de la clave en
la configuración de claves
administradas por el cliente de la
oferta de SaaS.
７ Nota
Para autorizar el acceso al HSM administrado para el cifrado mediante CMK,

consulte el ejemplo de la Cuenta de almacenamiento aquí. Para más información
sobre cómo administrar claves con HSM administrado, consulte Administración de
un HSM administrado mediante la CLI de Azure.
Consideraciones para clientes de proveedores de servicios

En el inquilino del cliente Inquilino 2 un administrador puede establecer directivas
para impedir que los usuarios que no sean administradores instalen aplicaciones.
Estas directivas pueden impedir que los usuarios que no sean administradores
creen entidades de servicio. Si se configura una directiva de este tipo, los usuarios
con permisos para crear entidades de servicio deberán participar.
El acceso a Azure Key Vault se puede autorizar mediante directivas de acceso o
RBAC de Azure. Al conceder acceso a un almacén de claves, asegúrese de usar el
mecanismo activo para el almacén de claves.
Un registro de aplicación de Microsoft Entra tiene un id. de aplicación (id. de
cliente). Cuando la aplicación se instala en el inquilino, se crea una entidad de
servicio. La entidad de servicio comparte el mismo id. de aplicación que el registro
de la aplicación, pero genera su propio id. de objeto. Al autorizar a la aplicación a
tener acceso a los recursos, es posible que tenga que usar la entidad de servicio
Name o la propiedad ObjectID .
Fase 3: el proveedor de servicios cifra los datos de un

recurso de Azure mediante la clave administrada por el
cliente
Una vez completada las fases 1 y 2, el proveedor de servicios puede configurar el cifrado
en el recurso de Azure con la clave y el almacén de claves en el inquilino del cliente y el
recurso de Azure en el inquilino del ISV. El proveedor de servicios puede configurar
claves administradas por el cliente entre inquilinos con las herramientas del cliente
compatibles con ese recurso de Azure, con una plantilla de ARM o con la API REST.

cliente entre inquilinos
En esta sección se describe cómo configurar una clave administrada por el cliente (CMK)
entre inquilinos y cifrar los datos de los clientes. Obtendrá información sobre cómo
cifrar los datos de los clientes en un recurso de Tenant1 mediante una CMK almacenada
en un almacén de claves en Tenant2. Puede usar Azure Portal, Azure PowerShell o la CLI
de Azure.
Portal
Inicie sesión en Azure Portal y siga los pasos siguientes.
El proveedor de servicios configura identidades.

El proveedor de servicios realiza los pasos siguientes en el inquilino Tenant1 del
proveedor de servicios.
El proveedor de servicios crea un registro de aplicaciones

multiinquilino
Puede crear un nuevo registro de aplicación de Microsoft Entra multiinquilino o
comenzar con un registro de aplicación multiinquilino existente. Si comienza con un
registro de aplicación existente, anote el id. de aplicación (id. de cliente) de la
aplicación.
Para crear un nuevo registro, siga estos pasos:
1. Busque Microsoft Entra ID en el cuadro de búsqueda. Busque y seleccione la

extensión Microsoft Entra ID.
2. Seleccione Administrar > Registros de aplicaciones en el panel izquierdo.
3. Seleccione + Nuevo registro.
4. Proporcione el nombre del registro de aplicación y seleccione Cuenta en

cualquier directorio organizativo (cualquier directorio de Microsoft Entra:
multiinquilino).
5. Seleccione Registrar.
6. Anote el valor de applicationId/ClientId de la aplicación.

El proveedor de servicios crea una identidad administrada
asignada por el usuario.
Cree una identidad administrada asignada por el usuario que se usará como
credencial de identidad federada.
1. Busque Identidades administradas en el cuadro de búsqueda. Busque y

seleccione la extensión Identidades administradas.
2. Seleccione + Create (+ Crear).
3. Proporcione el grupo de recursos, la región y el nombre de la identidad

administrada.
5. Si la implementación se realiza correctamente, anote el valor de resourceId de

Azure de la identidad administrada asignada por el usuario, que está
disponible en Propiedades. Por ejemplo:
/subscriptions/tttttttt-0000-tttt-0000-
tttt0000tttt/resourcegroups/XTCMKDemo/providers/Microsoft.ManagedIdentity/
userAssignedIdentities/ConsotoCMKDemoUA
El proveedor de servicios configura la identidad administrada

asignada por el usuario como una credencial federada en la
aplicación.
Configure una identidad administrada asignada por el usuario como credencial de
identidad federada en la aplicación para que pueda suplantar la identidad de la
aplicación.
1. Vaya a Microsoft Entra ID > Registros de aplicaciones > su aplicación.
2. Seleccione Certificados y secretos.
3. Seleccione Credenciales federadas.
4. Seleccione + Agregar credencial.
5. En Escenario de credencial federada, seleccione Claves administradas por el

cliente.
6. Haga clic en Seleccionar una identidad administrada. En el panel, seleccione

la suscripción. En Identidad administrada, seleccione Identidad administrada
asignada por el usuario. En el cuadro Seleccionar, busque la identidad
administrada que creó anteriormente y haga clic en Seleccionar en la parte
inferior del panel.

7. En Detalles de la credencial, proporcione un nombre y una descripción

opcional para la credencial y seleccione Agregar.
El proveedor de servicios comparte el id. de aplicación con el

cliente.
Busque el identificador (identificador de cliente) de la aplicación multiinquilino y

compártalo con el cliente.
El cliente concede a la aplicación del proveedor de

servicios acceso a la clave en el almacén de claves.
El cliente realiza los pasos siguientes en el inquilino Tenant2 del cliente. El cliente puede
usar Azure Portal, Azure PowerShell o la CLI de Azure.
El usuario que ejecuta los pasos debe ser un administrador con un rol con privilegios,
como Administrador de aplicaciones, Administrador de aplicaciones en la nube o
Administrador global.
Portal
El cliente instala la aplicación del proveedor de servicios en el

inquilino del cliente
Para instalar la aplicación registrada del proveedor de servicios en el inquilino del
cliente, cree una entidad de servicio con el id. de aplicación de la aplicación
registrada. Puede crear la entidad de servicio de cualquiera de las maneras
siguientes:
Use Microsoft Graph, Microsoft Graph PowerShell, Azure PowerShell o la CLI

de Azure para crear manualmente la entidad de servicio.
Construya una dirección URL de consentimiento del administrador y conceda
consentimiento para todo el inquilino para crear la entidad de servicio. Tendrá
que proporcionar esto con su AppId.
El cliente crea un almacén de claves
Para crear el almacén de claves, a la cuenta del usuario se le debe asignar el rol
Colaborador de Key Vault u otro rol que permita la creación de un almacén de
claves.
1. En el menú de Azure Portal o en la página principal, seleccione + Crear un

recurso. En el cuadro de búsqueda, escriba Almacenes de claves. En la lista de
resultados, seleccione Almacenes de claves. En la página Almacenes de
claves, seleccione Crear.
2. En la pestaña Aspectos básicos, elija una suscripción. En Grupo de recursos,

seleccione Crear nuevo y escriba un nombre para el grupo de recursos.
3. Introduzca un nombre único para el almacén de claves.
4. Seleccione una región y un plan de tarifa.

5. Habilite la protección de purgas para el nuevo almacén de claves.
6. En la pestaña Directiva de acceso, seleccione Control de acceso basado en

roles de Azure para Modelo de permisos.
7. Seleccione Revisar y crear y, a continuación, Crear.
Anote el nombre y el identificador URI del almacén de claves. Las aplicaciones que
acceden al almacén de claves deben usar este identificador URI.
Para obtener más información, consulte Inicio rápido: Creación de un almacén de

claves de Azure Key Vault con Azure Portal.
El cliente asigna el rol de Agente criptográfico de Key Vault a

una cuenta de usuario.
Este paso garantiza que pueda crear claves de cifrado.
1. Vaya al almacén de claves y seleccione Control de acceso (IAM) en el panel
izquierdo.
2. En Conceder acceso a este recurso seleccione Agregar asignación de rol.
3. Busque y seleccione Agente criptográfico de Key Vault.
4. En Miembros, seleccione Usuario, grupo o entidad de servicio.
5. Seleccione Miembros y busque su cuenta de usuario.
6. Seleccione Revisar y asignar.
El cliente crea una clave de cifrado
Para crear la clave de cifrado, a la cuenta del usuario se le debe asignar el rol
Agente criptográfico de Key Vault u otro rol que permita la creación de una clave.
1. En la página de propiedades de Key Vault, seleccione Claves.

2. Seleccione Generar o importar.
3. En la pantalla Crear una clave, especifique un nombre para la clave. Deje las
restantes opciones con sus valores predeterminados.
5. Copie el URI de la clave.
El cliente concede a la aplicación del proveedor de servicios

acceso al almacén de claves.
Asigne el rol de RBAC de Azure Usuario del cifrado del servicio de cifrado de Key
Vault a la aplicación registrada del proveedor de servicios para que pueda acceder
al almacén de claves.

izquierdo.
3. Busque y seleccione Usuario del cifrado del servicio de cifrado de Key Vault.
5. Seleccione Miembros y busque el nombre de la aplicación que instaló desde
el proveedor de servicios.
Ahora puede configurar claves administradas por el cliente con el URI y la clave del
almacén de claves.
Creación de una nueva cuenta de
almacenamiento cifrada con una clave de otro
inquilino
Hasta este punto, ha configurado la aplicación multiinquilino en el inquilino del ISV,
también ha instalado la aplicación en el inquilino del cliente y configurado tanto el
almacén de claves como la clave en el inquilino del cliente. A continuación, puede crear
una nueva cuenta de almacenamiento en el inquilino del ISV y configurar las claves
administradas por el cliente con la clave del inquilino del cliente.
versión nueva en el almacén de claves asociado. Para ello, omita la versión de la clave
del identificador URI de la clave. Como alternativa, puede especificar explícitamente la
actualice manualmente. La inclusión de la versión de la clave en el URI de la clave
configura las claves administradas por el cliente para la actualización manual de la
） Importante
una nueva versión de la clave. Al girar una clave en Azure Key Vault, asegúrese de
esperar 24 horas antes de deshabilitar la versión anterior.
Azure Portal
Para configurar las claves administradas por el cliente entre inquilinos para una
cuenta de almacenamiento nueva en Azure Portal:
1. En Azure Portal, vaya a la página Cuentas de almacenamiento en el inquilino

del ISV y seleccione el botón Crear para crear una cuenta.


(CMK).
5. En el campo Clave de cifrado, elija Escribir clave en el almacén de claves y

especifique el URI de la clave. Omita la versión de la clave del URI si quiere
que Azure Storage compruebe automáticamente una nueva versión de la
clave y la actualice.
6. En el campo Identidad asignada por el usuario, busque la identidad

administrada asignada por el usuario que creó anteriormente en el inquilino
del ISV.
7. Expanda la sección Opciones avanzadas y seleccione la aplicación registrada

multiinquilino que creó anteriormente en el inquilino del ISV.
También puede configurar las claves administradas por el cliente con la actualización
manual de las versiones de la clave cuando crea una cuenta de almacenamiento. Para
ello, incluya la versión de la clave al especificar el URI de la clave.
Cambio de la clave
７ Nota

Azure Portal

de cifrado.

por el cliente
Ｕ Precaución

Azure Portal
pasos:


Azure Portal


Consulte también
por el cliente entre inquilinos para una
Artículo • 29/03/2023
cliente para una cuenta de almacenamiento existente. En el escenario entre inquilinos, la
cuenta de almacenamiento reside en un inquilino administrado por un ISV, mientras que
la clave usada para el cifrado de esa cuenta de almacenamiento reside en un almacén
de claves de un inquilino administrado por el cliente.
Para aprender a configurar claves administradas por el cliente para una nueva cuenta de
almacenamiento, consulte Configuración de claves administradas por el cliente entre
inquilinos para una nueva cuenta de almacenamiento.
７ Nota
Información sobre las claves administradas por

el cliente entre inquilinos
Muchos proveedores de servicios que crean ofertas de software como servicio (SaaS) en
Azure quieren ofrecer a sus clientes la opción de administrar sus propias claves de
cifrado. Las claves administradas por el cliente permiten a un proveedor de servicios
cifrar los datos del cliente mediante una clave de cifrado administrada por el cliente del
proveedor de servicios y a la que no puede acceder el proveedor de servicios. En Azure,
el cliente del proveedor de servicios puede usar Azure Key Vault para administrar sus
claves de cifrado en su propio inquilino y suscripción de Azure AD.
Los servicios y recursos de la plataforma Azure que pertenecen al proveedor de servicios

y que residen en el inquilino del proveedor de servicios requieren acceso a la clave del
inquilino del cliente para realizar las operaciones de cifrado y descifrado.
En la imagen siguiente se muestra un cifrado de datos en reposo con identidad

federada en un flujo de trabajo de CMK entre inquilinos que abarca un proveedor de
servicios y su cliente.
En el ejemplo anterior, hay dos inquilinos de Azure AD: el inquilino de un proveedor de

servicios independiente (Tenant1) y el inquilino de un cliente (Tenant2). Tenant1 hospeda
los servicios de la plataforma Azure y Tenant2 hospeda el almacén de claves del cliente.
El proveedor de servicios crea un registro de aplicación multiinquilino en Tenant1. El

proveedor de servicios configura una credencial de identidad federada en esta
aplicación mediante una identidad administrada asignada por el usuario. A
continuación, el nombre y el identificador de la aplicación se comparten con el cliente.
Un usuario con los permisos adecuados instala la aplicación del proveedor de servicios
en el inquilino del cliente (Tenant2). A continuación, un usuario concede a la entidad de
servicio asociada a la aplicación instalada acceso al almacén de claves del cliente. El
cliente también almacena la clave de cifrado, o la clave administrada por el cliente, en el
almacén de claves. El cliente comparte la ubicación de la clave (la dirección URL de la
clave) con el proveedor de servicios.
El proveedor de servicios ahora tiene lo siguiente:

Un id. de aplicación para una aplicación multiinquilino instalada en el inquilino del
cliente, a la que se le ha concedido acceso a la clave administrada por el cliente.
Una identidad administrada configurada como credencial en la aplicación
multiinquilino.
La ubicación de la clave en el almacén de claves del cliente.
Con estos tres parámetros, el proveedor de servicios aprovisiona recursos de Azure en

Tenant1 que se pueden cifrar con la clave administrada por el cliente en Tenant2.
Vamos a dividir la solución de un extremo a otro anterior en tres fases:
1. El proveedor de servicios configura identidades.

2. El cliente concede a la aplicación multiinquilino del proveedor de servicios acceso
a una clave de cifrado en Azure Key Vault.
3. El proveedor de servicios cifra los datos de un recurso de Azure mediante la CMK.
Las operaciones de la fase 1 serán una configuración única para la mayoría de las
aplicaciones del proveedor de servicios. Las operaciones de las fases 2 y 3 se repetirán
para cada cliente.
Fase 1: el proveedor de servicios configura una aplicación

de Azure AD
Paso Descripción Rol mínimo Rol mínimo

en RBAC de en RBAC de
Azure Azure AD
1. Cree un nuevo registro de aplicación de Azure AD None Desarrollador

multiinquilino o comience con un registro de aplicación de
existente. Anote el id. de la aplicación (id. de cliente) del aplicaciones
registro de la aplicación mediante Azure Portal, Microsoft
Graph API, Azure PowerShell o la CLI de Azure.
2. Cree una identidad administrada asignada por el usuario Colaborador Ninguno

(que se usará como credencial de identidad federada). de identidad
Azure Portal / CLI de Azure / Azure PowerShell/ Plantillas administrada
de Azure Resource Manager
3. Configure la identidad administrada asignada por el Ninguno Propietario

usuario como credencial de identidad federada en la de la
aplicación para que pueda suplantar la identidad de la aplicación
aplicación.
Referencia de Graph API / Azure Portal/ CLI de Azure/
Azure PowerShell
Paso Descripción Rol mínimo Rol mínimo
en RBAC de en RBAC de
Azure Azure AD
4. Comparta el nombre y el id. de la aplicación con el cliente None None

para que pueda instalar y autorizar la aplicación.
Consideraciones para proveedores de servicio

No se recomiendan las plantillas de Azure Resource Manager (ARM) para crear
aplicaciones de Azure AD.
Se puede usar la misma aplicación multiinquilino para acceder a las claves en
diversos inquilinos, como Inquilino2, Inquilino3, Inquilino4, etc. En cada inquilino,
se crea una instancia independiente de la aplicación que tiene el mismo id. de
aplicación, pero un id. de objeto diferente. Por lo tanto, cada instancia de esta
aplicación se autoriza de forma independiente. Tenga en cuenta cómo se usa el
objeto de aplicación para esta característica a fin de crear particiones de la
aplicación en todos los clientes.
La aplicación puede tener un máximo de veinte credenciales de identidad
federada, lo que requiere que un proveedor de servicios comparta las
identidades federadas entre sus clientes. Para más información sobre las
consideraciones y restricciones del diseño de identidades federadas, consulte
Configuración de una aplicación para confiar en un proveedor de identidades
externo
En escenarios poco frecuentes, un proveedor de servicios puede usar un único
objeto de aplicación por cada cliente, pero eso implica costes de mantenimiento
considerables para administrar las aplicaciones a gran escala en todos los clientes.
En el inquilino del proveedor de servicios, no es posible automatizar la
comprobación del publicador.
Fase 2: el cliente autoriza el acceso al almacén de claves

privilegios mínimos RBAC de
Azure AD
con
privilegios
mínimos
privilegios mínimos RBAC de
Azure AD
con
privilegios
mínimos
1. Recomendado: envíe al usuario para None Usuarios

iniciar sesión en la aplicación. Si el con
usuario puede iniciar sesión, existe una permisos
entidad de servicio para la aplicación para
en su inquilino. instalar
Use Microsoft Graph, Microsoft aplicaciones
Graph PowerShell, Azure PowerShell o
la CLI de Azure para crear la entidad de
servicio.
Construya una dirección URL de
consentimiento del administrador y
conceda consentimiento para todo el
inquilino para crear la entidad de
servicio mediante el id. de aplicación.
2. Cree una instancia de Azure Key Vault y Se debe asignar a un usuario el Ninguno
una clave usada como clave rol Colaborador de Key Vault
administrada por el cliente. para crear el almacén de claves
Se debe asignar a un usuario el

rol Agente criptográfico de Key
Vault para agregar una clave al
almacén de claves.
3. Conceda a la identidad de la aplicación Para asignar el rol Usuario del Ninguno

consentida acceso al almacén de claves cifrado del servicio de cifrado
de Azure mediante la asignación del rol de Key Vault a la aplicación,
Usuario del cifrado del servicio de debe tener asignado el rol
cifrado de Key Vault. Administrador de acceso de
usuario.
4. Copie la dirección URL del almacén de None None

claves y el nombre de la clave en la
configuración de claves administradas
por el cliente de la oferta de SaaS.
Consideraciones para clientes de proveedores de servicios

En el inquilino del cliente, Tenant2, un administrador puede establecer directivas
para impedir que los usuarios que no sean administradores instalen aplicaciones.
Estas directivas pueden impedir que los usuarios que no sean administradores
creen entidades de servicio. Si se configura una directiva de este tipo, los usuarios
con permisos para crear entidades de servicio deberán participar.
El acceso a Azure Key Vault se puede autorizar mediante directivas de acceso o
RBAC de Azure. Al conceder acceso a un almacén de claves, asegúrese de usar el
mecanismo activo para el almacén de claves.
Un registro de aplicación de Azure AD tiene un id. de aplicación (id. de cliente).
Cuando la aplicación se instala en el inquilino, se crea una entidad de servicio. La
entidad de servicio comparte el mismo id. de aplicación que el registro de la
aplicación, pero genera su propio id. de objeto. Al autorizar a la aplicación a tener
acceso a los recursos, es posible que tenga que usar la entidad de servicio Name o
la propiedad ObjectID .
Fase 3: el proveedor de servicios cifra los datos de un

recurso de Azure mediante la clave administrada por el
cliente
Una vez completada las fases 1 y 2, el proveedor de servicios puede configurar el cifrado
en el recurso de Azure con la clave y el almacén de claves en el inquilino del cliente y el
recurso de Azure en el inquilino del ISV. El proveedor de servicios puede configurar
claves administradas por el cliente entre inquilinos con las herramientas del cliente
compatibles con ese recurso de Azure, con una plantilla de ARM o con la API REST.

cliente entre inquilinos
En esta sección se describe cómo configurar una clave administrada por el cliente (CMK)
entre inquilinos y cifrar los datos de los clientes. Obtendrá información sobre cómo
cifrar los datos de los clientes en un recurso de Tenant1 mediante una CMK almacenada
en un almacén de claves en Tenant2. Puede usar Azure Portal, Azure PowerShell o la CLI
de Azure.
Portal
El proveedor de servicios configura identidades.

El proveedor de servicios realiza los pasos siguientes en el inquilino Tenant1 del
proveedor de servicios.
El proveedor de servicios crea un registro de aplicaciones
multiinquilino
Puede crear un nuevo registro de aplicación de Azure AD multiinquilino o comenzar

con un registro de aplicación multiinquilino existente. Si comienza con un registro
de aplicación existente, anote el id. de aplicación (id. de cliente) de la aplicación.
Para crear un nuevo registro, siga estos pasos:
1. Busque Azure Active Directory en el cuadro de búsqueda. Busque y

seleccione la extensión Azure Active Directory.
2. Seleccione Administrar > Registros de aplicaciones en el panel izquierdo.
3. Seleccione + Nuevo registro.
4. Proporcione el nombre del registro de la aplicación y seleccione Cuenta en

cualquier directorio organizativo (cualquier directorio de Azure AD:
multiinquilino).
5. Seleccione Registrar.
6. Anote el valor de applicationId/ClientId de la aplicación.
El proveedor de servicios crea una identidad administrada

asignada por el usuario.
Cree una identidad administrada asignada por el usuario que se usará como
credencial de identidad federada.
1. Busque Identidades administradas en el cuadro de búsqueda. Busque y
seleccione la extensión Identidades administradas.
2. Seleccione + Create (+ Crear).
3. Proporcione el grupo de recursos, la región y el nombre de la identidad

administrada.
5. Si la implementación se realiza correctamente, anote el valor de resourceId de

Azure de la identidad administrada asignada por el usuario, que está
disponible en Propiedades. Por ejemplo:
/subscriptions/tttttttt-0000-tttt-0000-
tttt0000tttt/resourcegroups/XTCMKDemo/providers/Microsoft.ManagedIdentity/
userAssignedIdentities/ConsotoCMKDemoUA
El proveedor de servicios configura la identidad administrada

asignada por el usuario como una credencial federada en la
aplicación.
Configure una identidad administrada asignada por el usuario como credencial de
identidad federada en la aplicación para que pueda suplantar la identidad de la
aplicación.
1. Vaya a Azure Active Directory > Registros de aplicaciones > su aplicación.

2. Seleccione Certificados y secretos.
3. Seleccione Credenciales federadas.
4. Seleccione + Agregar credencial.
5. En Escenario de credencial federada, seleccione Claves administradas por el

cliente.
6. Haga clic en Seleccionar una identidad administrada. En el panel, seleccione

la suscripción. En Identidad administrada, seleccione Identidad administrada
asignada por el usuario. En el cuadro Seleccionar, busque la identidad
administrada que creó anteriormente y haga clic en Seleccionar en la parte
inferior del panel.

7. En Detalles de la credencial, proporcione un nombre y una descripción
opcional para la credencial y seleccione Agregar.
El proveedor de servicios comparte el id. de aplicación con el

cliente.
Busque el identificador (identificador de cliente) de la aplicación multiinquilino y
compártalo con el cliente.
El cliente concede a la aplicación del proveedor de

servicios acceso a la clave en el almacén de claves.
El cliente realiza los pasos siguientes en el inquilino Tenant2 del cliente. El cliente puede
usar Azure Portal, Azure PowerShell o la CLI de Azure.
El usuario que ejecuta los pasos debe ser un administrador con un rol con privilegios,
como Administrador de aplicaciones, Administrador de aplicaciones en la nube o
Administrador global.
Portal

El cliente instala la aplicación del proveedor de servicios en el
inquilino del cliente
Para instalar la aplicación registrada del proveedor de servicios en el inquilino del

cliente, cree una entidad de servicio con el id. de aplicación de la aplicación
registrada. Puede crear la entidad de servicio de cualquiera de las maneras
siguientes:
Use Microsoft Graph, Microsoft Graph PowerShell, Azure PowerShell o la CLI

de Azure para crear manualmente la entidad de servicio.
Construya una dirección URL de consentimiento del administrador y conceda
consentimiento para todo el inquilino para crear la entidad de servicio. Tendrá
que proporcionar esto con su AppId.
El cliente crea un almacén de claves
Para crear el almacén de claves, a la cuenta del usuario se le debe asignar el rol
Colaborador de Key Vault u otro rol que permita la creación de un almacén de
claves.
1. En el menú de Azure Portal o en la página principal, seleccione + Crear un

recurso. En el cuadro de búsqueda, escriba Almacenes de claves. En la lista de
resultados, seleccione Almacenes de claves. En la página Almacenes de
claves, seleccione Crear.
2. En la pestaña Aspectos básicos, elija una suscripción. En Grupo de recursos,

seleccione Crear nuevo y escriba un nombre para el grupo de recursos.
3. Introduzca un nombre único para el almacén de claves.
4. Seleccione una región y un plan de tarifa.
5. Habilite la protección de purgas para el nuevo almacén de claves.
6. En la pestaña Directiva de acceso, seleccione Control de acceso basado en

roles de Azure para Modelo de permisos.
7. Seleccione Revisar y crear y, a continuación, Crear.


Anote el nombre y el identificador URI del almacén de claves. Las aplicaciones que
acceden al almacén de claves deben usar este identificador URI.
Para obtener más información, consulte Inicio rápido: Creación de un almacén de

claves de Azure Key Vault con Azure Portal.
El cliente asigna el rol de Agente criptográfico de Key Vault a

una cuenta de usuario.
Este paso garantiza que pueda crear claves de cifrado.

izquierdo.
3. Busque y seleccione Agente criptográfico de Key Vault.
5. Seleccione Miembros y busque su cuenta de usuario.
El cliente crea una clave de cifrado
Para crear la clave de cifrado, a la cuenta del usuario se le debe asignar el rol
Agente criptográfico de Key Vault u otro rol que permita la creación de una clave.
1. En la página de propiedades de Key Vault, seleccione Claves.

2. Seleccione Generar o importar.
3. En la pantalla Crear una clave, especifique un nombre para la clave. Deje las
restantes opciones con sus valores predeterminados.
5. Copie el URI de la clave.
El cliente concede a la aplicación del proveedor de servicios

acceso al almacén de claves.
Asigne el rol de RBAC de Azure Usuario del cifrado del servicio de cifrado de Key
Vault a la aplicación registrada del proveedor de servicios para que pueda acceder
al almacén de claves.

izquierdo.
3. Busque y seleccione Usuario del cifrado del servicio de cifrado de Key Vault.
5. Seleccione Miembros y busque el nombre de la aplicación que instaló desde
el proveedor de servicios.
Ahora puede configurar claves administradas por el cliente con el URI y la clave del
almacén de claves.

cliente para una cuenta existente
Hasta este punto, ha configurado la aplicación multiinquilino en el inquilino del ISV,
también ha instalado la aplicación en el inquilino del cliente y configurado tanto el
almacén de claves como la clave en el inquilino del cliente. A continuación, puede
configurar las claves administradas por el cliente en una cuenta de almacenamiento
existente con la clave del inquilino del cliente.
En los ejemplos de este artículo se muestra cómo configurar claves administradas por el
cliente en una cuenta de almacenamiento existente mediante una identidad
administrada asignada por el usuario para autorizar el acceso al almacén de claves.
También puede usar una identidad administrada asignada por el sistema para configurar
claves administradas por el cliente en una cuenta de almacenamiento existente. En
cualquier caso, la identidad administrada debe tener los permisos adecuados para
acceder al almacén de claves. Para obtener más información, consulte Autenticar en
Azure Key Vault.
versión nueva en el almacén de claves asociado. Para ello, omita la versión de la clave
del identificador URI de la clave. Como alternativa, puede especificar explícitamente la
actualice manualmente. La inclusión de la versión de la clave en el URI de la clave
configura las claves administradas por el cliente para la actualización manual de la
） Importante
una nueva versión de la clave. Al girar una clave en Azure Key Vault, asegúrese de
esperar 24 horas antes de deshabilitar la versión anterior.
Azure Portal
Para configurar las claves administradas por el cliente entre inquilinos para una
cuenta de almacenamiento existente en Azure Portal, siga estos pasos:
2. En Seguridad y redes, seleccione Cifrado. De manera predeterminada, la

administración de claves está establecida en Claves administradas de
Microsoft, como se muestra en la siguiente imagen.

3. Seleccione la opción Claves administradas de cliente.
4. Elija la opción Select from Key Vault (Seleccionar desde almacén de claves).
5. Seleccione Escriba el identificador URI de la clave y especifique el URI de la

clave. Omita la versión de la clave del URI si quiere que Azure Storage
compruebe automáticamente una nueva versión de la clave y la actualice.
6. Seleccione la suscripción que contiene el almacén de claves y la clave.
7. En el campo Tipo de identidad, seleccione Asignación del usuario y, a

continuación, especifique la identidad administrada con la credencial de
identidad federada que creó anteriormente.
8. Expanda la sección Opciones avanzadas y seleccione la aplicación registrada

multiinquilino que creó anteriormente en el inquilino del ISV.
Después de especificar la clave del almacén de claves en el inquilino del cliente,

Azure Portal indica que las claves administradas por el cliente están configuradas
con esa clave. También indica que está habilitada la actualización automática de la
versión de la clave y muestra la versión de la clave actualmente en uso para el
cifrado. El portal también muestra el tipo de identidad administrada que se usa
para autorizar el acceso al almacén de claves, el id. de entidad de seguridad de la
identidad administrada y el id. de aplicación de la aplicación multiinquilino.
Cambio de la clave
７ Nota

Azure Portal

de cifrado.
por el cliente
Ｕ Precaución

Azure Portal
pasos:

Azure Portal

Consulte también
Configuración del cifrado con claves
administradas por el cliente
almacenadas en HSM administrado de
Azure Key Vault.
Artículo • 01/06/2023
el modelo de seguridad de hardware (HSM) administrado de Azure Key Vault. Un HSM
administrado de Azure Key Vault es un HSM validado de FIPS 140-2 de nivel 3.
cliente almacenadas en un HSM administrado mediante la CLI de Azure. Para obtener
información sobre cómo configurar el cifrado con las claves administradas por el cliente
almacenadas en un almacén de claves, consulte Configuración del cifrado con claves
administradas por el cliente almacenadas en Azure Key Vault.
７ Nota
Azure Key Vault y HSM administrado de Azure Key Vault admiten las mismas API e
interfaces de administración para la configuración.
Asignación de una identidad a la cuenta de

almacenamiento
En primer lugar, asigne una identidad administrada asignada por el sistema a una
cuenta de almacenamiento. Usará esta identidad administrada para conceder los
permisos de la cuenta de almacenamiento para acceder al HSM administrado. Para
obtener más información sobre las identidades administradas asignadas por el sistema,
consulte ¿Qué son las identidades administradas para los recursos de Azure?
Para asignar una identidad administrada mediante la CLI de Azure, llame al comando az
storage account update. No olvide reemplazar los valores del marcador de posición
entre corchetes con sus propios valores:
Azure CLI
az storage account update \

--name <storage-account> \
--resource-group <resource_group> \
--assign-identity
Asignación de un rol a la cuenta de

almacenamiento para el acceso al HSM
administrado
A continuación, asigne el rol Usuario de cifrado del servicio de criptografía de HSM
administrado a la identidad administrada de la cuenta de almacenamiento para que la
cuenta de almacenamiento tenga permisos para el HSM administrado. Microsoft
recomienda que limite la asignación del roles al nivel de la clave individual con el fin de
conceder la menor cantidad de privilegios posible a la identidad administrada.
Para crear la asignación de roles para la cuenta de almacenamiento, llame a az key vault
role assignment create. No olvide reemplazar los valores del marcador de posición entre
corchetes con sus propios valores.
Azure CLI
storage_account_principal = $(az storage account show \

--resource-group <resource-group> \
--query identity.principalId \
--output tsv)
az keyvault role assignment create \

--hsm-name <hsm-name> \
--role "Managed HSM Crypto Service Encryption User" \
--assignee $storage_account_principal \
--scope /keys/<key-name>
Configuración del cifrado con una clave en el

HSM administrado
Por último, configure el cifrado de Azure Storage con claves administradas por el cliente
para usar una clave almacenada en el HSM administrado. Entre los tipos de clave
admitidos se incluyen las claves RSA-HSM de los tamaños 2048, 3072 y 4096. Para
obtener información sobre cómo crear una clave en un HSM administrado, consulte
Creación de una clave HSM.
Instale la CLI de Azure 2.12.0 o posterior para configurar el cifrado con el fin de usar una
clave administrada por el cliente en un HSM administrado. Para más información,
consulte Instalación de la CLI de Azure.
Para actualizar automáticamente la versión de una clave administrada por el cliente,

omita la versión de la clave al configurar el cifrado con las claves administradas por el
cliente para la cuenta de almacenamiento. Para obtener más información sobre cómo
configurar el cifrado para la rotación automática de claves, consulte Actualización de la
Después, llame a az storage account update para actualizar la configuración de cifrado

de la cuenta de almacenamiento, como se muestra en el ejemplo siguiente. Incluya --
encryption-key-source parameter y establézcalo en Microsoft.Keyvault para habilitar
las claves administradas por el cliente para la cuenta. No olvide reemplazar los valores
del marcador de posición entre corchetes con sus propios valores.
Azure CLI
hsmurl = $(az keyvault show \

--hsm-name <hsm-name> \
--query properties.hsmUri \
--output tsv)
az storage account update \

--encryption-key-name <key> \
--encryption-key-source Microsoft.Keyvault \
--encryption-key-vault $hsmurl
Para actualizar manualmente la versión de una clave administrada por el cliente, incluya
la versión de la clave al configurar el cifrado para la cuenta de almacenamiento:
Azure CLI
az storage account update

--encryption-key-name <key> \
--encryption-key-version $key_version \
--encryption-key-source Microsoft.Keyvault \
--encryption-key-vault $hsmurl
Al actualizar manualmente la versión de la clave, deberá actualizar la configuración de
cifrado de la cuenta de almacenamiento para que use la nueva versión. En primer lugar,
consulte el URI del almacén de claves mediante una llamada a az keyvault show y, para
la versión de la clave, llame a az keyvault key list-versions. Luego, llame a az storage
account update para actualizar la configuración de cifrado de la cuenta de
almacenamiento y así poder usar la nueva versión de la clave, tal como se muestra en el
ejemplo anterior.
Pasos siguientes
Habilitación del cifrado de
infraestructura para el cifrado doble de
datos
Artículo • 06/11/2023
Azure Storage cifra de forma automática todos los datos de una cuenta de
almacenamiento en el nivel de servicio mediante el cifrado AES de 256 bits, uno de los
cifrados de bloques más sólidos que hay disponibles y compatible con FIPS 140-2. Los
clientes que necesiten más seguridad para que sus datos estén seguros también pueden
habilitar el cifrado AES de 256 bits en el nivel de infraestructura de Azure Storage para el
cifrado doble. El cifrado doble de los datos de Azure Storage sirve de protección en caso
de que uno de los algoritmos de cifrado o las claves puedan estar en peligro. En este
escenario, la capa adicional de cifrado también protege los datos.
El cifrado de infraestructura se puede habilitar para toda la cuenta de almacenamiento o

para un ámbito de cifrado dentro de una cuenta. Cuando se habilita el cifrado de
infraestructura para una cuenta de almacenamiento o un ámbito de cifrado, los datos se
cifran dos veces (una vez en el nivel de servicio y otra en el nivel de infraestructura) con
dos algoritmos de cifrado y dos claves diferentes.
El cifrado de nivel de servicio permite usar claves administradas por Microsoft o claves
administradas por el cliente con Azure Key Vault o el modelo de seguridad de hardware
(HSM) administrado de Key Vault. El cifrado en el nivel de infraestructura se basa en las
claves administradas por Microsoft y siempre usa una clave independiente. Para más
información sobre la administración de claves con el cifrado de Azure Storage, consulte
la sección Información sobre la administración de claves de cifrado.
Para cifrar dos veces los datos, primero debe crear una cuenta de almacenamiento o un
ámbito de cifrado que estén configurados para el cifrado de infraestructura. En este
artículo se describe cómo habilitar el cifrado de infraestructura.
） Importante
El cifrado de infraestructura se recomienda en escenarios en los que es necesario

cifrar los datos doblemente debido a los requisitos de cumplimiento. En la mayoría
de los demás escenarios, el cifrado de Azure Storage proporciona un algoritmo de
cifrado lo suficientemente eficaz y es poco probable que presente alguna ventaja
con respecto al uso del cifrado de infraestructura.
Creación de una cuenta con el cifrado de
infraestructura habilitado
Para habilitar el cifrado de infraestructura para una cuenta de almacenamiento, debe
configurar la cuenta de almacenamiento para que use el cifrado de infraestructura en el
momento de crear la cuenta. Una vez que la cuenta se ha creado, no se puede habilitar
o deshabilitar el cifrado de infraestructura. La cuenta de almacenamiento debe ser de
tipo blob en bloques prémium o de uso general v2.
Azure Portal
Para usar Azure Portal con el fin de crear una cuenta de almacenamiento con el
cifrado de infraestructura habilitado, siga estos pasos:
1. En Azure Portal, vaya a la página Cuentas de almacenamiento.
2. Elija el botón Agregar para agregar una cuenta de almacenamiento de blob

en bloques prémium o de uso general v2.
3. En la pestaña Cifrar, busque Habilitar cifrado de infraestructura y seleccione

Habilitado.
4. Seleccione Revisar y crear para terminar de crear la cuenta de

almacenamiento.
Para comprobar que el cifrado de infraestructura está habilitado para una cuenta de
almacenamiento con Azure Portal, siga estos pasos:
2. En Seguridad y redes, elija Cifrado.
Azure Policy proporciona una directiva integrada para requerir que el cifrado de
infraestructura esté habilitado para una cuenta de almacenamiento. Para obtener más
información, consulte la sección Almacenamiento de las definiciones de directivas
integradas de Azure Policy.
Creación de un ámbito de cifrado con el cifrado

de infraestructura habilitado
Si el cifrado de infraestructura está habilitado para una cuenta, cualquier ámbito de
cifrado creado en esa cuenta usa automáticamente el cifrado de infraestructura. Si el
cifrado de infraestructura no está habilitado en el nivel de cuenta, tiene la opción de
habilitarlo para un ámbito de cifrado en el momento de crear el ámbito. La
configuración de cifrado de infraestructura para un ámbito de cifrado no se puede
cambiar después de crear el ámbito. Para más información, consulte Creación de un
ámbito de cifrado.
Pasos siguientes
Ámbitos de cifrado para Blob Storage
Habilitación y configuración de
Microsoft Defender para Storage
Artículo • 25/05/2023
Microsoft Defender para Storage es una solución nativa de Azure que ofrece una capa
avanzada de inteligencia para la detección y mitigación de amenazas en cuentas de
almacenamiento, con tecnología de Inteligencia sobre amenazas de Microsoft,
tecnologías antimalware de Microsoft Defender y detección de datos confidenciales.
Con la protección de Azure Blob Storage, Azure Files y servicios de Azure Data
Lake Storage, proporciona un conjunto de alertas completo, detección de malware casi
en tiempo real (complemento) y detección de amenazas de datos confidenciales (sin
costo adicional), lo que permite la detección rápida, la evaluación de prioridades y la
respuesta a posibles amenazas de seguridad con información contextual.
Con Microsoft Defender para Storage, las organizaciones pueden personalizar su

protección y aplicar directivas de seguridad coherentes al habilitarlo en suscripciones y
cuentas de almacenamiento con control y flexibilidad granulares.
Obtenga más información sobre las funcionalidades y las amenazas y alertas de

seguridad de Microsoft Defender para Storage.
 Sugerencia
Si actualmente usa Microsoft Defender para Storage clásico, considere la

posibilidad de actualizar al nuevo plan, que ofrece varias ventajas sobre el plan
clásico. Obtenga más información sobre la migración a un nuevo plan.
Disponibilidad
Aspecto Detalles
Estado de la Disponibilidad general (GA)

versión:
Disponibilidad - Supervisión de actividades (alertas de seguridad): disponibilidad general (GA)

de - Detección de malware: versión preliminar
características: - Detección de amenazas de datos confidenciales (detección de datos
confidenciales): versión preliminar
Aspecto Detalles
Precios: - Defender para Storage: 10 USD/cuentas de almacenamiento/mes*

- Detección de malware (complemento): gratis durante la versión preliminar
pública**
Los precios anteriores se aplican a las nubes comerciales. Para obtener más
información, visite la página de precios .
* Las cuentas de almacenamiento que superen los 73 millones de

transacciones mensuales se cobrarán a 0,1492 USD por cada 1 millón de
transacciones que superen el umbral.
** En el futuro, la detección de malware tendrá un precio de 0,15 USD/GB de
datos ingeridos. La facturación de la detección de malware no está habilitada
durante la versión preliminar pública y se dará aviso por anticipado antes de
que se inicie la facturación.
Tipos de Blob Storage (Estándar/Premium StorageV2, incluido Data Lake Gen2):

almacenamiento supervisión de actividades, detección de malware, detección de datos
compatibles: confidenciales
Azure Files (a través de la API de REST y SMB): supervisión de actividades
Roles y Para la detección de malware y la detección de amenazas de datos

permisos confidenciales en los niveles de suscripción y cuenta de almacenamiento,
necesarios: necesita roles de propietario (propietario de la suscripción o propietario de la
cuenta de almacenamiento) o roles específicos con las acciones de datos
correspondientes. Para habilitar la supervisión de actividad, necesita permisos
de "Administración de seguridad". Obtenga más información sobre los
permisos necesarios.
Nubes: Nubes comerciales*

Azure Government (solo para la supervisión de actividad)
Azure China 21Vianet
Cuentas de AWS conectadas
* La zona de Azure DNS no se admite para la detección de malware y la detección de

amenazas de datos confidenciales.
Requisitos previos para la detección de

malware
Permisos
Para habilitar y configurar la detección de malware, debe tener roles de propietario
(como propietario de la suscripción o propietario de la cuenta de almacenamiento) o
roles específicos con las acciones de datos necesarias. Obtenga más información sobre
los permisos necesarios.
Proveedor de recursos de Event Grid

El proveedor de recursos de Event Grid debe estar registrado para poder crear el tema
del sistema de Event Grid que se usa para detectar desencadenadores de carga. Siga
estos pasos para comprobar que Event Grid está registrado en la suscripción.
Debe tener permiso para realizar la operación /register/action para el proveedor de

recursos. Este permiso se incluye en los roles Colaborador y Propietario.
Configurar Microsoft Defender para Storage

Para habilitar y configurar Microsoft Defender para Storage con el fin de garantizar la
máxima protección y optimización de costes, están disponibles las siguientes opciones
de configuración:
Habilite o deshabilite Microsoft Defender para Storage.
Habilite o deshabilite las características configurables de detección de amenazas

de datos confidenciales o detección de amenazas.
Establezca un límite mensual en la detección de malware por cuenta de

almacenamiento para controlar los costes (el valor predeterminado es de 5000 GB
por cuenta de almacenamiento al mes).
Configure métodos adicionales para guardar los resultados y el registro de la
detección de malware.
 Sugerencia
Las características de detección de malware tienen configuraciones

avanzadas para ayudar a los equipos de seguridad a admitir diferentes flujos
de trabajo y requisitos.
Invalide la configuración de nivel de suscripción para configurar cuentas de

almacenamiento específicas con configuraciones personalizadas que difieren de las
opciones configuradas en el nivel de suscripción.
Puede habilitar y configurar Microsoft Defender para Storage desde Azure Portal,
directivas de Azure integradas, mediante programación mediante plantillas de IaC (Bicep
y ARM) o directamente con la API de REST.
７ Nota
Para evitar la migración al plan clásico heredado, asegúrese de deshabilitar las

directivas antiguas de Defender para Storage. Busque y deshabilite las directivas
denominadas Configurar Azure Defender para Storage para habilitarlo,
Azure Defender para Storage debe estar habilitado o Configurar
Microsoft Defender para Storage para que esté habilitado (plan por cuenta de
almacenamiento).
Habilitar en una suscripción
Se recomienda habilitar Defender para Storage en el nivel de suscripción. De este

modo, se garantiza que todas las cuentas de almacenamiento de la suscripción se
protegerán, incluidas las cuentas futuras.
Hay varias maneras de habilitar Defender para Storage en las suscripciones:
Azure Portal
Directiva integrada de Azure
Plantillas de IaC, incluidas Bicep y ARM
REST API
 Sugerencia
Puede invalidar o establecer opciones de configuración personalizadas para
cuentas de almacenamiento específicas dentro de suscripciones protegidas.
Azure Portal
Para habilitar Defender para Storage en el nivel de suscripción con Azure Portal:
2. Vaya a Microsoft Defender for CloudConfiguración del entorno.
3. Seleccione la suscripción para la que quiere habilitar Defender para Storage.
4. En la página Planes de Defender, busque Almacenamiento en la lista y

seleccione Activado y Guardar.
Si actualmente tiene Defender para Storage habilitado con precios por

transacción, seleccione el vínculo Nuevo plan de precios disponible y
confirme el cambio de precios.

Microsoft Defender para Storage ahora está habilitado para esta suscripción y está
totalmente protegido, incluida la detección de malware al cargar y la detección de
amenazas de datos confidenciales.
Si desea desactivar la Detección de malware al cargar o la Detección de amenazas

de datos confidenciales, puede seleccionar Configuración y cambiar el estado de la
característica pertinente a Desactivado.
Si desea cambiar el límite de tamaño de detección de malware por cuenta de

almacenamiento al mes para malware, cambie la configuración en Editar
configuración.
Si desea deshabilitar el plan, cambie el botón de estado a Desactivado para el plan

de almacenamiento en la página Planes de Defender.
Habilitación y configuración a gran escala con una
directiva integrada de Azure
Para habilitar y configurar Defender para Storage a gran escala con una directiva
integrada de Azure para asegurarse de que se aplican directivas de seguridad
coherentes en todas las cuentas de almacenamiento existentes y nuevas dentro de
las suscripciones, siga estos pasos:
1. Inicie sesión en Azure Portal y vaya al panel Directiva.

2. En el panel Directiva, seleccione Definiciones en el menú de la izquierda.
3. En la categoría "Security Center", busque y, a continuación, seleccione la
opción Configurar Microsoft Defender para Storage para que esté
habilitado. Esta directiva habilitará todas las funcionalidades de Defender para
Storage: supervisión de actividad, detección de malware y detección de
amenazas de datos confidenciales. También puede obtenerla aquí: Lista de
definiciones de directivas integradas. Si desea habilitar una directiva sin las
características configurables, use Configurar Microsoft Defender para
Storage básico para que esté habilitado (solo supervisión de actividad).
4. Elija la directiva y revísela.
5. Seleccione Asignar y edite los detalles de la directiva. Puede ajustar, editar y
agregar reglas personalizadas a la directiva.
6. Una vez que haya completado la revisión, seleccione Revisar y crear.
7. Seleccione Crear para asignar la directiva.
Habilitación y configuración con plantillas de IaC
Plantilla de Bicep
Para habilitar y configurar Microsoft Defender para Storage en el nivel de
suscripción mediante Bicep, asegúrese de que el ámbito de destino esté
establecido en subscription y agregue lo siguiente a la plantilla de Bicep:
Bicep
resource StorageAccounts 'Microsoft.Security/pricings@2023-01-01' = {

name: 'StorageAccounts'
properties: {
pricingTier: 'Standard'
subPlan: 'DefenderForStorageV2'
extensions: [
{
name: 'OnUploadMalwareScanning'
isEnabled: 'True'
additionalExtensionProperties: {
CapGBPerMonthPerStorageAccount: '5000'
}
}
{
name: 'SensitiveDataDiscovery'
isEnabled: 'True'
}
]
}
}
Para modificar el límite mensual para la detección de malware por cuenta de

almacenamiento, basta con ajustar el parámetro CapGBPerMonthPerStorageAccount a
su valor preferido. Este parámetro establece un límite en los datos máximos que se
pueden examinar para malware cada mes por cuenta de almacenamiento. Si desea
permitir una detección ilimitada, asigne el valor -1 . El límite predeterminado se
establece en 5000 GB.
Si desea desactivar las características de Detección de malware al cargar o

Detección de amenazas de datos confidenciales, puede cambiar el valor isEnabled
a False en Detección de datos confidenciales.
Para deshabilitar el plan completo de Defender para Storage, establezca el valor de

propiedad pricingTier en Free y quite las propiedades subPlan y extensions .
Obtenga más información sobre la referencia de AzAPI de la plantilla de Bicep.
Plantilla ARM
suscripción mediante una plantilla de ARM, agregue este fragmento de código
JSON a la sección de recursos de la plantilla de ARM:
JSON
{
"type": "Microsoft.Security/pricings",
"apiVersion": "2023-01-01",
"name": "StorageAccounts",
"properties": {
"pricingTier": "Standard",
"subPlan": "DefenderForStorageV2",
"extensions": [
{
"name": "OnUploadMalwareScanning",
"isEnabled": "True",
"additionalExtensionProperties": {
"CapGBPerMonthPerStorageAccount": "5000"
}
},
{
"name": "SensitiveDataDiscovery",
"isEnabled": "True"
}
]
}
}
Para modificar el umbral mensual para la detección de malware en las cuentas de

pueden examinar para malware cada mes, por cuenta de almacenamiento. Si desea

Para deshabilitar el plan completo de Defender, establezca el valor de propiedad

pricingTier en Free y quite las propiedades subPlan y extensions .
Obtén más información en la referencia de plantillas de ARM.
Habilitación y configuración con la API de REST

suscripción mediante la API de REST, cree una solicitud PUT con este punto de
conexión (reemplace subscriptionId en la URL del punto de conexión con su
propio id. de suscripción de Azure):
HTTP
PUT
https://management.azure.com/subscriptions/{subscriptionId}/providers/Mi
crosoft.Security/pricings/StorageAccounts?api-version=2023-01-01
Agregue el siguiente cuerpo de solicitud:
JSON
{
"properties": {
"extensions": [
{
"name": "OnUploadMalwareScanning",
"isEnabled": "True",
"additionalExtensionProperties": {
"CapGBPerMonthPerStorageAccount": "5000"
}
},
{
"name": "SensitiveDataDiscovery",
"isEnabled": "True"
}
],
"subPlan": "DefenderForStorageV2",
"pricingTier": "Standard"
}
}
Para modificar el umbral mensual para la detección de malware en las cuentas de

pueden examinar para malware cada mes, por cuenta de almacenamiento. Si desea

Para deshabilitar el plan completo de Defender, establezca el valor de propiedad

pricingTier en Free y quite las propiedades subPlan y extensions .
Obtenga más información sobre la actualización de planes de Defender con la API

de REST en HTTP, Java, Go y JavaScript.
Invalidación de la configuración de nivel de suscripción

de Defender para Storage
La configuración de Defender para Storage en cada cuenta de almacenamiento es
heredada por la configuración de nivel de suscripción. Use la opción Invalidar la
configuración de nivel de suscripción de Defender para Storage para configurar las
opciones que difieren de las opciones configuradas en el nivel de suscripción.
La configuración de invalidación se usa normalmente para los escenarios siguientes:
1. Habilitar la detección de malware o las características de detección de amenazas

de confidencialidad de datos.
2. Configurar las opciones personalizadas para la detección de malware.
3. Deshabilitar Microsoft Defender para Storage en cuentas de almacenamiento

específicas.
７ Nota
Se recomienda habilitar Defender para Storage en toda la suscripción para proteger

todas las cuentas de almacenamiento existentes y futuras. Sin embargo, hay
algunos casos en los que querrá excluir cuentas de almacenamiento específicas de
la protección de Defender. Si ha decidido excluir alguna cuenta, siga los pasos que
se indican a continuación para usar la configuración de invalidación y, a
continuación, deshabilite la cuenta de almacenamiento correspondiente.
Si usa Defender para Storage (clásico), también puede excluir cuentas de

almacenamiento.
Azure Portal
Para invalidar la configuración de nivel de suscripción de Defender para Storage para
configurar las opciones que difieren de las opciones configuradas en el nivel de
suscripción mediante Azure Portal:
1. Inicie sesión en el Portal de Azure
2. Vaya a la cuenta de almacenamiento en la que desea configurar opciones

personalizadas.
3. En el menú de cuenta de almacenamiento, en la sección Seguridad y redes,

seleccione Microsoft Defender for Cloud.
4. Seleccione Configuración en Microsoft Defender para Storage.
5. Establezca el estado de Invalidar la configuración de nivel de suscripción de

Defender para Storage (en Configuración avanzada) en Activado. Esto garantiza
que la configuración solo se guarde para esta cuenta de almacenamiento y que la
configuración de la suscripción no la sobrescriba.
6. Configure las opciones que desea cambiar:

a. Para habilitar la detección de malware o la detección de amenazas de datos
confidenciales, establezca el estado en Activado.
b. Para modificar la configuración de la detección de malware:
i. Cambie la opción "Detección de malware al cargar" a Activado si aún no

está habilitada.
ii. A fin de ajustar el umbral mensual para examinar malware en las cuentas de
almacenamiento, se puede modificar el parámetro denominado «Establecer
el límite de GB examinados al mes» con el valor deseado. Este parámetro
determina la cantidad máxima de datos que se pueden examinar
mensualmente en la búsqueda de malware, específicamente para cada
cuenta de almacenamiento. Si desea permitir exámenes ilimitados, puede
desactivar este parámetro. De manera predeterminada el límite se establece
en 5,000 GB.
Obtenga más información sobre la configuración de la detección de malware.
7. Para deshabilitar Defender para Storage en estas cuentas de almacenamiento,

establezca el estado de Microsoft Defender para Storage en Desactivado.
API DE REST
Para invalidar la configuración de nivel de suscripción de Defender para Storage para
configurar las opciones que difieren de las opciones configuradas en el nivel de
suscripción mediante la API de REST:
1. Cree una solicitud PUT con este punto de conexión. Reemplace subscriptionId ,
resourceGroupName y accountName en la dirección URL del punto de conexión con
su propio id. de suscripción de Azure, el grupo de recursos y los nombres de la

cuenta de almacenamiento según corresponda.
URL de la solicitud:
HTTP
PUT
https://management.azure.com/subscriptions/{subscriptionId}/resourceGro
ups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{ac
countName}/providers/Microsoft.Security/DefenderForStorageSettings/curr
ent?api-version=2022-12-01-preview
Cuerpo de la solicitud:
JSON
{
"properties": {
"isEnabled": true,
"malwareScanning": {
"onUpload": {
"isEnabled": true,
"capGBPerMonth": 5000
}
},
"sensitiveDataDiscovery": {
"isEnabled": true
},
"overrideSubscriptionLevelSettings": true
}
}
a. Para habilitar la detección de malware o la detección de amenazas de datos

confidenciales, establezca el valor de isEnabled en true en las características
pertinentes.
b. Para modificar la configuración de detección de malware, edite los campos

pertinentes en "onUpload", asegúrese de que el valor de isEnabled es true. Si
desea permitir una detección ilimitada, asigne el valor -1 al parámetro
capGBPerMonth.
Obtenga más información sobre la configuración de detección de malware.

c. Para deshabilitar Defender para Storage en estas cuentas de almacenamiento,
use el siguiente cuerpo de solicitud:
JSON
{
"properties": {
"isEnabled": false,
"overrideSubscriptionLevelSettings": true
}
}
2. Asegúrese de agregar el parámetro overrideSubscriptionLevelSettings y de que

su valor esté establecido en true . Esto garantiza que la configuración solo se
guarde para esta cuenta de almacenamiento y que la configuración de la
suscripción no la sobrescriba.
Configuración de redes virtuales y
firewalls de Azure Storage
Artículo • 20/10/2023
Azure Storage proporciona un modelo de seguridad por capas. Este modelo le permite
controlar el nivel de acceso a las cuentas de almacenamiento que exigen sus
aplicaciones y entornos empresariales, en función del tipo y el subconjunto de redes o
recursos que usa.
Cuando configura las reglas de red, solo las aplicaciones que solicitan datos en el
conjunto especificado de redes o a través del conjunto especificado de recursos de
Azure pueden acceder a una cuenta de almacenamiento. Puede limitar el acceso a su
cuenta de almacenamiento a las solicitudes procedentes de direcciones IP especificadas,
intervalos IP, subredes en una red virtual de Azure o instancias de recursos de algunos
servicios de Azure.
Las cuentas de almacenamiento tienen un punto de conexión público accesible a través

de Internet. También puede crear puntos de conexión privados para la cuenta de
almacenamiento. La creación de puntos de conexión privados asigna una dirección IP
privada desde la red virtual a la cuenta de almacenamiento. Esto ayuda a proteger el
tráfico entre la red virtual y la cuenta de almacenamiento a través de un vínculo privado.
El firewall de Azure Storage proporciona control de acceso para el punto de conexión

público de la cuenta de almacenamiento. También puede usar el firewall para bloquear
todo el acceso a través del punto de conexión público al usar puntos de conexión
privados. La configuración del firewall también permite que los servicios de la
plataforma de Azure de confianza accedan a la cuenta de almacenamiento.
Una aplicación que accede a una cuenta de almacenamiento cuando las reglas de red
están en vigor aún requiere la autorización adecuada para la solicitud. La autorización es
compatible con las credenciales de Microsoft Entra para blobs y colas, con una clave de
acceso de cuenta válida o un token de firma de acceso compartido (SAS). Cuando
configura un contenedor de blob para el acceso anónimo, no es necesario autorizar las
solicitudes para leer datos en ese contenedor. Las regla de firewall seguirán vigentes y
bloquearán el tráfico anónimo.
La activación de las reglas de firewall para la cuenta de almacenamiento bloquea las

solicitudes entrantes para los datos de forma predeterminada, a menos que las
solicitudes procedan de un servicio que funcione en una instancia de red virtual de
Azure o desde direcciones IP públicas permitidas. Las solicitudes que bloquean incluyen
aquellas de otros servicios de Azure, desde Azure Portal, y desde los servicios de registro
y métricas.
Puede conceder acceso a los servicios de Azure que funcionan desde una red virtual al
permitir el tráfico de la subred que hospeda la instancia de servicio. También puede
habilitar un número limitado de escenarios a través del mecanismo de excepciones que
describe este artículo. Para acceder a los datos de la cuenta de almacenamiento
mediante Azure Portal, deberá estar en una máquina situada dentro del límite de
confianza (IP o red virtual) que haya configurado.
７ Nota

Escenarios
Para proteger la cuenta de almacenamiento, primero debe configurar una regla para
denegar el acceso al tráfico desde todas las redes (incluido el tráfico de Internet) en el
punto de conexión público de forma predeterminada. A continuación, debe configurar
las reglas que conceden acceso al tráfico desde redes virtuales específicas. También
puede configurar reglas para conceder acceso al tráfico desde intervalos de direcciones
IP de Internet públicos seleccionados, lo que permite habilitar conexiones desde clientes
locales o específicos de Internet. Esta configuración le ayuda a crear un límite de red
seguro para las aplicaciones.
Puede combinar reglas de firewall que permitan el acceso desde redes virtuales
específicas y desde intervalos de direcciones IP públicas en la misma cuenta de
almacenamiento. Puede aplicar reglas de firewall de almacenamiento a cuentas de
almacenamiento existente o crear nuevas cuentas de almacenamiento.
Las reglas de firewall de almacenamiento se aplican al punto de conexión público de

una cuenta de almacenamiento. No se necesitan reglas de acceso de firewall para
permitir el tráfico de los puntos de conexión privados de una cuenta de
almacenamiento. El proceso de aprobación de la creación de un punto de conexión
privado concede acceso implícito al tráfico desde la subred que hospeda el punto de
conexión privado.
） Importante
Las reglas de firewall de Azure Storage solo se aplican a las operaciones del plano
de datos. Las operaciones del plano de control no están sujetas a las restricciones
especificadas en las reglas de firewall.
Algunas operaciones, como las operaciones de contenedor de blobs, se pueden

realizar a través del plano de control y del plano de datos. Por lo tanto, si intenta
realizar una operación como enumerar contenedores de Azure Portal, la operación
se realizará correctamente a menos que otro mecanismo la bloquee. Los intentos
de acceder a los datos de blob desde una aplicación como Explorador de
Azure Storage se controlan mediante las restricciones de firewall.
Para obtener una lista de las operaciones del plano de datos, consulte la Referencia
de la API de REST de Azure Storage. Para obtener una lista de las operaciones del
plano de control, consulte la Referencia de la API de REST del proveedor de
recursos de Azure Storage.
Configuración del acceso de red a

Azure Storage
Puede controlar el acceso a los datos de la cuenta de almacenamiento a través de
puntos de conexión de red, o a través de servicios o recursos de confianza en cualquier
combinación, entre las que se incluyen:
Permitir el acceso desde subredes de red virtual seleccionadas mediante puntos de

conexión privados.
Permitir el acceso desde subredes de red virtual seleccionadas mediante puntos de
conexión de servicio.
Permitir el acceso desde intervalos o direcciones IP públicas específicas.
Permitir el acceso desde instancias de recursos de Azure seleccionadas.
Permitir el acceso desde servicios de Azure de confianza (mediante la opción
Administrar excepciones).
Configurar excepciones para los servicios de registro y métricas.
Acerca de los puntos de conexión de red virtual

Hay dos tipos de puntos de conexión de red virtual para las cuentas de
almacenamiento:
Puntos de conexión de servicio de red virtual
Puntos de conexión privados
Los puntos de conexión de servicio de red virtual son públicos y accesibles a través de
Internet. El firewall de Azure Storage proporciona la capacidad de controlar el acceso a
la cuenta de almacenamiento a través de estos puntos de conexión públicos. Al habilitar
el acceso de red pública a la cuenta de almacenamiento, todas las solicitudes entrantes
de datos se bloquean de manera predeterminada. Solo las aplicaciones que solicitan
datos de orígenes permitidos que configure en la configuración del firewall de la cuenta
de almacenamiento podrán acceder a los datos. Los orígenes pueden incluir la dirección
IP de origen o la subred de red virtual de un cliente, o una instancia de servicio o
recurso de Azure a través de la cual los clientes o servicios acceden a los datos. Las
solicitudes bloqueadas incluyen las de otros servicios de Azure, de Azure Portal, y de los
servicios de registro y métricas, a menos que permita explícitamente el acceso en la
configuración del firewall.
Un punto de conexión privado usa una dirección IP privada de la red virtual para
acceder a una cuenta de almacenamiento a través de la red troncal de Microsoft. Con un
punto de conexión privado, el tráfico entre la red virtual y la cuenta de almacenamiento
se protegen a través de un vínculo privado. Las reglas de firewall de almacenamiento
solo se aplican a los puntos de conexión públicos de una cuenta de almacenamiento, no
a los puntos de conexión privados. El proceso de aprobación de la creación de un punto
de conexión privado concede acceso implícito al tráfico desde la subred que hospeda el
punto de conexión privado. Puede usar Directivas de red para controlar el tráfico a
través de puntos de conexión privados si desea refinar las reglas de acceso. Si quiere
usar puntos de conexión privados exclusivamente, puede usar el firewall para bloquear
todo el acceso a través del punto de conexión público.
Para ayudarle a decidir cuándo usar cada tipo de punto de conexión en su entorno,
consulte Comparación de puntos de conexión privados y puntos de conexión de
servicio.
Cómo abordar la seguridad de red para la cuenta de

almacenamiento
Para proteger la cuenta de almacenamiento y crear un límite de red seguro para las
aplicaciones:
1. Para empezar, deshabilite todo el acceso a la red pública para la cuenta de

almacenamiento en la opción Acceso a la red pública en el firewall de la cuenta de
almacenamiento.
2. Siempre que sea posible, configure vínculos privados a la cuenta de
almacenamiento desde puntos de conexión privados en subredes de red virtual
donde residen los clientes que requieren acceso a los datos.
3. Si las aplicaciones cliente requieren acceso a través de los puntos de conexión

públicos, cambie la opción Acceso de red pública a Habilitado desde redes
virtuales seleccionadas y direcciones IP. A continuación, según sea necesario:
a. Especifique las subredes de red virtual desde las que desea permitir el acceso.
b. Especifique los intervalos de direcciones IP públicas desde los que desea
permitir el acceso, como los de redes locales.
c. Permita el acceso desde instancias de recursos de Azure seleccionadas.
d. Agregue excepciones para permitir el acceso desde servicios de confianza
necesarios para operaciones como la copia de seguridad de datos.
e. Agregue excepciones para el registro y las métricas.
Después de aplicar reglas de red, se aplican para todas las solicitudes. Los tokens de
SAS que conceden acceso a una dirección IP específica sirven para limitar el acceso del
titular del token, pero no conceden un acceso nuevo más allá de las reglas de red
configuradas.
Restricciones y consideraciones
Antes de implementar la seguridad de red para las cuentas de almacenamiento, revise
las restricciones y consideraciones importantes que se describen en esta sección.
＂ Las reglas de firewall de Azure Storage solo se aplican a las operaciones del plano
de datos. Las operaciones del plano de control no están sujetas a las restricciones
especificadas en las reglas de firewall.
＂ Revise las Restricciones de las reglas de red IP.
＂ Para acceder a los datos mediante herramientas como Azure Portal, Explorador de
Azure Storage y AzCopy, debe estar en un equipo dentro del límite de confianza
que estableció al configurar las reglas de seguridad de red.
＂ Se aplican reglas de red en todos los protocolos de red para Azure Storage,
incluidos REST y SMB.
＂ Las reglas de red no afectan al tráfico de disco de la máquina virtual (VM), incluidas
las operaciones de montaje y desmontaje y E/S de disco, pero ayudan a proteger el
acceso REST a los blobs en páginas.
＂ Puede usar discos no administrados en cuentas de almacenamiento con reglas de
red aplicadas para crear copias de seguridad y restaurar máquinas virtuales
mediante la creación de una excepción. Las excepciones de firewall no son
aplicables a discos administrados, ya que Azure ya los administra.
＂ Las cuentas de almacenamiento clásicas no admiten firewalls y redes virtuales.
＂ Si elimina una subred que se ha incluido en una regla de red virtual, se quitará de
las reglas de red de la cuenta de almacenamiento. Si crea una subred con el mismo
nombre, no tendrá acceso a la cuenta de almacenamiento. Para permitir el acceso,
deberá autorizar la nueva subred explícitamente en las reglas de red de la cuenta
de almacenamiento.
＂ Al hacer referencia a un punto de conexión de servicio en una aplicación cliente, se
recomienda evitar la dependencia de una dirección IP almacenada en caché. La
dirección IP de la cuenta de almacenamiento está sujeta a cambios y, por su parte,
confiar en una dirección IP almacenada en caché podría dar lugar a
comportamientos inesperados. Además, se recomienda respetar el período de vida
(TTL) del registro DNS y evitar reemplazarlo. La invalidación del TTL de DNS podría
dar lugar a comportamientos inesperados.
＂ Por diseño, el acceso a una cuenta de almacenamiento desde servicios de confianza
tiene la prioridad más alta, por encima de otras restricciones de acceso a la red. Si
establece Acceso de red pública en Deshabilitado después de haberlo establecido
en Habilitado desde redes virtuales y direcciones IP seleccionadas, las instancias
de recursos y excepciones que había configurado antes, incluida la opción Permitir
que los servicios de Azure de la lista de servicios de confianza accedan a esta
cuenta de almacenamiento, permanecerán en vigor. Como resultado, esos recursos
y servicios podrían seguir teniendo acceso a la cuenta de almacenamiento.
Autorización
Los clientes a los que se concedió acceso a través de reglas de red deben seguir
cumpliendo los requisitos de autorización de la cuenta de almacenamiento para acceder
a los datos. La autorización es compatible con las credenciales de Microsoft Entra para
blobs y colas, con una clave de acceso de cuenta válida o un token de firma de acceso
compartido (SAS).
Cuando configura un contenedor de blobs para el acceso público anónimo, las

solicitudes para leer datos de ese contenedor no tienen que estar autorizadas, pero las
reglas de firewall permanecen en vigor y bloquearán el tráfico anónimo.
Modificación de la regla de acceso de red

predeterminada
De forma predeterminada, las cuentas de almacenamiento aceptan conexiones de
clientes en cualquier red. Puede limitar el acceso a las redes seleccionadas o impedir el
tráfico de todas las redes y permitir el acceso solo a través de un punto de conexión
privado.
Debe establecer la regla predeterminada en denegar o las reglas de red no tendrán

ningún efecto. Sin embargo, cambiar esta configuración puede afectar a la capacidad de
la aplicación de conectarse a Azure Storage. Asegúrese de conceder acceso a las redes
permitidas o configurar el acceso a través de un punto de conexión privado antes de
cambiar esta configuración.
７ Nota

Portal
1. Vaya a la cuenta de almacenamiento que quiere proteger.
2. Busque la configuración Redes en Seguridad y redes.
3. Elija el tipo de acceso a la red pública que quiere permitir:
Para permitir el tráfico de todas las redes, seleccione Habilitado desde

todas las redes.
Para permitir el tráfico solo de redes virtuales específicas, seleccione

Habilitado desde redes virtuales y direcciones IP seleccionadas.
Para bloquear el tráfico de todas las redes, seleccione Deshabilitado.
4. Seleccione Guardar para aplicar los cambios.
Ｕ Precaución
Por diseño, el acceso a una cuenta de almacenamiento desde servicios de confianza

tiene la prioridad más alta, por encima de otras restricciones de acceso a la red. Si
establece Acceso de red pública en Deshabilitado después de haberlo establecido
en Habilitado desde redes virtuales y direcciones IP seleccionadas, las instancias
de recursos y excepciones que había configurado antes, incluida la opción Permitir
que los servicios de Azure de la lista de servicios de confianza accedan a esta
cuenta de almacenamiento, permanecerán en vigor. Como resultado, esos
recursos y servicios podrían seguir teniendo acceso a la cuenta de almacenamiento.
Concesión de acceso desde una red virtual

Puede configurar las cuentas de almacenamiento para permitir el acceso solo desde
subredes específicas. Las subredes permitidas pueden pertenecer a una red virtual de la
misma suscripción o una suscripción diferente, incluidas las que pertenecen a un
inquilino de Microsoft Entra diferente. Con los puntos de conexión de servicio entre
regiones, las subredes permitidas también pueden estar en regiones diferentes de la
Debe habilitar un punto de conexión de servicio para Azure Storage dentro de la red
virtual. El punto de conexión de servicio enruta el tráfico desde la red virtual hasta el
servicio Azure Storage mediante una ruta de acceso óptima. Las identidades de la red
virtual y la subred también se transmiten con cada solicitud. Después, los
administradores pueden configurar reglas de red para la cuenta de almacenamiento que
permitan recibir solicitudes desde subredes específicas en una red virtual. Los clientes a
los que se concedió acceso a través de estas reglas de red deben seguir cumpliendo los
requisitos de autorización de la cuenta de almacenamiento para acceder a los datos.
Cada cuenta de almacenamiento admite hasta 200 reglas de red virtual. Puede combinar
estas reglas con reglas de red IP.
） Importante
Al hacer referencia a un punto de conexión de servicio en una aplicación cliente, se

recomienda evitar la dependencia de una dirección IP almacenada en caché. La
dirección IP de la cuenta de almacenamiento está sujeta a cambios y, por su parte,
confiar en una dirección IP almacenada en caché podría dar lugar a
comportamientos inesperados.
Además, se recomienda respetar el período de vida (TTL) del registro DNS y evitar
reemplazarlo. La invalidación del TTL de DNS podría dar lugar a comportamientos
inesperados.
Permisos necesarios
Para aplicar una regla de red virtual a una cuenta de almacenamiento, el usuario debe
tener permisos apropiados para las subredes que se van a agregar. Un Colaborador de
la cuenta de almacenamiento o un usuario al que se haya concedido permiso para la
Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action operación
del proveedor de recursos de Azure puede aplicar una regla a través de un rol
personalizado de Azure.
La cuenta de almacenamiento y las redes virtuales a las que se concedió acceso pueden
estar en distintas suscripciones, incluidas suscripciones que formen parte de un inquilino
de Microsoft Entra diferente.
La configuración de reglas que conceden acceso a subredes en redes virtuales que

forman parte de un inquilino de Microsoft Entra diferente solo se admiten actualmente
a través de PowerShell, la CLI de Azure y las API de REST. No puede configurar estas
reglas a través del Azure Portal, aunque puede verlos en el portal.
Puntos de conexión de servicio entre regiones de Azure

Storage
Los puntos de conexión de servicio entre regiones para Azure Storage están disponibles
con carácter general en abril de 2023. Funcionan entre redes virtuales e instancias de
servicio de almacenamiento en cualquier región. Con los puntos de conexión de servicio
entre regiones, las subredes ya no usan una dirección IP pública para comunicarse con
ninguna cuenta de almacenamiento, incluidas las de otra región. En su lugar, todo el
tráfico de subredes a las cuentas de almacenamiento usa una dirección IP privada como
dirección IP de origen. Como consecuencia, las cuentas de almacenamiento que usen
reglas de red IP para permitir el tráfico de esas subredes dejan de tener efecto.
La configuración de puntos de conexión de servicio entre redes virtuales e instancias de

servicio en una región emparejada puede ser una parte importante del plan de
recuperación ante desastres. Los puntos de conexión de servicio permiten la
continuidad durante una conmutación por error regional, así como un acceso a las
instancias de almacenamiento con redundancia geográfica de solo lectura (RA-GRS). Las
reglas de red que conceden acceso de una red virtual a una cuenta de almacenamiento
también conceden acceso a cualquier instancia de RA-GRS.
Al planear la recuperación ante desastres durante una interrupción regional, cree por
adelantado las redes virtuales en la región emparejada. Habilite puntos de conexión de
servicio para Azure Storage, con reglas de red que concedan acceso desde estas redes
virtuales alternativas. A continuación, aplique estas reglas a las cuentas de
almacenamiento con redundancia geográfica.
Los puntos de conexión de servicio locales y entre regiones no pueden coexistir en la
misma subred. Para reemplazar los puntos de conexión de servicio existentes por los de
varias regiones, elimine los puntos de conexión existentes Microsoft.Storage y vuelva a
crearlos como puntos de conexión entre regiones ( Microsoft.Storage.Global ).
Administración de reglas de red virtual

Puede administrar las reglas de red virtual para las cuentas de almacenamiento a través
del Azure Portal, PowerShell o la CLI de Azure v2.
Si desea habilitar el acceso a su cuenta de almacenamiento desde una red o subred

virtual en otro inquilino de Microsoft Entra, debe usar PowerShell o la CLI de Azure.
Azure Portal no muestra subredes en otros inquilinos de Microsoft Entra.
Portal
2. Seleccionar Redes.
3. Compruebe haber elegido permitir el acceso desde Redes seleccionadas.
4. Para conceder acceso a una red virtual con una nueva regla de red, en Redes
virtuales, seleccione Agregar red virtual existente. Seleccione las opciones
Redes virtuales y Subredes y, a continuación, haga clic en Agregar.
Para crear una nueva red virtual y concederle acceso, seleccione Agregar
nueva red virtual. Proporcione la información necesaria para crear la nueva
red virtual y, luego, seleccione Crear.
Si un punto de conexión de servicio para Azure Storage no se ha configurado

previamente para la red virtual y las subredes seleccionadas, se puede
configurar como parte de esta operación.
Actualmente, solo aparecen las redes virtuales que pertenecen al mismo

inquilino de Microsoft Entra para su selección durante la creación de la regla.
Para conceder acceso a una subred de una red virtual que pertenece a otro
inquilino, use PowerShell, la CLI de Azure o la API de REST.
5. Para quitar una regla de red virtual o subred, seleccione la elipsis (...) para abrir
el menú contextual de la red virtual o la subred y seleccione Quitar.

） Importante
Si elimina una subred que se ha incluido en una regla de red, se quitará de las
reglas de red de la cuenta de almacenamiento. Si crea una subred con el
mismo nombre, no tendrá acceso a la cuenta de almacenamiento. Para
permitir el acceso, deberá autorizar la nueva subred explícitamente en las
reglas de red de la cuenta de almacenamiento.
Concesión de acceso desde un intervalo IP de

Internet
Puede usar las reglas de red IP para permitir el acceso desde intervalos específicos de
direcciones IP de la red pública de Internet mediante la creación de reglas de red IP.
Cada cuenta de almacenamiento admite hasta 200 reglas. Estas reglas conceden acceso
a servicios específicos basados en Internet y redes locales, y bloquean el tráfico de
Internet general.
Restricciones para las reglas de red IP

Las restricciones siguientes se aplican a los intervalos de direcciones IP:
Las reglas de red IP solo se permiten para direcciones IP de la red pública de

Internet.
No se permiten intervalos de direcciones IP reservados para redes privadas (tal y

como se define en RFC 1918 ) en las reglas de IP. Las redes privadas incluyen
direcciones que comienzan por 10, 172.16 a 172.31 y 192.168.
Debe proporcionar los intervalos de dirección de Internet permitidos mediante la

notación CIDR en el formulario 16.17.18.0/24 o como direcciones IP individuales
en formato 16.17.18.19.
Los intervalos de dirección pequeños con tamaños de prefijos /31 o /32 no son
compatibles. Configure estos rangos utilizando reglas de direcciones IP
individuales.
Solo se admiten direcciones IPv4 para la configuración de reglas de firewall de

almacenamiento.
） Importante
Las reglas de red IP no se pueden usar en los siguientes casos:
Para restringir el acceso a los clientes de la misma región de Azure que la

cuenta de almacenamiento. Las reglas de red IP no tienen ningún efecto en
las solicitudes que proceden de la misma región de Azure que la cuenta de
almacenamiento. Use reglas de red virtual para permitir solicitudes de la
misma región.
Para restringir el acceso a los clientes de una región emparejada que se
encuentran en una red virtual que tiene un punto de conexión de servicio.
Para restringir el acceso a los servicios de Azure implementados en la misma
región que la cuenta de almacenamiento. Los servicios implementados en la
misma región que la cuenta de almacenamiento usan direcciones IP privadas
de Azure para la comunicación. Por lo tanto, no puede restringir el acceso a
servicios específicos de Azure en función de su intervalo de direcciones IP
salientes públicas.
Configuración del acceso desde redes locales

Para conceder acceso desde las redes locales a la cuenta de almacenamiento mediante
una regla de red IP, debe identificar las direcciones IP orientadas a Internet que usa su
red. Para obtener ayuda, póngase en contacto con el administrador de red.
Si usa Azure ExpressRoute desde las instalaciones para pares públicos o el

emparejamiento de Microsoft, tiene que identificar las direcciones IP de NAT que se
usan. Para el emparejamiento público, cada circuito ExpressRoute usa de forma
predeterminada dos direcciones IP de NAT que se aplican al tráfico del servicio de Azure
cuando el tráfico entra en la red troncal de Microsoft Azure. Para el emparejamiento de
Microsoft, el proveedor de servicios o el cliente proporciona las direcciones IP NAT.
Para permitir el acceso a los recursos de servicio, tiene que permitir estas direcciones IP
públicas en la configuración del firewall de IP de recursos. Para encontrar las direcciones
de IP de circuito de ExpressRoute de los pares públicos, abra una incidencia de soporte
técnico con ExpressRoute en Azure Portal. Obtenga más información sobre NAT para
ExpressRoute para emparejamiento público y de Microsoft.
Administración de reglas de red IP

Puede administrar las reglas de red de IP para las cuentas de almacenamiento a través
de Azure Portal, PowerShell o la CLI de Azure v2.
Portal
4. Para conceder acceso al intervalo IP de Internet, escriba la dirección IP o el

intervalo de direcciones (en formato CIDR) en Firewall>Intervalo de
direcciones.
5. Para quitar una regla de red de IP, seleccione el icono ( ) junto al intervalo
de direcciones.
Concesión de acceso a instancias de recursos

de Azure
En algunos casos, una aplicación puede depender de recursos de Azure que no se
pueden aislar a través de una regla de red virtual o de dirección IP. Pero aún le gustaría
proteger y restringir el acceso de la cuenta de almacenamiento solo a los recursos de
Azure de la aplicación. Puedes configurar cuentas de almacenamiento para permitir el
acceso a instancias de recursos específicas de servicios de Azure confiables mediante la
creación de una regla de instancia de recurso.
Las asignaciones de roles de Azure de la instancia de recurso determinan los tipos de

operaciones que una instancia de recurso puede realizar en los datos de la cuenta de
almacenamiento. Las instancias de recursos deben estar en el mismo inquilino que la
cuenta de almacenamiento, pero pueden pertenecer a cualquier suscripción del
inquilino.
Portal
Puede agregar o quitar reglas de red de recursos en Azure Portal:

2. Busque la cuenta de almacenamiento y muestre la información general de la
cuenta.
4. En Firewalls y redes virtuales, en Redes seleccionadas, seleccione la opción

permitir el acceso.
5. Desplácese hacia abajo para buscar Instancias de recursos. En la lista

desplegable Tipo de recurso, seleccione el tipo de recurso de la instancia de
recurso.
6. En la lista desplegable Nombre de instancia, seleccione la instancia de

recurso. También puede elegir incluir todas las instancias de recursos en el
inquilino, la suscripción o el grupo de recursos activos.
7. Seleccione Guardar para aplicar los cambios. La instancia de recurso aparece

en la sección Instancias de recursos de la página de configuración de red.
Para quitar la instancia de recurso, seleccione el icono de eliminación ( ) junto a la

instancia de recurso.
Concesión de acceso a servicios de Azure de

confianza
Algunos servicios de Azure funcionan desde redes que no se pueden incluir en las reglas
de red. Puede conceder a un subconjunto de estos servicios de Azure de confianza el
acceso a la cuenta de almacenamiento, a la vez que mantiene las reglas de red para
otras aplicaciones. Estos servicios de confianza usarán una autenticación sólida para
conectarse a su cuenta de almacenamiento.
Puede conceder acceso a servicios de Azure de confianza mediante la creación de una

excepción de regla de red. La sección Administración de excepciones de este artículo
proporciona instrucciones paso a paso.
Acceso de confianza para los recursos registrados en su

suscripción
Los recursos de algunos servicios que están registrados en su suscripción pueden
acceder a su cuenta de almacenamiento en la misma suscripción para ciertas
operaciones, como la escritura de registros o la realización de copias de seguridad. En la
tabla siguiente se describe cada servicio y las operaciones permitidas.
Servicio Nombre del proveedor de Operaciones permitidas

recursos
Azure Backup Microsoft.RecoveryServices Ejecute copias de seguridad y restauraciones de

discos no administrados en máquinas virtuales
de infraestructura como servicio (IaaS) (no
necesarias para discos administrados). Más
información.
Azure Data Box Microsoft.DataBox Importe datos en Azure. Más información.
Azure DevTest Microsoft.DevTestLab Cree imágenes personalizadas e instale

Labs artefactos. Más información.
Azure Event Microsoft.EventGrid Habilite la publicación de eventos de Azure

Grid Blob Storage y permita publicar en las colas de
almacenamiento.
Azure Event Microsoft.EventHub Archivar datos mediante Event Hubs Capture.

Hubs Más información.
Azure File Sync Microsoft.StorageSync Transforme el servidor de archivos local en una

memoria caché para los recursos compartidos
de archivos de Azure. Esta funcionalidad
permite la sincronización de varios sitios, la
recuperación ante desastres rápida y la copia
de seguridad en la nube. Más información.
HDInsight de Microsoft.HDInsight Aprovisione el contenido inicial del sistema de

Azure archivos predeterminado para un nuevo clúster
de HDInsight. Más información.
Azure Microsoft.ImportExport Importe datos a Azure Storage o exporte datos

Import/Export desde Azure Storage. Más información.
Azure Monitor Microsoft.Insights Escriba datos de supervisión en una cuenta de

almacenamiento protegida, incluidos los
registros de recursos, los registros de inicio de
sesión y de auditoría de Microsoft Entra y los
registros de Microsoft Intune. Más información.
Servicios de Microsoft.Network Almacene y analice los registros de tráfico de

redes de Azure red, incluidos los servicios Azure Network
Watcher y Azure Traffic Manager. Más
información.
Azure Site Microsoft.SiteRecovery Habilite la replicación para la recuperación ante

Recovery desastres de máquinas virtuales de IaaS de
Azure al usar la caché habilitada para firewall, el
Servicio Nombre del proveedor de Operaciones permitidas
origen o las cuentas de almacenamiento de
recursos
destino. Más información.
Acceso de confianza basado en la identidad administrada

asignada por el sistema
En la tabla siguiente se enumeran los servicios que pueden acceder a los datos de la
cuenta de almacenamiento si las instancias de recursos de esos servicios tienen el
permiso adecuado.
Servicio Nombre del proveedor de recursos Propósito
FarmBeats de Azure Microsoft.AgFoodPlatform/farmBeats Permite el acceso

a las cuentas de
almacenamiento.
Azure API Management Microsoft.ApiManagement/service Permite el acceso

a las cuentas de
almacenamiento
detrás de
firewalls a través
de directivas. Más
información.
Sistemas autónomos de Microsoft.AutonomousSystems/workspaces Permite el acceso

Microsoft a las cuentas de
almacenamiento.
Azure Cache for Redis Microsoft.Cache/Redis Permite el acceso

a las cuentas de
almacenamiento.
Más información.
Azure Cognitive Search Microsoft.Search/searchServices Habilita el acceso

a las cuentas de
almacenamiento
con fines de
indexación,
proceso y
consulta.
Servicios de Azure AI Microsoft.CognitiveService/accounts Permite el acceso

a las cuentas de
almacenamiento.
Más información.
Azure Container Registry Microsoft.ContainerRegistry/registries Mediante el

conjunto de
características de
ACR Tasks,
permite el acceso
a las cuentas de
almacenamiento
al compilar
imágenes de
contenedor.
Microsoft Microsoft.CostManagementExports Habilita la

Cost Management exportación a
cuentas de
almacenamiento
detrás de un
firewall. Más
información.
Azure Databricks Microsoft.Databricks/accessConnectors Permite el acceso

a las cuentas de
almacenamiento.
Azure Data Factory Microsoft.DataFactory/factories Permite el acceso

a las cuentas de
almacenamiento
a través del
entorno de
ejecución de Data
Factory.
Almacén de Microsoft.DataProtection/BackupVaults Permite el acceso

Azure Backup a las cuentas de
almacenamiento.
Azure Data Share Microsoft.DataShare/accounts Permite el acceso

a las cuentas de
almacenamiento.
Azure Database for Microsoft.DBForPostgreSQL Permite el acceso

PostgreSQL a las cuentas de
almacenamiento.
Azure IoT Hub Microsoft.Devices/IotHubs Permite que los

datos de un
centro de IoT se
escriban en Blob
Storage. Más
información.
Azure DevTest Labs Microsoft.DevTestLab/labs Permite el acceso

a las cuentas de
almacenamiento.
Azure Event Grid Microsoft.EventGrid/domains Permite el acceso

a las cuentas de
almacenamiento.
Azure Event Grid Microsoft.EventGrid/partnerTopics Permite el acceso

a las cuentas de
almacenamiento.
Azure Event Grid Microsoft.EventGrid/systemTopics Permite el acceso

a las cuentas de
almacenamiento.
Azure Event Grid Microsoft.EventGrid/topics Permite el acceso

a las cuentas de
almacenamiento.
Azure Healthcare API Microsoft.HealthcareApis/services Permite el acceso

a las cuentas de
almacenamiento.
Azure Healthcare API Microsoft.HealthcareApis/workspaces Permite el acceso

a las cuentas de
almacenamiento.
Azure IoT Central Microsoft.IoTCentral/IoTApps Permite el acceso

a las cuentas de
almacenamiento.
HSM administrado por Microsoft.keyvault/managedHSMs Permite el acceso

Azure Key Vault a las cuentas de
almacenamiento.
Azure Logic Apps Microsoft.Logic/integrationAccounts Permite a las

aplicaciones
lógicas acceder a
las cuentas de
almacenamiento.
Más información.
Azure Logic Apps Microsoft.Logic/workflows Permite a las

aplicaciones
lógicas acceder a
las cuentas de
almacenamiento.
Más información.
Azure Machine Learning Microsoft.MachineLearning/registries Permite a las

Studio áreas de trabajo
autorizadas de
Azure Machine
Learning escribir
los resultados del
experimento, los
modelos y los
registros en Blob
Storage y leer los
datos. Más
información.
Azure Machine Learning Microsoft.MachineLearningServices Permite a las

áreas de trabajo
autorizadas de
Azure Machine
Learning escribir
los resultados del
experimento, los
modelos y los
registros en Blob
Storage y leer los
datos. Más
información.
Azure Machine Learning Microsoft.MachineLearningServices/workspaces Permite a las

áreas de trabajo
autorizadas de
Azure Machine
Learning escribir
los resultados del
experimento, los
modelos y los
registros en Blob
Storage y leer los
datos. Más
información.
Azure Media Services Microsoft.Media/mediaservices Permite el acceso

a las cuentas de
almacenamiento.
Azure Migrate Microsoft.Migrate/migrateprojects Permite el acceso

a las cuentas de
almacenamiento.
Azure Spatial Anchors Microsoft.MixedReality/remoteRenderingAccounts Permite el acceso

a las cuentas de
almacenamiento.
Azure ExpressRoute Microsoft.Network/expressRoutePorts Permite el acceso

a las cuentas de
almacenamiento.
Microsoft Power Platform Microsoft.PowerPlatform/enterprisePolicies Permite el acceso

a las cuentas de
almacenamiento.
Microsoft Project Arcadia Microsoft.ProjectArcadia/workspaces Permite el acceso

a las cuentas de
almacenamiento.
Azure Data Catalog Microsoft.ProjectBabylon/accounts Permite el acceso

a las cuentas de
almacenamiento.
Microsoft Purview Microsoft.Purview/accounts Permite el acceso

a las cuentas de
almacenamiento.
Azure Site Recovery Microsoft.RecoveryServices/vaults Permite el acceso

a las cuentas de
almacenamiento.
Security Center Microsoft.Security/dataScanners Permite el acceso

a las cuentas de
almacenamiento.
Singularity Microsoft.Singularity/accounts Permite el acceso

a las cuentas de
almacenamiento.
Azure SQL Database Microsoft.Sql Permite escribir

datos de
auditoría en
cuentas de
almacenamiento
detrás de un
firewall.
Servidores de Azure SQL Microsoft.Sql/servers Permite escribir

datos de
auditoría en
cuentas de
almacenamiento
detrás de un
firewall.
Azure Synapse Analytics Microsoft.Sql Permite importar

y exportar datos
de bases de
datos SQL
específicas
mediante la
instrucción COPY
o PolyBase (en un
grupo dedicado)
o la función
openrowset y las
tablas externas
de un grupo de
servidores. Más
información.
Azure Stream Analytics Microsoft.StreamAnalytics Permite que los

datos de un
trabajo de
streaming se
escriban en Blob
Storage. Más
información.
Azure Stream Analytics Microsoft.StreamAnalytics/streamingjobs Permite que los

datos de un
trabajo de
streaming se
escriban en Blob
Storage. Más
información.
Azure Synapse Analytics Microsoft.Synapse/workspaces Permite el acceso

a datos en Azure
Storage.
Azure Video Indexer Microsoft.VideoIndexer/Accounts Permite el acceso

a las cuentas de
almacenamiento.
Si la cuenta no tiene habilitada la característica de espacio de nombres jerárquico,

puede conceder permiso mediante la asignación explícita de un rol de Azure a la
identidad administrada para cada instancia de recurso. En ese caso, el ámbito de acceso
de la instancia corresponde al rol de Azure que se asigna a la identidad administrada.
Puede usar la misma técnica para una cuenta que tenga la característica de espacio de
nombres jerárquico habilitada en ella. Sin embargo, no tiene que asignar un rol de
Azure si agrega la identidad administrada asignada por el sistema a la lista de control de
acceso (ACL) de cualquier directorio o blob que contiene la cuenta de almacenamiento.
En ese caso, el ámbito de acceso de la instancia corresponde al directorio o archivo al
que tiene acceso la identidad administrada.
También puede combinar roles y ACL de Azure para conceder acceso. Para más
información, consulte Modelo de control de acceso de Azure Data Lake Storage Gen2.
Se recomienda usar reglas de instancia de recursos para conceder acceso a recursos

específicos.
Administración de excepciones
En algunos casos, como los análisis de almacenamiento, se requiere acceso para leer
registros de recursos y métricas desde fuera del límite de red. Al configurar el acceso de
los servicios de confianza a la cuenta de almacenamiento, puede permitir el acceso de
lectura a los archivos de registro, las tablas de métricas o ambos mediante la creación
de una excepción de regla de red. Puede administrar las excepciones de reglas de red a
través de Azure Portal, PowerShell o la CLI de Azure v2.
Para más información sobre cómo trabajar con Storage Analytics, consulte Uso de Azure
Storage Analytics para recopilar datos de métricas y registros.
Portal
4. En Excepciones, seleccione las excepciones que quiere conceder.
Pasos siguientes
Más información sobre los puntos de conexión de servicio de red de Azure. Profundizar
más en la seguridad de Azure Storage.
Requisito de transferencia segura para
garantizar conexiones seguras
Artículo • 11/05/2023
Puede configurar la cuenta de almacenamiento para que acepte solicitudes de

conexiones seguras solo si establece la propiedad Se requiere transferencia segura para
la cuenta de almacenamiento. Cuando se requiere una transferencia segura, se rechazan
todas las solicitudes que se originan en una conexión no segura. Microsoft recomienda
que siempre se requiera una transferencia segura para todas las cuentas de
almacenamiento.
Cuando se requiere una transferencia segura, se debe realizar una llamada a una
operación de API REST de Azure Storage a través de HTTPS. Se rechaza cualquier
solicitud realizada a través de HTTP. De forma predeterminada, la propiedad Se requiere
transferencia segura se habilita al crear una cuenta de almacenamiento.
Azure Policy proporciona una directiva integrada para garantizar que se requiere una
transferencia segura para las cuentas de almacenamiento. Para obtener más
información, consulte la sección Almacenamiento de las definiciones de directivas
integradas de Azure Policy.
Se produce un error al establecer conexión con un recurso compartido de archivos de

Azure a través de SMB sin cifrado cuando se requiere la transferencia segura para la
cuenta de almacenamiento. Entre los ejemplos de conexiones no seguras se incluyen las
realizadas a través de SMB 2.1 o SMB 3.x sin cifrado.
７ Nota
Dado que Azure Storage no admite HTTPS para los nombres de dominio
personalizados, esta opción no se aplica cuando se utiliza un nombre de dominio
personalizado.
Esta configuración de transferencia segura no se aplica a TCP. Las conexiones por

medio del protocolo NFS 3.0 que admiten Azure Blob Storage con TCP, que no está
protegido, se realizarán correctamente.
Requerir una transferencia segura en Azure

Storage
Puede activar la propiedad Se requiere transferencia segura al crear una cuenta de
almacenamiento en Azure Portal . También puede habilitarla para cuentas de
almacenamiento existentes.
Solicitud de transferencia segura en una nueva cuenta de

almacenamiento
1. Abra el panel Crear cuenta de almacenamiento en Azure Portal.
2. En la página Avanzado, seleccione la casilla Habilitar transferencia segura.
Solicitud de transferencia segura en una cuenta de

almacenamiento existente
1. Seleccione una cuenta de almacenamiento existente en Azure Portal.
2. En el panel de menú de la cuenta de almacenamiento, en Configuración,

seleccione Opciones de configuración.
3. En Se requiere transferencia segura, seleccione Habilitado.

Requerir una transferencia segura desde el
código
Para requerir una transferencia segura mediante programación, establezca la propiedad
enableHttpsTrafficOnly en True en la cuenta de almacenamiento. Puede establecer esta
propiedad mediante la API REST del proveedor de recursos de almacenamiento, las
bibliotecas de cliente o las herramientas siguientes:
REST API
PowerShell
CLI
NodeJS
SDK de .NET
SDK de Python
SDK de Ruby
Requerir una transferencia segura con

PowerShell
７ Nota

En este ejemplo, debe utilizarse la versión 0.7 del módulo Az de Azure PowerShell o una
versión posterior. Ejecute Get-Module -ListAvailable Az para encontrar la versión. Si
necesita instalarla o actualizarla, consulte el artículo sobre cómo instalar el módulo de
Azure PowerShell.
Ejecute Connect-AzAccount para crear una conexión con Azure.
Utilice la siguiente línea de comandos siguiente para comprobar la configuración:
PowerShell
Get-AzStorageAccount -Name "{StorageAccountName}" -ResourceGroupName "

{ResourceGroupName}"
StorageAccountName : {StorageAccountName}
Kind : Storage
EnableHttpsTrafficOnly : False
...
Utilice la siguiente línea de comandos siguiente para habilitar la configuración:
PowerShell
Set-AzStorageAccount -Name "{StorageAccountName}" -ResourceGroupName "

{ResourceGroupName}" -EnableHttpsTrafficOnly $True
StorageAccountName : {StorageAccountName}
Kind : Storage
EnableHttpsTrafficOnly : True
...
Requerir una transferencia segura con la CLI de

Azure
Para ejecutar este ejemplo, instale la versión más reciente de la CLI de Azure. Para
empezar, ejecute az login para crear una conexión con Azure.
Los ejemplos de la CLI de Azure están escritos para el shell bash . Para ejecutar este
ejemplo en Windows PowerShell o en el símbolo del sistema, es posible que necesite
cambiar algunos elementos del script.
Si no tiene una suscripción a Azure, cree una cuenta gratuita de Azure antes de
empezar.
Utilice el comando siguiente para comprobar esta configuración:

Azure CLI
az storage account show -g {ResourceGroupName} -n {StorageAccountName}

{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": false,
"type": "Microsoft.Storage/storageAccounts"
...
}
Utilice el comando siguiente para habilitar la configuración:
Azure CLI
az storage account update -g {ResourceGroupName} -n {StorageAccountName} --

https-only true
{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": true,
"type": "Microsoft.Storage/storageAccounts"
...
}
Pasos siguientes
Recomendaciones de seguridad para Blob Storage
Detección, habilitación y deshabilitación
de SMBv1, SMBv2 y SMBv3 en Windows
Artículo • 18/05/2023
Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012, Windows 11, Windows 10,
Windows 8.1, Windows 8
En este artículo, se describe cómo habilitar y deshabilitar el protocolo Bloque de

mensajes del servidor (SMB) versión 1 (SMBv1), SMB versión 2 (SMBv2) y SMB versión 3
(SMBv3) en los componentes de cliente y servidor de SMB.
Aunque deshabilitar o quitar SMBv1 puede causar algunos problemas de compatibilidad

con equipos o software antiguos, SMBv1 tiene vulnerabilidades de seguridad
significativas y le recomendamos que no lo use . SMB 1.0 no está instalado de forma
predeterminada en ninguna edición de Windows 11 o Windows Server 2019, ni en las
versiones posteriores. SMB 1.0 tampoco está instalado de forma predeterminada en
Windows 10, excepto en las ediciones Home y Pro. Se recomienda que, en lugar de
volver a instalar SMB 1.0, actualice el servidor SMB que todavía lo requiere. Para obtener
una lista de terceros que requieran SMB 1.0 y sus actualizaciones que quiten el requisito,
examine el Centro de activación de productos SMB1 .
Deshabilitación de SMBv2 o SMBv3 para la

solución de problemas
Se recomienda mantener habilitados SMBv2 y SMBv3, pero es posible que le resulte útil
deshabilitar uno temporalmente para la solución de problemas. Para obtener más
información, consulte Cómo detectar el estado, habilitar y deshabilitar los protocolos
SMB.
En Windows 10, Windows 8.1, Windows Server 2019, Windows Server 2016,
Windows Server 2012 R2 y Windows Server 2012, deshabilitar SMBv3 desactiva la
funcionalidad siguiente:
Conmutación por error transparente: los clientes se vuelven a conectar sin

interrupción a los nodos del clúster durante el mantenimiento o la conmutación
por error
Escalado horizontal: acceso simultáneo a datos compartidos en todos los nodos de
clúster de archivos
Multicanal: agregación del ancho de banda de red y tolerancia a errores cuando
hay varias rutas disponibles entre el cliente y el servidor
SMB directo: agrega compatibilidad con redes RDMA para un alto rendimiento,
con baja latencia y un uso bajo de CPU.
Cifrado: proporciona cifrado de un extremo a otro y protege frente a la
interceptación en redes no confiables.
Concesión de directorios: mejora los tiempos de respuesta de las aplicaciones en
las sucursales mediante el almacenamiento en caché.
Optimizaciones de rendimiento: optimizaciones para operaciones de E/S de lectura
y escritura aleatorias pequeñas
En Windows 7 y Windows Server 2008 R2, deshabilitar SMBv2 desactiva la funcionalidad

siguiente:
Composición de solicitudes: permite enviar varias solicitudes SMBv2 como una

única solicitud de red.
Lecturas y escrituras más grandes: mejor uso de redes más rápidas
Almacenamiento en caché de propiedades de archivos y carpetas: los clientes
conservan copias locales de los archivos y las carpetas
Identificadores duraderos: permitir que la conexión se vuelva a conectar de forma
transparente al servidor si hay una desconexión temporal
Firma de mensajes mejorada: HMAC SHA-256 reemplaza a MD5 como algoritmo
hash.
Escalabilidad mejorada para compartir archivos: el número de usuarios, recursos
compartidos y archivos abiertos por servidor han aumentado considerablemente
Compatibilidad con vínculo simbólicos
Modelo de concesión de interbloqueo de cliente: limita los datos transferidos
entre el cliente y el servidor, lo que mejora el rendimiento en redes de alta latencia
y aumenta la escalabilidad del servidor SMB.
Compatibilidad con MTU grande: para un uso completo de Ethernet de 10 gigabits
(GbE)
Eficiencia energética mejorada: se pueden suspender los clientes que tienen
archivos abiertos en un servidor.
El protocolo SMBv2 se presentó en Windows Vista y Windows Server 2008, mientras que
el protocolo SMBv3 se presentó en Windows 8 y Windows Server 2012. Para obtener
más información sobre las funcionalidades de SMBv2 y SMBv3, consulte los artículos
siguientes:
Información general sobre el Bloque de mensajes del servidor

Novedades de SMB
Cómo quitar SMBv1 mediante PowerShell
Estos son los pasos para detectar, deshabilitar y habilitar el cliente y el servidor SMBv1
mediante comandos de PowerShell con privilegios elevados.
７ Nota
El equipo se reiniciará después de ejecutar los comandos de PowerShell para

deshabilitar o habilitar SMBv1.
Detección:
PowerShell
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
Deshabilite:
PowerShell
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
Habilite:
PowerShell
Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
 Sugerencia
Puede detectar el estado de SMBv1, sin privilegios elevados, mediante la ejecución

de: Get-SmbServerConfiguration | Format-List EnableSMB1Protocol .
Windows Server 2012, Windows Server 2012 R2,

Windows Server 2016, Windows Server 2019: método
mediante Administrador del servidor
Para quitar SMBv1 de Windows Server:
1. En el panel de Administrador del servidor correspondiente al servidor en el que

desea quitar SMBv1, en Configurar este servidor local, seleccione Agregar roles y
características.
2. En la página Antes de comenzar, seleccione Iniciar el Asistente para quitar roles y
características y, a continuación, en la página siguiente, seleccione Siguiente.
3. En la página Seleccionar servidor de destino en Grupo de servidores, asegúrese
de que esté seleccionado el servidor del que desea quitar la característica y, a
continuación, seleccione Siguiente.
4. En la página Quitar roles de servidor, seleccione Siguiente.
5. En la página Quitar características, desactive la casilla Compatibilidad para uso
compartido de archivos de SMB 1.0/CIFS y seleccione Siguiente.
6. En la página Confirmar selecciones de eliminación, confirme que aparece la
característica y, a continuación, seleccione Quitar.
Windows 8.1, Windows 10 y Windows 11: método

mediante Agregar o quitar programas
Para deshabilitar SMBv1 en los sistemas operativos mencionados:
1. En Panel de control, seleccione Programas y características.

2. En Panel de control Inicio, seleccione Activar o desactivar las características de
Windows para abrir el cuadro Características de Windows.
3. En el cuadro Características de Windows, desplácese hacia abajo en la lista,
desactive la casilla Compatibilidad para uso compartido de archivos de SMB
1.0/CIFS y seleccione Aceptar.
4. Después de que Windows aplique el cambio, en la página de confirmación,
seleccione Reiniciar ahora.
Cómo detectar el estado, habilitar y

deshabilitar los protocolos SMB
７ Nota
Al habilitar o deshabilitar SMBv2 en Windows 8 o Windows Server 2012, también se

habilita o deshabilita SMBv3. Este comportamiento se produce porque estos
protocolos comparten la misma pila.
Server
Windows 8 y Windows Server 2012 presentaron el nuevo cmdlet Set-

SMBServerConfiguration de Windows PowerShell. El cmdlet permite habilitar o
deshabilitar los protocolos SMBv1, SMBv2 y SMBv3 en el componente de servidor.
No es necesario reiniciar el equipo después de ejecutar el cmdlet Set-
SMBServerConfiguration.
SMBv1
Detección:
PowerShell
Get-SmbServerConfiguration | Select EnableSMB1Protocol
Deshabilite:
PowerShell
Set-SmbServerConfiguration -EnableSMB1Protocol $false
Habilite:
PowerShell
Set-SmbServerConfiguration -EnableSMB1Protocol $true
Para obtener más información, consulte Almacenamiento de servidor en

Microsoft .
SMB v2/v3
Detección:
PowerShell
Get-SmbServerConfiguration | Select EnableSMB2Protocol
Deshabilite:
PowerShell
Set-SmbServerConfiguration -EnableSMB2Protocol $false
Habilite:
PowerShell
Set-SmbServerConfiguration -EnableSMB2Protocol $true
Para Windows 7, Windows Server 2008 R2,

Windows Vista y Windows Server 2008
Para habilitar o deshabilitar los protocolos SMB en un servidor SMB que ejecuta
Windows 7, Windows Server 2008 R2, Windows Vista o Windows Server 2008, use
Windows PowerShell o el editor del Registro.
Métodos adicionales de PowerShell
７ Nota
Este método requiere PowerShell 2.0 o posterior.
SMBv1 en un servidor SMB
Detección:
PowerShell
Get-Item HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
| ForEach-Object {Get-ItemProperty $_.pspath}
Configuración predeterminada = Habilitado (no se crea ningún valor con nombre

del Registro), por lo que no se devolverá ningún valor de SMB1.
Deshabilite:
PowerShell
Set-ItemProperty -Path
"HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -
Type DWORD -Value 0 -Force
Habilite:
PowerShell
Nota Debe reiniciar el equipo después de realizar estos cambios. Para obtener más
información, consulte Almacenamiento de servidor en Microsoft .
SMBv2/v3 en un servidor SMB
Detección:
PowerShell
Get-ItemProperty
HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters |
ForEach-Object {Get-ItemProperty $_.pspath}
Deshabilite:
PowerShell
Habilite:
PowerShell
７ Nota
Debe reiniciar el equipo después de realizar estos cambios.
Editor del Registro
） Importante
Sigue meticulosamente los pasos que se describen en esta sección. Pueden

producirse problemas graves si modifica el Registro de manera incorrecta.
Antes de modificarlo, haz una copia de seguridad del registro para
restaurarlo , por si se produjeran problemas.
Para habilitar o deshabilitar SMBv1 en el servidor SMB, configure la siguiente clave

del Registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Para
meters
Registry entry: SMB1

REG_DWORD: 0 = Disabled
REG_DWORD: 1 = Enabled
Default: 1 = Enabled (No registry key is created)
Para habilitar o deshabilitar SMBv2 en el servidor SMB, configure la siguiente clave

del Registro:
meters
Registry entry: SMB2

REG_DWORD: 0 = Disabled
REG_DWORD: 1 = Enabled
Default: 1 = Enabled (No registry key is created)
７ Nota
Debe reiniciar el equipo después de realizar estos cambios.
Deshabilitar SMBv1 mediante una directiva de

grupo
En esta sección, se presenta cómo usar una directiva de grupo para deshabilitar SMBv1.
Puede usar este método en diferentes versiones de Windows.
Server
SMBv1
Este procedimiento configura el siguiente nuevo elemento en el Registro:
meters
Entrada del Registro: SMB1

REG_DWORD: 0 = Deshabilitado
Para usar una directiva de grupo para configurar esto, siga estos pasos:
1. Abra la Consola de administración de directivas de grupo. Haga clic con el

botón secundario en el objeto de directiva de grupo (GPO) que debería
contener el nuevo elemento de preferencia y, a continuación, haga clic en
Editar.
2. En la opción Configuración del equipo del árbol de la consola, expanda la

carpeta Preferencias y, a continuación, la carpeta Configuración de Windows.
3. Haga clic con el botón derecho en el nodo Registro, elija Nuevo y seleccione
Elemento del Registro.
En el cuadro de diálogo Nuevas propiedades de Registro, seleccione lo siguiente:
Acción: Crear
Subárbol: HKEY_LOCAL_MACHINE
Ruta de acceso de la clave:
SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Nombre del valor: SMB1
Tipo de valor: REG_DWORD
Datos del valor: 0
Este procedimiento deshabilita los componentes de servidor de SMBv1. Esta

directiva de grupo se debe aplicar a todas las estaciones de trabajo, servidores y
controladores de dominio necesarios en el dominio.
７ Nota
También se pueden establecer filtros WMI para excluir sistemas operativos no

admitidos o exclusiones seleccionadas, como Windows XP.
） Importante
Tenga cuidado al realizar estos cambios en los controladores de dominio en

los que Windows XP heredado o sistemas Linux antiguos y de terceros (que no
admiten SMBv2 ni SMBv3) requieran acceso a SYSVOL u otros recursos
compartidos de archivos en los que se va a deshabilitar SMB v1.
Auditoría del uso de SMBv1

Para determinar qué clientes intentan conectarse a un servidor SMB con SMBv1, puede
habilitar la auditoría en Windows Server 2016, Windows 10 y Windows Server 2019.
También puede auditar en Windows 7 y Windows Server 2008 R2 si está instalada la
actualización mensual de mayo de 2018 y, en Windows 8.1 y Windows Server 2012 R2, si
está instalada la actualización mensual de julio de 2017.
Habilite:
PowerShell
Set-SmbServerConfiguration -AuditSmb1Access $true
Deshabilite:
PowerShell
Set-SmbServerConfiguration -AuditSmb1Access $false
Detección:
PowerShell
Get-SmbServerConfiguration | Select AuditSmb1Access
Cuando la auditoría de SMBv1 está habilitada, aparece en el registro de eventos el

evento 3000 "Microsoft-Windows-SMBServer\Audit", identificando cada cliente que
intenta conectarse con SMBv1.
Resumen
Si toda la configuración está en el mismo GPO, la administración de la directiva de
grupo muestra la siguiente configuración.
Prueba y validación
Después de completar los pasos de configuración de este artículo, permita que la
directiva se replique y actualice. Según sea necesario para las pruebas, ejecute
gpupdate /force en un símbolo del sistema y revise los equipos de destino para
asegurarse de que la configuración del Registro se haya aplicado correctamente.
Asegúrese de que funcionen SMBv2 y SMBv3 en todos los demás sistemas del entorno.
７ Nota
No olvide reiniciar los sistemas de destino.

Eliminación de SMB 1 en Linux
Artículo • 24/05/2023
Muchas organizaciones y proveedores de servicios de Internet (ISP) bloquean el puerto

que usa SMB para comunicarse, el puerto 445. Esta práctica procede de las instrucciones
de seguridad sobre las versiones heredadas y en desuso del protocolo SMB. Aunque
SMB 3.x es un protocolo seguro para Internet, las versiones anteriores de SMB,
especialmente SMB 1, no lo son. SMB 1, también conocido como CIFS (Sistema de
archivos de Internet común), se incluye en muchas distribuciones de Linux.
SMB 1 es un protocolo obsoleto, ineficaz y no seguro. La buena noticia es que Azure

Files no es compatible con SMB 1. Además, a partir de la versión 4.18 del kernel de
Linux, Linux hace posible deshabilitar SMB 1. Siempre recomendamos
encarecidamente deshabilitar SMB 1 en los clientes Linux antes de usar recursos
compartidos de archivos SMB en producción.
Estado de la distribución de Linux

A partir del kernel de Linux 4.18, el módulo de kernel de SMB, denominado cifs por
motivos de herencia, expone un nuevo parámetro de módulo (a menudo conocido
como parm de diversos documentos externos), denominado disable_legacy_dialects .
Aunque se presentó en el kernel de Linux 4.18, algunos proveedores han trasladado este
cambio a los kernels más antiguos que admiten. En la tabla siguiente se detalla la
disponibilidad de este parámetro de módulo en distribuciones de Linux comunes.
Distribución Puede deshabilitar SMB 1
Ubuntu 14.04-16.04 No
Ubuntu 18.04 Sí
Ubuntu 19.04+ Sí
Debian 8-9 No
Debian 10+ Sí
Fedora 29+ Sí
CentOS 7 No
CentOS 8+ Sí
Red Hat Enterprise Linux 6.x-7.x No

Distribución Puede deshabilitar SMB 1
Red Hat Enterprise Linux 8+ Sí
openSUSE Leap 15.0 No
openSUSE Leap 15.1+ Sí
openSUSE Tumbleweed Sí
SUSE Linux Enterprise 11.x-12.x No
SUSE Linux Enterprise 15 No
SUSE Linux Enterprise 15.1 No
Puede comprobar si la distribución de Linux es compatible con el parámetro del módulo

disable_legacy_dialects por medio del comando siguiente:
Bash
sudo modinfo -p cifs | grep disable_legacy_dialects
Este comando debe generar el siguiente mensaje:
Resultados
disable_legacy_dialects: To improve security it may be helpful to restrict

the ability to override the default dialects (SMB2.1, SMB3 and SMB3.02) on
mount with old dialects (CIFS/SMB1 and SMB2) since vers=1.0 (CIFS/SMB1) and
vers=2.0 are weaker and less secure. Default: n/N/0 (bool)
Eliminación de SMB 1
Antes de deshabilitar SMB 1, confirme que el módulo SMB no está cargado actualmente
en el sistema (esto sucede de manera automática si ha montado un recurso compartido
de SMB). Ejecute el siguiente comando, que no debe generar nada si SMB no está
cargado:
Bash
lsmod | grep cifs
Para descargar el módulo, desmonte primero todos los recursos compartidos de SMB
con el comando umount . Puede identificar todos los recursos compartidos de SMB
montados en el sistema con el siguiente comando:
Bash
mount | grep cifs
Una vez que haya desmontado todos los recursos compartidos de archivos SMB, es
seguro descargar el módulo. Ejecute el comando modprobe :
Bash
sudo modprobe -r cifs
Puede cargar manualmente el módulo con SMB 1 descargado mediante el comando

modprobe :
Bash
sudo modprobe cifs disable_legacy_dialects=Y
Por último, puede comprobar que el módulo SMB se ha cargado con el parámetro, para
ello, examine los parámetros cargados en /sys/module/cifs/parameters :
Bash
cat /sys/module/cifs/parameters/disable_legacy_dialects
Para deshabilitar de forma persistente SMB 1 en las distribuciones basadas en Ubuntu y

Debian, debe crear un nuevo archivo (si aún no tiene opciones personalizadas para
otros módulos) denominado /etc/modprobe.d/local.conf con la configuración. Ejecute
el comando siguiente:
Bash
echo "options cifs disable_legacy_dialects=Y" | sudo tee -a

/etc/modprobe.d/local.conf > /dev/null
Para comprobar que esto ha funcionado, cargue el módulo SMB:
Bash
sudo modprobe cifs

cat /sys/module/cifs/parameters/disable_legacy_dialects
Pasos siguientes

Uso de Azure Files con Linux
Solución de problemas de SMB en Linux
Solución de problemas de NFS en Linux
Aplicación de una versión mínima
necesaria de Seguridad de la capa de
transporte (TLS) para las solicitudes a
una cuenta de almacenamiento
Artículo • 25/03/2023
La comunicación entre una aplicación cliente y una cuenta de Azure Storage se cifra
mediante la Seguridad de la capa de transporte (TLS). TLS es un protocolo criptográfico
estándar que garantiza la privacidad y la integridad de los datos entre los clientes y los
servicios a través de Internet. Para más información acerca de TLS, consulte Seguridad
de la capa de transporte .
Actualmente, Azure Storage admite tres versiones del protocolo TLS: 1.0, 1.1 y 1.2. Azure
Storage usa TLS 1.2 en puntos de conexión HTTP públicos. Sin embargo, TLS 1.0 y
TLS 1.1 se siguen admitiendo gracias a la compatibilidad con versiones anteriores.
Las cuentas de Azure Storage permiten a los clientes enviar y recibir datos con la versión
más antigua de TLS (TLS 1.0) y con las versiones posteriores. Para aplicar medidas de
seguridad más estrictas, puede configurar la cuenta de almacenamiento para que los
clientes deban enviar y recibir datos con una versión más reciente de TLS. Si una cuenta
de almacenamiento requiere una versión mínima de TLS, se producirá un error en todas
las solicitudes realizadas con una versión anterior.
En este artículo se describe cómo usar un marco de tipo DRAG (detección-corrección-

auditoría-gobernanza) para administrar continuamente una Seguridad de la capa de
transporte segura para las cuentas de almacenamiento.
Para obtener información acerca de cómo especificar una versión concreta de TLS al
enviar una solicitud desde una aplicación cliente, consulte Configuración de la
Seguridad de la capa de transporte (TLS) para una aplicación cliente.
７ Nota
El conjunto de cifrado que se usa tanto cuando los clientes envían datos a una
cuenta de almacenamiento como cuando los reciben de ella depende de la versión
de TLS usada. No es posible configurar una cuenta de almacenamiento para
bloquear el uso de cifrados específicos, más allá de requerir una versión mínima de
TLS. Si necesita la capacidad de permitir solo conjuntos de cifrado específicos al
conectarse a una cuenta de almacenamiento, considere la posibilidad de usar Azure
Application Gateway. Para más información sobre el uso de Application Gateway
para este fin, consulte Configuración de versiones de directivas TLS y conjuntos
de cifrado en Azure Application Gateway.
Detección de la versión de TLS que usan las

aplicaciones cliente
Cuando se aplica una versión mínima de TLS para la cuenta de almacenamiento, se
corre el riesgo de rechazar las solicitudes de los clientes que envían datos con una
versión anterior de TLS. Para comprender cómo la configuración de la versión mínima
de TLS puede afectar a las aplicaciones cliente, Microsoft recomienda que habilite el
registro para su cuenta de Azure Storage y analice los registros después de un intervalo
de tiempo para detectar qué versiones de TLS están usando las aplicaciones cliente.
Para registrar las solicitudes a la cuenta de Azure Storage y determinar qué versión de
TLS usa el cliente, puede usar el registro de Azure Storage en Azure Monitor. Para más
información, consulte Supervisión de Azure Storage.
El registro de Azure Storage en Azure Monitor admite el uso de consultas de registro

para analizar los datos de registro. Para consultar los registros, puede usar un área de
trabajo de Azure Log Analytics. Para más información sobre las consultas de registro,
consulte el Tutorial: Introducción a las consultas de Log Analytics.
Para registrar datos de Azure Storage con Azure Monitor y analizarlos con Azure Log
Analytics, primero debe crear una configuración de diagnóstico que indique qué tipos
de solicitudes y para qué servicios de almacenamiento quiere registrar los datos. Para
crear una configuración de diagnóstico en Azure Portal, siga estos pasos:
1. Cree un área de trabajo de Log Analytics en la suscripción que contenga la cuenta

de Azure Storage. Después de configurar el registro de la cuenta de
almacenamiento, los registros estarán disponibles en el área de trabajo de Log
Analytics. Para obtener más información, consulte Creación de un área de trabajo
de Log Analytics en Azure Portal.
3. En la sección Supervisión, seleccione Configuración de diagnóstico.
4. Seleccione el servicio de Azure Storage cuyas solicitudes quiere registrar. Por

ejemplo, elija Blob para registrar las solicitudes a Blob Storage.
5. Seleccione Agregar configuración de diagnóstico.

6. Proporcione un nombre para la configuración de diagnóstico.
7. En Detalles de la categoría, en la sección registro, elija qué tipos de solicitudes

registrar. Puede registrar las solicitudes de lectura, escritura y eliminación. Por
ejemplo, al elegir StorageRead y StorageWrite se registrarán las solicitudes de
lectura y escritura del servicio seleccionado.
8. En Detalles del destino, seleccione Enviar a Log Analytics. Seleccione la

suscripción y el área de trabajo de Log Analytics que creó anteriormente, como se
Después de crear la configuración de diagnóstico, las solicitudes a la cuenta de

almacenamiento se registran posteriormente según esa configuración. Para más
información, consulte Creación de una configuración de diagnóstico para recopilar
registros y métricas en Azure.
En el artículo Registros de recursos encontrará una referencia sobre los campos

disponibles en los registros de Azure Storage en Azure Monitor.
Consulta de las solicitudes registradas por versión de TLS

Los registros de Azure Storage en Azure Monitor incluyen la versión de TLS que se usó
para hacer una solicitud a una cuenta de almacenamiento. Use la propiedad TlsVersion
para comprobar la versión de TLS de una solicitud registrada.
Para determinar cuántas solicitudes se realizaron a Blob Storage con cada versión de TLS
durante los últimos siete días, abra su área de trabajo de Log Analytics. Luego, pegue la
siguiente consulta en una nueva consulta de registro y ejecútela. No olvide reemplazar
los valores del marcador de posición entre corchetes con sus propios valores:
Kusto
StorageBlobLogs
| where TimeGenerated > ago(7d) and AccountName == "<account-name>"
| summarize count() by TlsVersion
Los resultados muestran el número de solicitudes realizadas con cada versión de TLS:
Consulta de solicitudes registradas por dirección IP del

autor de la llamada y por encabezado del agente de
usuario
Los registros de Azure Storage en Azure Monitor también incluyen la dirección IP del
autor de la llamada y el encabezado del agente de usuario para ayudarle a evaluar qué
aplicaciones cliente tienen acceso a la cuenta de almacenamiento. Puede analizar estos
valores para determinar si las aplicaciones cliente deben actualizarse para usar una
versión más reciente de TLS, o si es aceptable que se produzca un error en la solicitud
de un cliente si no se envía con la versión mínima de TLS.
Para determinar qué clientes realizaron solicitudes con una versión de TLS anterior a
TLS 1.2 en los últimos siete días, pegue la siguiente consulta en una nueva consulta de
registro y ejecútela. No olvide reemplazar los valores del marcador de posición entre
corchetes con sus propios valores:
Kusto
StorageBlobLogs
| where TimeGenerated > ago(7d) and AccountName == "<account-name>" and
TlsVersion != "TLS 1.2"
| project TlsVersion, CallerIpAddress, UserAgentHeader
Corrección de riesgos de seguridad con una

versión mínima de TLS
Si está seguro de que el tráfico de los clientes que usan versiones anteriores de TLS es
mínimo, o que es aceptable que se produzcan errores en las solicitudes realizadas con
una versión anterior de TLS, puede empezar a aplicar una versión de TLS mínima en la
cuenta de almacenamiento. Requerir que los clientes usen una versión mínima de TLS
para realizar solicitudes en una cuenta de almacenamiento forma parte de una
estrategia para minimizar los riesgos de seguridad de los datos.
） Importante
Si usa un servicio que se conecta a Azure Storage, asegúrese de que ese servicio
use la versión adecuada de TLS para enviar solicitudes a Azure Storage antes de
establecer la versión mínima necesaria para una cuenta de almacenamiento.
Configuración de la versión mínima de TLS para una

cuenta de almacenamiento
Para configurar la versión mínima de TLS para una cuenta de almacenamiento,
establezca la versión MinimumTlsVersion de la cuenta. Esta propiedad está disponible
para todas las cuentas de almacenamiento que se crean con el modelo de
implementación de Azure Resource Manager. Para más información sobre el modelo de
implementación de Azure Resource Manager, consulte Introducción a las cuentas de
almacenamiento.
El valor predeterminado de la propiedad MinimumTlsVersion es diferente en función de

cómo se establezca. Al crear una cuenta de almacenamiento con Azure Portal, la versión
mínima de TLS se establece en 1.2 de forma predeterminada. Al crear una cuenta de
almacenamiento con PowerShell, la CLI de Azure o una plantilla de Azure Resource
Manager, la propiedad MinimumTlsVersion no se establece de forma predeterminada y
no devuelve un valor hasta que se establece explícitamente.
Cuando la propiedad MinimumTlsVersion no está establecida, su valor se puede
mostrar como null o como una cadena vacía, en función del contexto. Si el valor de la
propiedad no está establecido, la cuenta de almacenamiento permitirá las solicitudes
enviadas con la versión 1.0 o posterior de TLS.
Portal
Al crear una cuenta de almacenamiento con Azure Portal, la versión mínima de TLS
se establece en 1.2 de forma predeterminada.
Para configurar la versión mínima de TLS de una cuenta de almacenamiento

existente con Azure Portal, siga estos pasos:
2. En Configuración, seleccione Configuración.
3. En Versión mínima de TLS, use la lista desplegable para seleccionar la versión

mínima de TLS necesaria para acceder a los datos de esta cuenta de
almacenamiento.
７ Nota
Después de actualizar la versión mínima de TLS para la cuenta de almacenamiento,

el cambio puede tardar hasta 30 segundos en propagarse por completo.
La configuración de la versión de TLS mínima requiere la versión 2019-04-01 o posterior
del proveedor de recursos de Azure Storage. Para más información, consulte la API REST
del proveedor de recursos de Azure Storage.
Comprobación de la versión mínima de TLS requerida

para varias cuentas
Para comprobar la versión mínima de TLS necesaria en un conjunto de cuentas de
almacenamiento con un rendimiento óptimo, puede usar Azure Resource Graph
Explorer en Azure Portal. Para más información sobre el uso de Resource Graph Explorer,
consulte Inicio rápido: Ejecución de la primera consulta de Resource Graph mediante
Azure Resource Graph Explorer.
Si la siguiente consulta se ejecuta en Resource Graph Explorer, este devuelve una lista
de cuentas de almacenamiento y muestra la versión mínima de TLS de cada cuenta:
Kusto
resources
| where type =~ 'Microsoft.Storage/storageAccounts'
| extend minimumTlsVersion = parse_json(properties).minimumTlsVersion
| project subscriptionId, resourceGroup, name, minimumTlsVersion
Prueba de la versión mínima de TLS desde un cliente

Para probar que la versión mínima de TLS necesaria para una cuenta de
almacenamiento impida las llamadas realizadas con una versión anterior, puede
configurar un cliente para que use una versión anterior de TLS. Para obtener más
información acerca de cómo configurar un cliente para que use una versión específica
de TLS, consulte Configuración de la Seguridad de la capa de transporte (TLS) para una
aplicación cliente.
Cuando un cliente acceda a una cuenta de almacenamiento mediante una versión de

TLS que no cumpla con la versión mínima de TLS configurada para la cuenta, Azure
Storage devolverá el código de error 400 (solicitud incorrecta) y un mensaje indicando
que la versión de TLS que se usó no está permitida para realizar solicitudes en esta
７ Nota
Al configurar una versión mínima de TLS para una cuenta de almacenamiento, esa
versión mínima se aplica en la capa de aplicación. Las herramientas que intentan
determinar la compatibilidad de TLS en la capa de protocolo pueden devolver
versiones de TLS además de la versión mínima necesaria cuando se ejecutan
directamente en el punto de conexión de la cuenta de almacenamiento.
Uso de Azure Policy para auditar el

cumplimiento
Si tiene un gran número de cuentas de almacenamiento, tal vez quiera realizar una
auditoría para asegurarse de que todas las cuentas están configuradas para la versión
mínima de TLS que requiere la organización. Para auditar un conjunto de cuentas de
almacenamiento para su cumplimiento, use Azure Policy. Azure Policy es un servicio que
puede usar para crear, asignar y administrar directivas que aplican reglas a los recursos
de Azure. Azure Policy le permite mantener esos recursos conforme a lo establecido en
los estándares corporativos y los contratos de nivel de servicio. Para más información,
consulte la Introducción a Azure Policy.
Creación de una directiva con un efecto de auditoría

Azure Policy admite efectos que determinan lo que sucede cuando una regla de
directiva se evalúa con respecto a un recurso. El efecto de auditoría crea una advertencia
cuando un recurso no cumple los requisitos, pero no detiene la solicitud. Para más
información, consulte Comprender los efectos de Azure Policy.
Para crear una directiva con un efecto de auditoría para la versión mínima de TLS con
Azure Portal, siga estos pasos:
1. En Azure Portal, vaya al servicio Azure Policy.
2. Seleccione Definiciones en la sección Creación.
3. Seleccione Agregar definición de directiva para crear una nueva definición de

directiva.
4. En el campo donde se indica la ubicación de la definición, seleccione el botón

Más para especificar dónde se encuentra el recurso de directiva de auditoría.
5. Escriba un nombre para la directiva. Si lo desea, puede escribir también una

descripción y la categoría.
6. En Regla de directivas, agregue la siguiente definición de directiva a la sección

policyRule.
JSON
{
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"anyOf": [
{
"field":
"Microsoft.Storage/storageAccounts/minimumTlsVersion",
"notEquals": "TLS1_2"
},
{
"field":
"exists": "false"
}
]
}
]
},
"then": {
"effect": "audit"
}
}
}
7. Guarde la directiva.
Asignación de la directiva
A continuación, asigne la directiva a un recurso. El ámbito de la directiva corresponde a
ese recurso y a todos los recursos que hay debajo del mismo. Para más información
sobre la asignación de directivas, consulte Estructura de asignaciones de Azure Policy.
Para asignar la directiva con Azure Portal, haga lo siguiente:

2. Seleccione Asignaciones en la sección Creación.
3. Seleccione Asignar directiva para crear una nueva asignación de directiva.
4. En el campo Ámbito, seleccione el ámbito de la asignación de directiva.
5. En el campo Definición de directiva, seleccione el botón Más y, a continuación,
seleccione la directiva que definió en la sección anterior de la lista.
6. Escriba un nombre para la asignación de directiva. La descripción es opcional.
7. Deje la opción Cumplimiento de directivas como Habilitada. Esta configuración no
tiene ningún efecto en la directiva de auditoría.
8. Seleccione Revisar y crear para crear la asignación.
Ver el informe de cumplimiento

Una vez asignada la directiva, puede ver el informe de cumplimiento. El informe de
cumplimiento de una directiva de auditoría proporciona información sobre las cuentas
de almacenamiento que no cumplen con esa directiva. Para más información, consulte
Obtención de datos de cumplimiento de directiva.
El informe de cumplimiento puede tardar varios minutos en estar disponible después de

que se cree la asignación de directiva.
Para ver el informe de cumplimiento en Azure Portal, siga estos pasos:
2. Seleccione Cumplimiento.
3. Filtre los resultados por el nombre de la asignación de directiva que creó en el

paso anterior. El informe muestra el número de recursos que no cumplen con la
directiva.
4. Puede explorar en profundidad el informe para obtener más detalles, incluida una
lista de cuentas de almacenamiento que no cumplen los requisitos.
Uso de Azure Policy para aplicar la versión
mínima de TLS
Azure Policy admite la gobernanza en la nube, asegurándose así de que los recursos de
Azure cumplen los requisitos y los estándares establecidos. Para aplicar un requisito
mínimo de versión de TLS para las cuentas de almacenamiento de la organización,
puede crear una directiva que impida la creación de una nueva cuenta de
almacenamiento que establezca un requisito mínimo de TLS en una versión anterior de
TLS que la que se indica en la directiva. Esta directiva también impedirá todos los
cambios de configuración en una cuenta existente si la configuración de la versión
mínima de TLS no es compatible con la directiva.
La directiva de cumplimiento usa el efecto de denegación para impedir que una

solicitud cree o modifique una cuenta de almacenamiento para que la versión de TLS
mínima ya no se adhiera a los estándares de la organización. Para más información,
consulte Comprender los efectos de Azure Policy.
Para crear una directiva con un efecto de denegación para una versión mínima de TLS
que sea anterior a TLS 1.2, siga los mismos pasos que se indican en Uso de Azure Policy
para auditar el cumplimiento, pero proporcione el siguiente código JSON en la sección
policyRule de la definición de directivas:
JSON
{
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"anyOf": [
{
"field":
"notEquals": "TLS1_2"
},
{
"field":
"exists": "false"
}
]
}
]
},
"then": {
"effect": "deny"
}
}
}
Después de crear la directiva con el efecto de denegación y asignarla a un ámbito, un

usuario no puede crear una cuenta de almacenamiento con una versión de TLS mínima
que sea anterior a la 1.2. Asimismo, los usuarios tampoco pueden realizar cambios de
configuración en una cuenta de almacenamiento existente que actualmente requiera
una versión mínima de TLS que sea anterior a la 1.2. Si intentan hacerlo, se producirá un
error. La versión mínima de TLS requerida de la cuenta de almacenamiento debe
establecerse en 1.2 para continuar con la creación o la configuración de la cuenta.
En la siguiente imagen se muestra el error que se produce si se intenta crear una cuenta
de almacenamiento con una versión mínima de TLS establecida en TLS 1.0 (la versión
predeterminada para una nueva cuenta) cuando una directiva con un efecto de
denegación requiere que la versión mínima de TLS se establezca en TLS 1.2.
Permisos necesarios para requerir una versión

mínima de TLS
Para establecer la propiedad MinimumTlsVersion para la cuenta de almacenamiento, el
usuario debe tener permisos para crear y administrar cuentas de almacenamiento. Los
roles de control de acceso basado en rol de Azure (Azure RBAC) que proporcionan estos
permisos incluyen la acción Microsoft.Storage/storageAccounts/write o
Microsoft.Storage/storageAccounts/*. Los roles integrados con esta acción incluyen:
El rol Propietario de Azure Resource Manager

El rol Colaborador de Azure Resource Manager
El rol Colaborador de la cuenta de almacenamiento
Estos roles no proporcionan acceso a los datos de una cuenta de almacenamiento a

través de Azure Active Directory (Azure AD). Sin embargo, incluyen
Microsoft.Storage/storageAccounts/listkeys/action, que concede acceso a las claves de
acceso de la cuenta. Con este permiso, un usuario puede usar las claves de acceso de la
cuenta para acceder a todos los datos de una cuenta de almacenamiento.
Las asignaciones de roles deben tener el ámbito del nivel de la cuenta de
almacenamiento o superior para permitir que un usuario requiera una versión mínima
de TLS para la cuenta de almacenamiento. Para obtener más información sobre el
ámbito de los roles, vea Comprensión del ámbito para RBAC de Azure.
Tenga cuidado de restringir la asignación de estos roles solo a aquellos usuarios que
requieran la capacidad de crear una cuenta de almacenamiento o actualizar sus
propiedades. Use el principio de privilegios mínimos para asegurarse de que los
usuarios tienen los permisos mínimos que necesitan para realizar sus tareas. Para más
información sobre la administración del acceso con RBAC de Azure, consulte
Procedimientos recomendados para RBAC de Azure.
７ Nota
Los roles clásicos de administrador de suscripciones Administrador del servicio y

Coadministrador equivalen al rol Propietario de Azure Resource Manager. El rol
Propietario incluye todas las acciones, por lo que un usuario con uno de estos roles
administrativos también puede crear y administrar cuentas de almacenamiento.
Para más información, consulte Roles de Azure, roles de Azure AD y roles de
administrador de la suscripción clásica.
Consideraciones sobre la red

Cuando un cliente envía una solicitud a una cuenta de almacenamiento, debe establecer
primero una conexión con el punto de conexión público de la cuenta de
almacenamiento, antes de procesar las solicitudes. Una vez establecida la conexión, se
comprueba la configuración de la versión de TLS mínima. Si la solicitud usa una versión
de TLS anterior que la especificada en la configuración, la conexión continuará
correctamente, pero la solicitud producirá un error después. Para obtener más
información acerca de los puntos de conexión públicos para Azure Storage, consulte
Sintaxis del URI de recurso.
Pasos siguientes
Configuración de Seguridad de la capa de transporte (TLS) para una aplicación
cliente
Configuración de Seguridad de la capa
de transporte (TLS) para una aplicación
cliente
Artículo • 07/04/2023
Por motivos de seguridad, las cuentas de Azure Storage pueden exigir a los clientes que
usen una versión mínima de Seguridad de la capa de transporte (TLS) para enviar
solicitudes. Si el cliente usa una versión de TLS inferior a la versión mínima necesaria, se
producirá un error en las llamadas a Azure Storage. Por ejemplo, si una cuenta de
almacenamiento requiere TLS 1.2, las solicitudes enviadas por un cliente que use TLS 1.1
generarán un error.
En este artículo se describe cómo configurar una aplicación cliente para usar una versión
determinada de TLS. Para información sobre cómo configurar una versión mínima
necesaria de TLS para una cuenta de Azure Storage, consulte Configuración de la
versión mínima necesaria de Seguridad de la capa de transporte (TLS) para una cuenta
de almacenamiento.
Configuración de la versión de TLS del cliente

Para que un cliente envíe una solicitud con una versión determinada de TLS, el sistema
operativo debe ser compatible con esa versión.
En los siguientes ejemplos se muestra cómo establecer la versión de TLS del cliente en la
1.2 desde PowerShell o .NET. La versión de .NET Framework que utiliza el cliente debe
admitir TLS 1.2. Para más información, consulte Compatibilidad con TLS 1.2.
PowerShell
En el ejemplo siguiente se muestra cómo habilitar TLS 1.2 en el cliente de

PowerShell.
PowerShell
# Set the TLS version used by the PowerShell client to TLS 1.2.
[System.Net.ServicePointManager]::SecurityProtocol =
[System.Net.SecurityProtocolType]::Tls12;
# Create a new container.

$storageAccount = Get-AzStorageAccount -ResourceGroupName $rgName -Name
$accountName
$ctx = $storageAccount.Context
New-AzStorageContainer -Name "sample-container" -Context $ctx
Comprobación de la versión de TLS utilizada

por un cliente
Para comprobar que el cliente usó la versión especificada de TLS para enviar una
solicitud, puede usar Fiddler o una herramienta similar. Abra Fiddler para empezar a
capturar el tráfico de red del cliente y, luego, ejecute uno de los ejemplos de la sección
anterior. Examine el seguimiento de Fiddler para confirmar que se usó la versión
correcta de TLS para enviar la solicitud, como se muestra en la siguiente imagen.
Pasos siguientes
Configuración de la versión mínima necesaria de Seguridad de la capa de
transporte (TLS) para una cuenta de almacenamiento
Artículo • 18/12/2023
） Contenido asistido por IA. Este artículo se ha creado en parte con ayuda de inteligencia artificial.
Un autor ha revisado y modificado el contenido según ha sido necesario. Más información
AzCopy es una utilidad de línea de comandos que puede usar para copiar blobs o
archivos a una cuenta de almacenamiento o desde una cuenta de almacenamiento. En
este artículo sirve de ayuda para descargar AzCopy, conectarse a la cuenta de
almacenamiento y, a continuación, transferir datos.
７ Nota
AzCopy V10 es la versión admitida actualmente de AzCopy.
Si necesita usar una versión anterior de AzCopy, consulte la sección Uso de la

versión anterior de AzCopy de este artículo.
En este vídeo se muestra cómo descargar y ejecutar la utilidad AzCopy.

https://learn-video.azurefd.net/vod/player?id=4238a2be-881a-4aaa-8ccd-
07a6557a05ef&locale=es-
es&embedUrl=%2Fazure%2Fstorage%2Fcommon%2Fstorage-use-azcopy-v10
Los pasos del vídeo también se describen en las secciones siguientes.
Descargar AzCopy
En primer lugar, descargue el archivo ejecutable de AzCopy V10 en cualquier directorio
en el equipo. AzCopy V10 es solo un archivo ejecutable, de modo que no hay que
instalar nada.
Windows 64 bits (zip)

Windows 32 bits (zip)
Linux x86-64 (tar)
Linux ARM64 (tar)
macOS (zip)
Versión preliminar macOS ARM64 (zip)
Estos archivos se comprimen como un archivo ZIP (Windows y Mac) o un archivo TAR
(Linux). Para descargar y descomprimir el archivo tar en Linux, consulte la
documentación de su distribución de Linux.
Para obtener información detallada sobre las versiones de AzCopy, vea la página de la
versión de AzCopy .
７ Nota
Si desea copiar datos desde y hacia su servicio de almacenamiento de Azure Table,

instale AzCopy versión 7.3 .
Ejecución de AzCopy
Para mayor comodidad, considere la posibilidad de agregar la ubicación del directorio
del ejecutable de AzCopy a la ruta de acceso del sistema para facilitar su uso. De este
modo, puede escribir azcopy desde cualquier directorio del sistema.
Si decide no agregar el directorio de AzCopy a la ruta de acceso, tendrá que cambiar los
directorios a la ubicación de su archivo ejecutable de AzCopy y escribir azcopy o
.\azcopy en los símbolos del sistema de Windows PowerShell.
Como propietario de la cuenta de Azure Storage, no se le asignan automáticamente

permisos para tener acceso a datos. Antes de hacer nada significativo con AzCopy, debe
decidir cómo proporcionará las credenciales de autorización al servicio de
almacenamiento.
Autorización de AzCopy
Puede proporcionar las credenciales de autorización mediante Microsoft Entra ID o
mediante un token de firma de acceso compartido (SAS).
Opción 1: Uso de Microsoft Entra ID
Con Microsoft Entra ID, puede proporcionar credenciales una vez en lugar de anexar un
token de SAS a cada comando.
Opción 2: Uso de un token de SAS

Puede anexar un token de SAS a cada dirección URL de origen o destino que use en los
comandos de AzCopy.
El comando de este ejemplo copia recursivamente los datos desde un directorio local a
un contenedor de blobs. Un token de SAS ficticio se anexa al final de la dirección URL
del contenedor.
AzCopy
azcopy copy "C:\local\path"

"https://account.blob.core.windows.net/mycontainer1/?sv=2018-03-
28&ss=bjqt&srt=sco&sp=rwddgcup&se=2019-05-01T05:01:17Z&st=2019-04-
30T21:01:17Z&spr=https&sig=MGCXiyEzbtttkr3ewJIh2AR8KrghSy1DGM9ovN734bQF4%3D"
--recursive=true
Para más información sobre los tokens de SAS y de cómo obtener uno, consulte Uso de
firmas de acceso compartido (SAS).
７ Nota
El parámetro Se requiere transferencia segura de una cuenta de almacenamiento

determina si la conexión a una cuenta de almacenamiento está protegida con
Seguridad de la capa de transporte (TLS). Esta opción está habilitada de forma
predeterminada.
Transferencia de datos
Después de autorizar la identidad o de obtener un token de SAS, puede comenzar la
transferencia de datos.
Para obtener ejemplos de comandos, consulte cualquiera de estos artículos.
ﾉ Expandir tabla
Servicio Artículo
Azure Blob Storage Carga de archivos en Azure Blob Storage
Azure Blob Storage Descarga de blobs desde Azure Blob Storage
Azure Blob Storage Copia de blobs entre cuentas de Azure Storage
Azure Blob Storage Sincronización con Azure Blob Storage
Azure Files Transferencia de datos con AzCopy y File Storage
Amazon S3 Copia de datos de Amazon S3 a Azure Storage
Google Cloud Storage Copia de datos de Google Cloud Storage a Azure Storage (versión
preliminar)
Servicio Artículo
Almacenamiento de Transferencia de datos con AzCopy y Azure Stack Storage

Azure Stack
Obtención de ayuda sobre los comandos

Para ver una lista de los comandos, escriba azcopy -h y, a continuación, presione la
tecla ENTRAR.
Para obtener información acerca de un comando específico, basta con que incluya el
nombre del comando (por ejemplo: azcopy list -h ).
Lista de comandos
En la tabla siguiente se enumeran todos los comandos de AzCopy v10. Cada comando
está vinculado a un artículo de referencia.
ﾉ Expandir tabla
Get-Help Descripción
azcopy bench Ejecuta una prueba comparativa de rendimiento al cargar o descargar datos de
prueba hacia o desde un destino especificado.
azcopy copy Copia los datos de origen en una ubicación de destino.
azcopy doc Genera documentación para la herramienta en formato de Markdown.
azcopy env Muestra las variables de entorno que pueden configurar el comportamiento de
AzCopy.
azcopy jobs Subcomandos relacionados con la administración de trabajos.

Get-Help Descripción
azcopy jobs Elimina todos los archivos de registro y de plan de todos los trabajos.
clean
azcopy jobs list Muestra información sobre todos los trabajos.
azcopy jobs Quita todos los archivos asociados al identificador de trabajo especificado.
remove
azcopy jobs Reanuda el trabajo existente con el identificador de trabajo especificado.

resume
azcopy jobs Muestra información detallada del identificador de trabajo especificado.

show
azcopy list Enumera las entidades de un recurso determinado.
azcopy login Inicie sesión en Microsoft Entra ID para acceder a los recursos de Azure
Storage.
azcopy login Enumera las entidades de un recurso determinado.

status
azcopy logout Cierra la sesión del usuario y finaliza el acceso a los recursos de Azure Storage.
azcopy make Crea un contenedor o un recurso compartido de archivos.
azcopy remove Elimine blobs o archivos de una cuenta de almacenamiento de Azure.
azcopy sync Replica la ubicación de origen en la ubicación de destino.
azcopy set- Cambie el nivel de acceso de uno o varios blobs y reemplace (sobrescriba) los
properties metadatos y las etiquetas de índice de uno o varios blobs.
７ Nota
AzCopy no tiene un comando para cambiar el nombre de los archivos.
Uso en un script
Obtención de un vínculo de descarga estático

Con el tiempo, el vínculo de descarga de AzCopy apuntará a nuevas versiones de
AzCopy. Si el script descarga AzCopy, puede que deje de funcionar si una versión más
reciente de AzCopy modifica las características de las que depende.
Para evitar estos problemas, obtenga un vínculo estático (sin cambios) a la versión
actual de AzCopy. De este modo, el script descarga exactamente la misma versión de
AzCopy cada vez que se ejecuta.
Para obtener el vínculo, ejecute este comando:
ﾉ Expandir tabla
Sistema Get-Help
operativo
Linux curl -s -D- https://aka.ms/downloadazcopy-v10-linux \| grep ^Location
Windows (Invoke-WebRequest -Uri https://aka.ms/downloadazcopy-v10-windows -

PowerShell MaximumRedirection 0 -ErrorAction SilentlyContinue).headers.location
PowerShell 6.1+ (Invoke-WebRequest -Uri https://aka.ms/downloadazcopy-v10-windows -

MaximumRedirection 0 -ErrorAction SilentlyContinue -
SkipHttpErrorCheck).headers.location
７ Nota
Para Linux, --strip-components=1 en el comando tar elimina la carpeta de nivel

superior que contiene el nombre de la versión y, en su lugar, extrae el archivo
binario directamente en la carpeta actual. Esto permite que el script se actualice
con una nueva versión de azcopy al actualizar únicamente la dirección URL de
wget .
La dirección URL aparece en la salida de este comando. A continuación, el script puede

descargar AzCopy mediante esa dirección URL.
Linux
Bash
wget -O azcopy_v10.tar.gz https://aka.ms/downloadazcopy-v10-linux && tar -xf

azcopy_v10.tar.gz --strip-components=1
Windows PowerShell
PowerShell
Invoke-WebRequest -Uri
'https://azcopyvnext.azureedge.net/release20220315/azcopy_windows_amd64_10.1
4.1.zip' -OutFile 'azcopyv10.zip'
Expand-archive -Path '.\azcopyv10.zip' -Destinationpath '.\'
$AzCopy = (Get-ChildItem -path '.\' -Recurse -File -Filter
'azcopy.exe').FullName
# Invoke AzCopy
& $AzCopy
PowerShell 6.1+
PowerShell
Invoke-WebRequest -Uri
'https://azcopyvnext.azureedge.net/release20220315/azcopy_windows_amd64_10.1
4.1.zip' -OutFile 'azcopyv10.zip'
$AzCopy = (Expand-archive -Path '.\azcopyv10.zip' -Destinationpath '.\' -
PassThru | where-object {$_.Name -eq 'azcopy.exe'}).FullName
# Invoke AzCopy
& $AzCopy
Escape de caracteres especiales en tokens de SAS
En los archivos por lotes con la extensión .cmd , tendrá que usar una secuencia de
escape en los caracteres % que aparezcan en los tokens de SAS. Para ello, agregue un
carácter % adicional junto a los caracteres % existentes en la cadena de token de SAS. La
secuencia de caracteres resultante aparece como %% . Asegúrese de agregar un ^
adicional antes de cada carácter de & para crear la secuencia de caracteres ^& .
Ejecutar scripts mediante Jenkins

Si tiene previsto usar Jenkins para ejecutar scripts, asegúrese de colocar el siguiente
comando al principio del script.
/usr/bin/keyctl new_session
Uso en el Explorador de Azure Storage

El Explorador de Storage usa AzCopy para realizar todas sus operaciones de
transferencia de datos. Puede usar el Explorador de Storage si quiere aplicar las
ventajas de rendimiento de AzCopy pero prefiere usar una interfaz gráfica de usuario, en
lugar de la línea de comandos, para interactuar con los archivos.
El Explorador de Azure Storage utiliza la clave de la cuenta para realizar operaciones, por
lo que después de iniciar sesión en el Explorador de Azure Storage, no tendrá que
proporcionar credenciales de autorización adicionales.
Configuración, optimización y corrección

Consulte los siguientes recursos:
Parámetros de configuración de AzCopy
Optimización del rendimiento de AzCopy
Búsqueda de errores y reanudación de trabajos mediante archivos de registro y de

plan en AzCopy
Solución de problemas con AzCopy v10
Usar una versión anterior (en desuso)

Si necesita usar la versión anterior de AzCopy, consulte alguno de los vínculos
siguientes:
AzCopy en Windows (v8)
AzCopy en Linux (v7)
７ Nota
Estas versiones de AzCopy están en desuso. Microsoft recomienda usar AzCopy

v10.
Pasos siguientes
Si tiene alguna pregunta, problemas o comentarios generales, envíelos en la página
GitHub .
Transferencia de datos con AzCopy y
File Storage
Artículo • 19/12/2023
AzCopy es una utilidad de línea de comandos que puede usar para copiar archivos en
una cuenta de almacenamiento o desde esta. Este artículo contiene comandos de
ejemplo que funcionan con Azure Files.
Introducción
Vea el artículo Introducción a AzCopy para descargar AzCopy y obtener información
sobre las formas de proporcionar credenciales de autorización para el servicio de
almacenamiento.
７ Nota
Los ejemplos de este artículo muestran el uso de un token de SAS para autorizar el
acceso. Sin embargo, para los comandos que tienen como destino archivos y
directorios, ahora puede proporcionar credenciales de autorización mediante
Microsoft Entra ID y omitir el token de SAS de esos comandos. Todavía tendrá que
usar un token de SAS en cualquier comando que tenga como destino solo el
recurso compartido de archivos o la cuenta (por ejemplo, 'azcopy make
https://mystorageaccount.file.core.windows.net/myfileshare' o 'azcopy copy
'https://mystorageaccount.file.core.windows.net' .
Para más información, consulte Autorización de AzCopy.
Creación de recursos compartidos de archivos

Puede usar el comando azcopy make para crear un recurso compartido de archivos. El
ejemplo de esta sección crea un recurso compartido de archivos denominado
myfileshare .
 Sugerencia
En este ejemplo los argumentos de ruta de acceso se encierran entre comillas

simples ('). Use comillas simples en todos los shells de comandos excepto en el
shell de comandos de Windows (cmd.exe). Si usa un shell de comandos de
Windows (cmd.exe), incluya los argumentos de la ruta de acceso entre comillas
dobles ("") en lugar de comillas simples ('').
Sintaxis
azcopy make 'https://<storage-account-name>.file.core.windows.net/<file-share-name>
<SAS-token>'
Ejemplo
AzCopy
azcopy make 'https://mystorageaccount.file.core.windows.net/myfileshare?

sv=2018-03-28&ss=bjqt&srs=sco&sp=rjklhjup&se=2019-05-10T04:37:48Z&st=2019-
05-
09T20:37:48Z&spr=https&sig=/SOVEFfsKDqRry4bk3qz1vAQFwY5DDzp2%2B/3Eykf/JLs%3D
'
Para obtener documentos de referencia detallados, consulte azcopy make.
Carga de archivos
Puede usar el comando azcopy copy para cargar archivos y directorios desde el equipo
local.
 Sugerencia
En los ejemplos de esta sección se delimitan los argumentos de ruta de acceso con
comillas simples (''). Use comillas simples en todos los shells de comandos excepto
en el shell de comandos de Windows (cmd.exe). Si usa un shell de comandos de
En esta sección se incluyen los ejemplos siguientes:
＂ Cargar un archivo
＂ Subir un directorio
＂ Subir el contenido de un directorio
＂ Cargar un archivo específico
 Sugerencia
Puede modificar las operaciones de carga mediante marcas opcionales. Estos son
algunos ejemplos.
ﾉ Expandir tabla
Escenario Marca
Copiar las listas de control de acceso (ACL) junto con --preserve-smb-permissions=

los archivos. [true|false]
Copiar la información de la propiedad SMB junto con --preserve-smb-info=[true|false]

los archivos.
Para obtener una lista completa, vea las opciones.
７ Nota
AzCopy no calcula y almacena automáticamente el código hash md5 del archivo

para un archivo superior a 256 MB. Si desea que AzCopy lo haga, anexe la marca --
put-md5 a cada comando de copia. De ese modo, cuando se descarga el archivo,
AzCopy calcula un hash MD5 para los datos descargados y comprueba que el hash
MD5 almacenado en la propiedad Content-md5 del archivo coincide con el hash
calculado.
Cargar un archivo
Sintaxis
azcopy copy '<local-file-path>' 'https://<storage-account-

name>.file.core.windows.net/<file-share-name>/<file-name>'
Ejemplo
AzCopy
azcopy copy 'C:\myDirectory\myTextFile.txt'

'https://mystorageaccount.file.core.windows.net/myfileshare/myTextFile.txt?
05-
' --preserve-smb-permissions=true --preserve-smb-info=true
También puede cargar un archivo mediante un símbolo comodín (*) en cualquier lugar
de la ruta de acceso o del nombre de archivo. Por ejemplo: 'C:\myDirectory\*.txt' o
C:\my*\*.txt .
Subir un directorio
En este ejemplo se copia un directorio (y todos sus archivos) en un recurso compartido
de archivos. El resultado es un directorio en el recurso compartido de archivos con el
mismo nombre.
Sintaxis
azcopy copy '<local-directory-path>' 'https://<storage-account-

name>.file.core.windows.net/<file-share-name><SAS-token>' --recursive
Ejemplo
AzCopy
azcopy copy 'C:\myDirectory'

'https://mystorageaccount.file.core.windows.net/myfileshare?sv=2018-03-
28&ss=bjqt&srs=sco&sp=rjklhjup&se=2019-05-10T04:37:48Z&st=2019-05-
' --recursive --preserve-smb-permissions=true --preserve-smb-info=true
Para copiar un directorio dentro del recurso compartido de archivos, simplemente

especifique el nombre de ese directorio en la cadena de comandos.
Ejemplo
AzCopy

'https://mystorageaccount.file.core.windows.net/myfileshare/myFileShareDirec
tory?sv=2018-03-28&ss=bjqt&srs=sco&sp=rjklhjup&se=2019-05-
10T04:37:48Z&st=2019-05-
' --recursive --preserve-smb-permissions=true --preserve-smb-info=true
Si especifica el nombre de un directorio que no existe en el recurso compartido de

archivos, AzCopy crea un directorio con ese nombre.
Subir el contenido de un directorio

Puede cargar el contenido de un directorio sin copiar el propio directorio contenedor
mediante el carácter comodín (*).
Sintaxis
azcopy copy '<local-directory-path>/*' 'https://<storage-account-
name>.file.core.windows.net/<file-share-name>/<directory-path><SAS-token>'
Ejemplo
AzCopy
azcopy copy 'C:\myDirectory\*'

10T04:37:48Z&st=2019-05-
' --preserve-smb-permissions=true --preserve-smb-info=true
７ Nota
Anexe la marca --recursive para cargar archivos en todos los subdirectorios.
Carga de archivos específicos

Puede cargar archivos específicos mediante nombres de archivo completos, nombres
parciales con caracteres comodín (*) o fechas y horas.
Especificación de varios nombres de archivo completos

Use el comando azcopy copy con la opción --include-path . Separe los nombres de
archivo individuales mediante punto y coma ( ; ).
Sintaxis

name>.file.core.windows.net/<file-share-or-directory-name><SAS-token>' --include-
path <semicolon-separated-file-list>
Ejemplo
AzCopy
28&ss=bfqt&srt=sco&sp=rwdlacup&se=2019-07-04T05:30:08Z&st=2019-07-
03T21:30:08Z&spr=https&sig=CAfhgnc9gdGktvB=ska7bAiqIddM845yiyFwdMH481QA8%3D'
--include-path 'photos;documents\myFile.txt' --preserve-smb-permissions=true
--preserve-smb-info=true
En este ejemplo, AzCopy transfiere el directorio C:\myDirectory\photos y el archivo

C:\myDirectory\documents\myFile.txt . Debe incluir la opción --recursive para
transferir todos los archivos del directorio C:\myDirectory\photos .
También puede excluir archivos mediante la opción --exclude-path . Para más

información, consulte los documentos de referencia de azcopy copy .
Uso de caracteres comodín

Use el comando azcopy copy con la opción --include-pattern . Especifique nombres
parciales que incluyan los caracteres comodín. Separe los nombres con punto y coma
( ; ).
Sintaxis
pattern <semicolon-separated-file-list-with-wildcard-characters>
Ejemplo
AzCopy

--include-pattern 'myFile*.txt;*.pdf*' --preserve-smb-permissions=true --
preserve-smb-info=true
También puede excluir archivos mediante la opción --exclude-pattern . Para más

Las opciones --include-pattern y --exclude-pattern solo se aplican a los nombres de

archivo, no a la ruta de acceso. Si quiere copiar todos los archivos de texto que existen
en un árbol de directorios, use la opción --recursive para obtener todo el árbol de
directorios y, a continuación, use el --include-pattern y especifique *.txt para obtener
todos los archivos de texto.
Carga de archivos modificados después de una fecha y hora
Use el comando azcopy copy con la opción --include-after . Especifique una fecha y
hora en formato ISO 8601 (por ejemplo: 2020-08-19T15:04:00Z ).
Sintaxis
azcopy copy '<local-directory-path>\*' 'https://<storage-account-
after <Date-Time-in-ISO-8601-format>
Ejemplo
AzCopy
azcopy copy 'C:\myDirectory\*'

--include-after '2020-08-19T15:04:00Z' --preserve-smb-permissions=true --
Para ver una referencia detallada, consulte la documentación de referencia de azcopy

copy.
Puede usar el comando azcopy copy para descargar archivos, directorios y recursos
compartidos de archivos en la máquina local.
 Sugerencia

＂ Descarga de un archivo
＂ Descargar un directorio
＂ Descargar el contenido de un directorio
＂ Descarga de archivos específicos
 Sugerencia
Puede modificar las operaciones de descarga mediante marcas opcionales. Estos

son algunos ejemplos:
ﾉ Expandir tabla
Escenario Marca


los archivos.
Descomprimir archivos automáticamente. DECOMPRESS
７ Nota
Si el valor de la propiedad Content-md5 de un archivo contiene un hash, AzCopy

calcula un hash MD5 para los datos descargados y comprueba que el hash MD5
almacenado en la propiedad Content-md5 del archivo coincide con el hash
calculado. Si estos valores no coinciden, se produce un error en la descarga a
menos que invalide este comportamiento mediante la anexión de --check-
md5=NoCheck o --check-md5=LogOnly al comando de copia.
Sintaxis
azcopy copy 'https://<storage-account-name>.file.core.windows.net/<file-share-

name>/<file-path><SAS-token>' '<local-file-path>'
Ejemplo
AzCopy
azcopy copy
05-
' 'C:\myDirectory\myTextFile.txt' --preserve-smb-permissions=true --
Descargar un directorio
Sintaxis
name>/<directory-path><SAS-token>' '<local-directory-path>' --recursive
Ejemplo
AzCopy
azcopy copy
10T04:37:48Z&st=2019-05-
' 'C:\myDirectory' --recursive --preserve-smb-permissions=true --preserve-
smb-info=true
En este ejemplo se crea un directorio denominado

C:\myDirectory\myFileShareDirectory que contiene todos los archivos descargados.
Descargar el contenido de un directorio

Puede descargar el contenido de un directorio sin copiar el propio directorio
contenedor mediante el carácter comodín (*).
Sintaxis

name>/*<SAS-token>' '<local-directory-path>/'
Ejemplo
AzCopy
azcopy copy
tory/*?sv=2018-03-28&ss=bjqt&srs=sco&sp=rjklhjup&se=2019-05-
10T04:37:48Z&st=2019-05-
' 'C:\myDirectory' --preserve-smb-permissions=true --preserve-smb-info=true
７ Nota
Anexe la marca --recursive para descargar archivos en todos los subdirectorios.
Descarga de archivos específicos

Puede descargar archivos específicos mediante nombres de archivo completos,
nombres parciales con caracteres comodín (*) o fechas y horas.
Especificación de varios nombres de archivo completos
Use el comando azcopy copy con la opción --include-path . Separe los nombres de
archivo individuales mediante punto y coma ( ; ).
Sintaxis
azcopy copy 'https://<storage-account-name>.file.core.windows.net/<file-share-or-
directory-name><SAS-token>' '<local-directory-path>' --include-path <semicolon-

separated-file-list>
Ejemplo
AzCopy
azcopy copy
'https://mystorageaccount.file.core.windows.net/myFileShare/myDirectory?
sv=2018-03-28&ss=bfqt&srt=sco&sp=rwdlacup&se=2019-07-04T05:30:08Z&st=2019-
07-
'C:\myDirectory' --include-path 'photos;documents\myFile.txt' --recursive -
-preserve-smb-permissions=true --preserve-smb-info=true
En este ejemplo, AzCopy transfiere el directorio

https://mystorageaccount.file.core.windows.net/myFileShare/myDirectory/photos y el
archivo
https://mystorageaccount.file.core.windows.net/myFileShare/myDirectory/documents/my
File.txt . Incluya la opción --recursive para transferir todos los archivos del directorio
https://mystorageaccount.file.core.windows.net/myFileShare/myDirectory/photos .
También puede excluir archivos mediante la opción --exclude-path . Para más

Uso de caracteres comodín

Use el comando azcopy copy con la opción --include-pattern . Especifique nombres
parciales que incluyan los caracteres comodín. Separe los nombres con punto y coma
( ; ).
Sintaxis
directory-name><SAS-token>' '<local-directory-path>' --include-pattern <semicolon-
separated-file-list-with-wildcard-characters>
Ejemplo
AzCopy
azcopy copy
'https://mystorageaccount.file.core.windows.net/myfileshare/myDirectory?
07-
'C:\myDirectory' --include-pattern 'myFile*.txt;*.pdf*' --preserve-smb-
permissions=true --preserve-smb-info=true
También puede excluir archivos mediante la opción --exclude-pattern . Para más

Las opciones --include-pattern y --exclude-pattern solo se aplican a los nombres de

archivo, no a la ruta de acceso. Si quiere copiar todos los archivos de texto que existen
en un árbol de directorios, use la opción --recursive para obtener todo el árbol de
directorios y, a continuación, use el --include-pattern y especifique *.txt para obtener
todos los archivos de texto.
Descarga de archivos modificados después de una fecha y hora

Use el comando azcopy copy con la opción --include-after . Especifique una fecha y
hora en formato ISO-8601 (por ejemplo: 2020-08-19T15:04:00Z ).
Sintaxis
directory-name>/*<SAS-token>' '<local-directory-path>' --include-after <Date-Time-
in-ISO-8601-format>
Ejemplo
AzCopy
azcopy copy 'https://mystorageaccount.file.core.windows.net/myfileshare/*?

07-
'C:\myDirectory' --include-after '2020-08-19T15:04:00Z' --preserve-smb-
permissions=true --preserve-smb-info=true
Para ver una referencia detallada, consulte la documentación de referencia de azcopy

copy.
Descarga desde una instantánea de recurso compartido
Puede descargar una versión específica de un archivo o directorio haciendo referencia al

valor DateTime de una instantánea de recurso compartido. Para más información sobre
el uso compartido de instantáneas, consulte Introducción a las instantáneas de recurso
Sintaxis
name>/<file-path-or-directory-name><SAS-token>&sharesnapshot=<DateTime-of-
snapshot>' '<local-file-or-directory-path>'
Ejemplo (Descargar un archivo)
AzCopy
azcopy copy
05-
&sharesnapshot=2020-09-23T08:21:07.0000000Z' 'C:\myDirectory\myTextFile.txt'
--preserve-smb-permissions=true --preserve-smb-info=true
Ejemplo (Descargar un directorio)
AzCopy
azcopy copy
10T04:37:48Z&st=2019-05-
&sharesnapshot=2020-09-23T08:21:07.0000000Z' 'C:\myDirectory' --recursive -
-preserve-smb-permissions=true --preserve-smb-info=true
Copia de archivos entre cuentas de

almacenamiento
Puede usar AzCopy para copiar archivos a otras cuentas de almacenamiento. La
operación de copia es sincrónica, por lo que todos los archivos se copian cuando el
comando devuelve.
AzCopy usa interfaces APIde servidor a servidor, por lo que los datos se copian
directamente entre servidores de almacenamiento. Para aumentar el rendimiento de
estas operaciones puede establecer el valor de la variable de entorno
AZCOPY_CONCURRENCY_VALUE . Para más información, consulte Aumento de la
simultaneidad.
También puede copiar versiones específicas de un archivo haciendo referencia al valor

DateTime de una instantánea de recurso compartido. Para más información sobre el uso
compartido de instantáneas, consulte Introducción a las instantáneas de recurso
 Sugerencia

＂ Copia de un archivo a otra cuenta de almacenamiento
＂ Copia de un directorio a otra cuenta de almacenamiento
＂ Copia de un recurso compartido de archivos a otra cuenta de almacenamiento
＂ Copia de todos los recurso compartido de archivos, directorios y archivos a otra
 Sugerencia
Puede modificar las operaciones de copia mediante marcas opcionales. Estos son
algunos ejemplos.
ﾉ Expandir tabla
Escenario Marca


los archivos.
Copia de un archivo a otra cuenta de almacenamiento

Sintaxis
azcopy copy 'https://<source-storage-account-name>.file.core.windows.net/<file-
share-name>/<file-path><SAS-token>' 'https://<destination-storage-account-
name>.file.core.windows.net/<file-share-name>/<file-path><SAS-token>'
Ejemplo
AzCopy
azcopy copy
'https://mysourceaccount.file.core.windows.net/mycontainer/myTextFile.txt?
07-
'https://mydestinationaccount.file.core.windows.net/mycontainer/myTextFile.t
xt?sv=2018-03-28&ss=bfqt&srt=sco&sp=rwdlacup&se=2019-07-
04T05:30:08Z&st=2019-07-
Ejemplo (instantánea de recurso compartido)
AzCopy
azcopy copy
'https://mysourceaccount.file.core.windows.net/mycontainer/myTextFile.txt?
07-
03T21:30:08Z&spr=https&sig=CAfhgnc9gdGktvB=ska7bAiqIddM845yiyFwdMH481QA8%3D&
sharesnapshot=2020-09-23T08:21:07.0000000Z'
'https://mydestinationaccount.file.core.windows.net/mycontainer/myTextFile.t
xt?sv=2018-03-28&ss=bfqt&srt=sco&sp=rwdlacup&se=2019-07-
04T05:30:08Z&st=2019-07-
Copia de un directorio a otra cuenta de almacenamiento

Sintaxis

share-name>/<directory-path><SAS-token>' 'https://<destination-storage-account-
Ejemplo
AzCopy
azcopy copy
'https://mysourceaccount.file.core.windows.net/myFileShare/myFileDirectory?
07-
'https://mydestinationaccount.file.core.windows.net/mycontainer?sv=2018-03-
--recursive --preserve-smb-permissions=true --preserve-smb-info=true
AzCopy
azcopy copy
'https://mysourceaccount.file.core.windows.net/myFileShare/myFileDirectory?
07-
Copia de un recurso compartido de archivos a otra

Sintaxis

share-name><SAS-token>' 'https://<destination-storage-account-
Ejemplo
AzCopy
azcopy copy 'https://mysourceaccount.file.core.windows.net/mycontainer?

07-
03T21:30:08Z&spr=https&sig=CAfhgnc9gdGktvB=ska7bAiqIddM845yiyFwdMH481QA8%3D
AzCopy
azcopy copy 'https://mysourceaccount.file.core.windows.net/mycontainer?

07-
Copia de todos los recurso compartido de archivos,
directorios y archivos a otra cuenta de almacenamiento
Sintaxis
azcopy copy 'https://<source-storage-account-name>.file.core.windows.net/<SAS-
token>' 'https://<destination-storage-account-name>.file.core.windows.net/<SAS-
token>' --recursive'
Ejemplo
AzCopy
azcopy copy 'https://mysourceaccount.file.core.windows.net?sv=2018-03-

'https://mydestinationaccount.file.core.windows.net?sv=2018-03-
AzCopy
azcopy copy 'https://mysourceaccount.file.core.windows.net?sv=2018-03-

'https://mydestinationaccount.file.core.windows.net?sv=2018-03-
Sincronización de archivos
Puede sincronizar el contenido de un sistema de archivos local con un recurso
compartido de archivos, o bien sincronizar el contenido de un recurso compartido de
archivos con otro. También puede sincronizar el contenido de un directorio de un
recurso compartido de archivos con el contenido de un directorio que se encuentra en
otro recurso compartido de archivos. La sincronización es unidireccional. En otras
palabras, tendrá que elegir cuál de estos dos puntos de conexión es el origen y cuál es
el destino. La sincronización también usa las API de servidor a servidor.
７ Nota
Actualmente, este escenario es compatible con las cuentas que han habilitado el
espacio de nombres jerárquico a través del punto de conexión de blob.
２ Advertencia
Se admite la sincronización de AzCopy, pero no se recomienda por completo para

Azure Files. La sincronización de AzCopy no admite copias diferenciales a gran
escala y es posible que se pierda cierta fidelidad en los archivos. Para más
información, consulte Migración a recursos compartidos de archivos de Azure.
Directrices
De manera predeterminada, el comando sync compara nombres de archivo y las marcas
de tiempo de la última modificación. Puede invalidar ese comportamiento para usar
hashes MD5 en lugar de marcas de tiempo modificadas por última vez mediante la
marca --compare-hash . Establezca la marca opcional --delete-destination en un valor
de true o prompt para eliminar archivos en el directorio de destino si esos archivos ya
no existen en el directorio de origen.
Si establece la marca --delete-destination en true , AzCopy elimina los archivos

sin proporcionar un aviso. Si quiere que aparezca un mensaje antes de que AzCopy
elimine un archivo, establezca la marca --delete-destination en prompt .
Si tiene previsto establecer la marca --delete-destination en prompt o false ,

considere la posibilidad de usar el comando copy en lugar del comando sync y
establezca el parámetro --overwrite en ifSourceNewer . El comando copy
consume menos memoria y genera menos costos de facturación porque una
operación de copia no tiene que indexar el origen o el destino antes de mover
archivos.
Si no tiene previsto usar la marca --compare-hash , entonces la máquina en la que

ejecute el comando de sincronización debe tener un reloj del sistema preciso
porque las últimas horas modificadas son fundamentales para determinar si se
debe transferir un archivo. Si el sistema tiene un sesgo de reloj importante, evite
modificar los archivos en el destino demasiado cerca de la hora en que planea
ejecutar un comando de sincronización.
AzCopy usa API de servidor a servidor para sincronizar datos entre cuentas de
almacenamiento. Esto significa que los datos se copian directamente entre los
servidores de almacenamiento. Sin embargo, AzCopy configura y supervisa cada
transferencia y, para cuentas de almacenamiento más grandes (por ejemplo,
cuentas que contienen millones de blobs), AzCopy podría necesitar una cantidad
importante de recursos de proceso para realizar estas tareas. Por tanto, si ejecuta
AzCopy desde una máquina virtual (VM), asegúrese de que la máquina virtual tiene
suficientes núcleos y memoria para controlar la carga.
 Sugerencia
Puede modificar las operaciones de sincronización mediante marcas opcionales.

Estos son algunos ejemplos.
ﾉ Expandir tabla
Escenario Marca
Copiar las listas de control de acceso (ACL) junto con los --preserve-smb-
archivos. permissions=[true|false]
Copiar la información de la propiedad SMB junto con los --preserve-smb-info=

archivos. [true|false]
Excluir archivos en función de un patrón. --exclude-path
Especifique el grado de detalles que quiere que sean las --log-level=

entradas de registro relacionadas con la sincronización. [WARNING|ERROR|INFO|
NONE]
comillas simples (''). Use comillas simples en todos los shells de comandos excepto en el
shell de comandos de Windows (cmd.exe). Si usa un shell de comandos de Windows
(cmd.exe), incluya los argumentos de la ruta de acceso entre comillas dobles ("") en
lugar de comillas simples ('').
Actualización de un recurso compartido de archivos con

los cambios realizados en un sistema de archivos local
En este caso, el recurso compartido de archivos es el destino y el sistema de archivos
local es el origen.
 Sugerencia

Sintaxis
azcopy sync '<local-directory-path>' 'https://<storage-account-

Ejemplo
AzCopy
azcopy sync 'C:\myDirectory'

'https://mystorageaccount.file.core.windows.net/myfileShare?sv=2018-03-
--recursive
Actualización de un sistema de archivos local con los

cambios realizados en un recurso compartido de archivos
En este caso, el sistema de archivos local es el destino y el recurso compartido de
archivos es el origen.
 Sugerencia

Sintaxis
azcopy sync 'https://<storage-account-name>.file.core.windows.net/<file-share-name>

<SAS-token>' 'C:\myDirectory' --recursive
Ejemplo
AzCopy
azcopy sync 'https://mystorageaccount.file.core.windows.net/myfileShare?

07-
'C:\myDirectory' --recursive
Actualización de un recurso compartido de archivos con

los cambios realizados en otro recurso compartido de
archivos
El primer recurso compartido de archivos que aparece en este comando es el origen. El
segundo es el destino.
Sintaxis
azcopy sync 'https://<source-storage-account-name>.file.core.windows.net/<file-

share-name><SAS-token>' 'https://<destination-storage-account-
Ejemplo
AzCopy
azcopy sync 'https://mysourceaccount.file.core.windows.net/myfileShare?

07-
'https://mydestinationaccount.file.core.windows.net/myfileshare?sv=2018-03-
Actualización de un directorio con cambios en un

directorio de otro recurso compartido de archivos
El primer directorio que aparece en este comando es el origen. El segundo es el destino.
Sintaxis
share-name>/<directory-name><SAS-token>' 'https://<destination-storage-account-
name>.file.core.windows.net/<file-share-name>/<directory-name><SAS-token>' --
recursive
Ejemplo
AzCopy
azcopy sync
'https://mysourceaccount.file.core.windows.net/myFileShare/myDirectory?
07-
'https://mydestinationaccount.file.core.windows.net/myFileShare/myDirectory?
07-
Actualización de un recurso compartido de archivos para

que coincida con el contenido de la instantánea de un
recurso compartido
El primer recurso compartido de archivos que aparece en este comando es el origen. Al
final del identificador URI, anexe la cadena &sharesnapshot= , seguida del valor DateTime
de la instantánea.
Sintaxis

share-name><SAS-token>&sharesnapsot<snapshot-ID>' 'https://<destination-storage-
account-name>.file.core.windows.net/<file-share-name><SAS-token>' --recursive
Ejemplo
AzCopy
azcopy sync 'https://mysourceaccount.file.core.windows.net/myfileShare?

07-
sharesnapshot=2020-03-03T20%3A24%3A13.0000000Z'
'https://mydestinationaccount.file.core.windows.net/myfileshare?sv=2018-03-
Para más información sobre el uso compartido de instantáneas, consulte Introducción a

las instantáneas de recurso compartido de Azure Files.
Pasos siguientes
Puede encontrar más ejemplos en cualquiera de estos artículos:
Transferencia de datos
Consulte estos artículos para configurar opciones, optimizar el rendimiento y solucionar

problemas:
Parámetros de configuración de AzCopy

Optimización del rendimiento de AzCopy
Búsqueda de errores y reanudación de trabajos mediante archivos de registro y de
plan en AzCopy
Solución de problemas con AzCopy v10
Búsqueda de errores y reanudación de
trabajos mediante archivos de registro y
de plan en AzCopy
Artículo • 01/06/2023
AzCopy es una utilidad de línea de comandos que puede usar para copiar blobs o
archivos a una cuenta de almacenamiento o desde una cuenta de almacenamiento. En
este artículo se describe cómo usar registros para diagnosticar errores y, a continuación,
usar archivos de plan para reanudar trabajos. En este artículo también se muestra cómo
configurar archivos de registro y de plan cambiando su nivel de detalle y la ubicación
predeterminada donde se almacenan.
７ Nota
Si busca contenido que le ayude a empezar a trabajar con AzCopy, consulte

Introducción a AzCopy. Este artículo se aplica a AzCopy V10, la versión de AzCopy
admitida actualmente. Si necesita usar una versión anterior de AzCopy, consulte la
sección para usar una versión anterior de AzCopy.
Archivos de registro y de plan

AzCopy crea archivos de registro y de plan para cada trabajo. Puede usar los registros
para investigar y solucionar los posibles problemas.
Los registros contendrán el estado de error ( UPLOADFAILED , COPYFAILED y

DOWNLOADFAILED ), la ruta de acceso completa y el motivo del error.
De forma predeterminada, los archivos de registro y de plan se encuentran en el

directorio %USERPROFILE%\.azcopy de Windows o en el directorio $HOME$\.azcopy en Mac
y Linux, pero puede cambiar la ubicación.
El error pertinente no es necesariamente el primer error que aparece en el archivo. En el

caso de errores como errores de red, tiempos de espera y errores de servidor ocupado,
AzCopy volverá a intentarlo hasta 20 veces y, normalmente, el proceso de reintento se
realizará correctamente. El primer error que se ve podría ser algo inofensivo que se
reintentara correctamente. Por lo tanto, en lugar de examinar el primer error del archivo,
busque los errores cercanos UPLOADFAILED , COPYFAILED o DOWNLOADFAILED .
） Importante
Al enviar una solicitud a Soporte técnico de Microsoft (o al solucionar el problema

con la participación de terceros), comparta la versión censurada del comando que
quiere ejecutar. Esto garantiza que la SAS no se comparta de forma accidental con
nadie. Puede encontrar la versión censurada al principio del archivo de registro.
Revisión de los registros en busca errores

El comando siguiente obtiene todos los errores con el estado UPLOADFAILED del registro
04dc9ca9-158f-7945-5933-564021086c79 :
Windows (PowerShell)
Select-String UPLOADFAILED .\04dc9ca9-158f-7945-5933-564021086c79.log
Linux
grep UPLOADFAILED .\04dc9ca9-158f-7945-5933-564021086c79.log
Visualización y reanudación de trabajos

Cada operación de transferencia creará un trabajo de AzCopy. Use el comando siguiente
para ver el historial de trabajos:
azcopy jobs list
Para ver las estadísticas del trabajo, use el siguiente comando:
azcopy jobs show <job-id>
Para filtrar a las transferencias por estado, use el siguiente comando:

azcopy jobs show <job-id> --with-status=Failed
 Sugerencia
El valor de la marca --with-status distingue entre mayúsculas y minúsculas.
Use el comando siguiente para reanudar un trabajo con error o cancelado. Este
comando usa su identificador, junto con el token de SAS, ya que no es persistente por
motivos de seguridad:
azcopy jobs resume <job-id> --source-sas="<sas-token>" --destination-sas="

<sas-token>"
 Sugerencia
Encierre los argumentos de ruta de acceso, como el token de SAS, entre comillas
Al reanudar un trabajo, AzCopy examina el archivo de plan de trabajo. En el archivo de

plan se enumeran todos los archivos que se han identificado para el procesamiento al
crear el trabajo por primera vez. Al reanudar un trabajo, AzCopy intentará transferir
todos los archivos que aparecen en el archivo de plan que no se han transferido todavía.
Cambio de la ubicación de los archivos de plan

Use cualquiera de estos comandos.
Sistema operativo Get-Help
Windows PowerShell: $env:AZCOPY_JOB_PLAN_LOCATION="<value>"

En un símbolo del sistema, use: set AZCOPY_JOB_PLAN_LOCATION=<value>
Linux export AZCOPY_JOB_PLAN_LOCATION=<value>

macOS export AZCOPY_JOB_PLAN_LOCATION=<value>
Use azcopy env para comprobar el valor actual de esta variable. Si el valor está en
blanco, los registros se escriben en la ubicación predeterminada.
Cambio de la ubicación de los archivos de

registro
Use cualquiera de estos comandos.
Windows PowerShell: $env:AZCOPY_LOG_LOCATION="<value>"

En un símbolo del sistema, use: set AZCOPY_LOG_LOCATION=<value>
Linux export AZCOPY_LOG_LOCATION=<value>
macOS export AZCOPY_LOG_LOCATION=<value>
Use azcopy env para comprobar el valor actual de esta variable. Si el valor está en
blanco, los registros se escriben en la ubicación predeterminada.
Cambiar el nivel de registro predeterminado

De forma predeterminada, el nivel de registro de AzCopy se establece en INFO . Si quiere
reducir el nivel de detalle del registro para ahorrar espacio en disco, sobrescriba este
valor mediante la opción --log-level .
Los niveles de registro disponibles son: DEBUG , INFO , WARNING , ERROR , y NONE .
Eliminación de archivos de registro y de plan

Si quiere quitar todos los archivos de registro y de plan de la máquina local para ahorrar
espacio en disco, use el comando azcopy jobs clean .
Para quitar los archivos de registro y de plan asociados a un solo trabajo, use azcopy
jobs rm <job-id> . Reemplace el marcador de posición <job-id> en este ejemplo por el
identificador del trabajo.
Consulte también
Solución de problemas de Azure Files
Artículo • 11/10/2023
En este artículo se enumeran los problemas comunes relacionados con Azure Files.
También proporciona posibles causas y soluciones para estos problemas.
Si no encuentra una respuesta a su pregunta, puede ponerse en contacto con nosotros

a través de los siguientes canales (en orden de escalado):
Microsoft Q&Página de preguntas para Azure Files.

Comentarios de la comunidad de Azure .
Soporte técnico de Microsoft. Para crear una nueva solicitud de soporte técnico,
inicie sesión en el Azure Portal y, en la pestaña Ayuda, seleccione el botón Ayuda y
soporte técnico y, a continuación, seleccione Nueva solicitud de soporte técnico.
Se aplica a
Recursos compartidos de archivos estándar (GPv2), LRS/ZRS
Recursos compartidos de archivos estándar (GPv2), GRS/GZRS
Primeros pasos de solución de problemas

generales
Si tiene problemas con Azure Files, comience con los pasos siguientes.
Comprobación de la resolución dns y la conectividad con

el recurso compartido de archivos de Azure
El problema más común que encuentran los clientes Azure Files es que el montaje o el
acceso al recurso compartido de archivos de Azure produce un error debido a una
configuración de red incorrecta. Esto puede ocurrir con cualquiera de los tres protocolos
de uso compartido de archivos que Azure Files admite: SMB, NFS y FileREST.
En la tabla siguiente se proporcionan los requisitos de SMB, NFS y FileREST para cuál de
los puntos de conexión de red de una cuenta de almacenamiento pueden usar y a qué
puerto se puede acceder a ese punto de conexión. Para obtener más información sobre
los puntos de conexión de red, consulte Azure Files consideraciones sobre redes.
Nombre del Punto de conexión Punto de Punto de Puerto

protocolo público sin conexión público conexión necesario
restricciones restringido privado
SMB TCP 445
NFS TCP 2049
FileREST TCP 443

(HTTPS), TCP 80
(HTTP)
Para montar o acceder a un recurso compartido de archivos correctamente, el cliente

debe:
Puede resolver el nombre de dominio completo de la cuenta de almacenamiento

(por ejemplo, mystorageaccount.file.core.windows.net ) en la dirección IP correcta
para el punto de conexión de red deseado de la cuenta de almacenamiento.
Establezca una conexión TCP correcta a la dirección IP resuelta correctamente en el

puerto correcto para el protocolo deseado.
７ Nota
Debe usar el nombre de dominio completo (FQDN) para la cuenta de

almacenamiento al montar o acceder al recurso compartido. Los siguientes
comandos le permitirán ver las direcciones IP actuales de los puntos de conexión
de red de la cuenta de almacenamiento, pero no debe codificar de forma rígida
estas direcciones IP en scripts, configuraciones de firewall u otras ubicaciones. No
se garantiza que las direcciones IP permanezcan iguales y pueden cambiar en
cualquier momento.
Comprobación de la resolución de nombres DNS
El siguiente comando le permite probar la resolución de nombres DNS de la cuenta de

almacenamiento.
PowerShell
PowerShell
# If you have changed the DNS configuration in your environment, it may
be helpful to clear
# the DNS client cache to ensure you're getting the updated DNS name
resolution.
Clear-DnsClientCache
# Replace this value with the fully qualified domain name for your
storage account.
# Different storage accounts, especially in different Azure
environments,
# may have different suffixes than file.core.windows.net, so be sure to
use the correct
# suffix for your storage account.
$hostName = "mystorageaccount.file.core.windows.net"
# Do the name resolution. Piping to Format-List is optional.

Resolve-DnsName -Name $hostName | Format-List
La salida devuelta por Resolve-DnsName puede ser diferente en función del entorno
y de la configuración de red deseada. Por ejemplo, si está intentando acceder a un
punto de conexión público de una cuenta de almacenamiento que no tiene ningún
punto de conexión privado configurado, verá la siguiente salida. En esta salida,
x.x.x.x es la dirección IP del clúster file.phx10prdstf01a.store.core.windows.net
de la plataforma de almacenamiento de Azure que sirve a la cuenta de

almacenamiento.
Resultados
Name : mystorageaccount.file.core.windows.net
Type : CNAME
TTL : 27
Section : Answer
NameHost : file.phx10prdstf01a.store.core.windows.net
Name : file.phx10prdstf01a.store.core.windows.net
QueryType : A
TTL : 60
Section : Answer
IP4Address : x.x.x.x
Si intenta acceder al punto de conexión público de una cuenta de almacenamiento

que tiene uno o varios puntos de conexión privados configurados, verá la siguiente
salida. La salida incluye un registro CNAME adicional para
mystorageaccount.privatelink.file.core.windows.net , situado entre el FQDN
habitual de la cuenta de almacenamiento y el nombre del clúster de

almacenamiento. Esto permite la resolución de nombres a la dirección IP del punto
de conexión público cuando el usuario accede desde Internet y la resolución a la
dirección IP del punto de conexión privado cuando el usuario tiene acceso desde
dentro de una red virtual de Azure (o red emparejada).
Resultados
Type : CNAME
TTL : 60
Section : Answer
NameHost : mystorageaccount.privatelink.file.core.windows.net
Name : mystorageaccount.privatelink.file.core.windows.net
Type : CNAME
TTL : 60
Section : Answer
NameHost : file.phx10prdstf01a.store.core.windows.net
Name : file.phx10prdstf01a.store.core.windows.net
QueryType : A
TTL : 60
Section : Answer
IP4Address : x.x.x.x
Si se resuelve en un punto de conexión privado, normalmente se espera un registro

A para mystorageaccount.privatelink.file.core.windows.net que se asigne a la
dirección IP del punto de conexión privado:
Resultados
Type : CNAME
TTL : 53
Section : Answer
NameHost :
mystorageaccount.privatelink.file.core.windows.net
Name :
mystorageaccount.privatelink.file.core.windows.net
QueryType : A
TTL : 10
Section : Answer
IP4Address : 10.0.0.5
Comprobación de la conectividad TCP

El siguiente comando le permite probar la capacidad del cliente para establecer una
conexión TCP con el número de puerto o dirección IP resuelto.
PowerShell
PowerShell
# Replace this value with the fully qualified domain name for your
storage account.
# Different storage accounts, especially in different Azure
environments,
# may have different suffixes than file.core.windows.net, so be sure to
use the correct
# suffix for your storage account.
$hostName = "mystorageaccount.file.core.windows.net"
# Do the TCP connection test - see the above protocol/port table to

figure out which
# port to use for your test. This test uses port 445, the port used by
SMB.
Test-NetConnection -ComputerName $hostName -Port 445
Si la conexión se estableció correctamente, debe esperar ver el siguiente resultado:
Output
ComputerName : mystorageAccount.file.core.windows.net
RemoteAddress : x.x.x.x
RemotePort : 445
InterfaceAlias : Ethernet
SourceAddress : y.y.y.y
TcpTestSucceeded : True
Ejecución de diagnósticos
Tanto los clientes Windows como los clientes Linux pueden usar AzFileDiagnostics
para asegurarse de que el entorno de cliente tiene los requisitos previos correctos.
AzFileDiagnostics automatiza la detección de síntomas y ayuda a configurar el entorno
para obtener un rendimiento óptimo.
Áreas comunes de solución de problemas

Para obtener información más detallada, elija el área de asunto que desea solucionar.
Problemas de conectividad y acceso (SMB)
Problemas de autenticación y autorización basados en identidades (SMB)
Problemas de rendimiento (SMB/NFS)
Problemas generales en Linux (SMB)
Problemas generales en Linux (NFS)
problemas de Azure File Sync
Algunos problemas pueden estar relacionados con más de un área de asunto (por
ejemplo, conectividad y rendimiento).
¿Necesita ayuda?
Si aún necesita ayuda, póngase en contacto con el soporte técnico para resolver el
problema rápidamente.
Vea también
Ponte en contacto con nosotros para obtener

ayuda
Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo
en la comunidad de Azure. También puede enviar comentarios sobre el producto al
soporte de la comunidad de Azure.
Comentarios
¿Le ha resultado útil esta página?  Yes  No
Solución de problemas de conectividad
y acceso Azure Files (SMB)
Artículo • 20/12/2023
En este artículo se enumeran los problemas comunes que pueden producirse al intentar
conectarse a recursos compartidos de archivos de Azure del Bloque de mensajes del
servidor (SMB) desde clientes Windows o Linux y acceder a él. También proporciona
posibles causas y soluciones para estos problemas.
７ Nota
¿Le resultó útil este artículo? Su entrada es importante para nosotros. Use el botón
Comentarios de esta página para indicarnos lo bien que ha funcionado este
artículo o cómo podemos mejorarlo.
） Importante
Este artículo solo se aplica a recursos compartidos SMB. Para obtener más
información sobre los recursos compartidos del sistema de archivos de red (NFS),
consulte Solución de problemas de recursos compartidos de archivos NFS de
Azure.
Se aplica a
ﾉ Expandir tabla
No se puede conectar a un recurso compartido

de archivos de Azure ni montarlo
Seleccione la pestaña Windows o Linux en función del sistema operativo cliente que use
para acceder a recursos compartidos de archivos de Azure.
Windows
Al intentar conectarse a un recurso compartido de archivos de Azure en Windows,

es posible que reciba los siguientes mensajes de error.
Error 5 al montar un recurso compartido de archivos

de Azure
Error del sistema 5. Acceso denegado.
Causa 1: Canal de comunicación sin cifrar
Por motivos de seguridad, las conexiones a recursos compartidos de archivos de

Azure se bloquean si el canal de comunicación no está cifrado y el intento de
conexión no se realiza desde el mismo centro de datos donde residen los recursos
compartidos de archivos de Azure. Si la opción Transferencia segura necesaria está
habilitada en la cuenta de almacenamiento, también se bloquean las conexiones sin
cifrar dentro del mismo centro de datos. Solo se proporciona un canal de
comunicación cifrado si el sistema operativo cliente del usuario final admite el
cifrado SMB.
Windows 8, Windows Server 2012 y versiones posteriores de cada sistema negocian

solicitudes que incluyen SMB 3.x, que admite el cifrado.
Solución para la causa 1

1. Conéctese desde un cliente que admita el cifrado SMB (Windows 8/Windows
Server 2012 o posterior).
2. Conéctese desde una máquina virtual (VM) en el mismo centro de datos que
la cuenta de almacenamiento de Azure que se usa para el recurso compartido
3. Compruebe que la opción Transferencia segura necesaria está deshabilitada
en la cuenta de almacenamiento si el cliente no admite el cifrado SMB.
Causa 2: Las reglas de firewall o red virtual están habilitadas en

El tráfico de red se deniega si la red virtual (VNET) y las reglas de firewall están
configuradas en la cuenta de almacenamiento, a menos que la dirección IP del
cliente o la red virtual aparezcan en la lista de permitidos.

Compruebe que las reglas de red virtual y firewall están configuradas
correctamente en la cuenta de almacenamiento. Para probar si la red virtual o las
reglas de firewall están causando el problema, cambie temporalmente la
configuración de la cuenta de almacenamiento a Permitir el acceso desde todas las
redes. Para más información, consulte Configuración de firewalls y redes virtuales
de Azure Storage.
Causa 3: Los permisos de nivel de recurso compartido son

incorrectos al usar la autenticación basada en identidades
Si los usuarios acceden al recurso compartido de archivos de Azure mediante Active

Directory (AD) o Servicios de dominio de Microsoft Entra autenticación, el acceso al
recurso compartido de archivos produce un error con el error "Acceso denegado" si
los permisos de nivel de recurso compartido son incorrectos.
Valide que los permisos están configurados correctamente:
Servicios de dominio de Active Directory (AD DS) consulte Asignación de

permisos de nivel de recurso compartido.
Las asignaciones de permisos de nivel de recurso compartido son compatibles

con grupos y usuarios que se han sincronizado de AD DS con Microsoft Entra
id. mediante Microsoft Entra Connect Sync o Microsoft Entra Connect Cloud
Sync. Confirme que los grupos y los usuarios a los que se les asignan permisos
de nivel de recurso compartido no son grupos "solo en la nube" no admitidos.
Servicios de dominio de Microsoft Entra consulte Asignación de permisos de

nivel de recurso compartido.
Error 53, Error 67 o Error 87 al montar o desmontar un

Al intentar montar un recurso compartido de archivos desde el entorno local o
desde otro centro de datos, es posible que reciba los errores siguientes:
Se ha producido el error del sistema 53. No se ha encontrado la ruta de

acceso de la red.
Error del sistema 67. No se encuentra el nombre de red.
Error del sistema 87. El parámetro es incorrecto.
Causa 1: El puerto 445 está bloqueado

El error del sistema 53 o el error del sistema 67 pueden producirse si se bloquea la
comunicación saliente del puerto 445 a un centro de datos de Azure Files. Para ver
el resumen de los ISP que permiten o no permiten el acceso desde el puerto 445,
vaya a TechNet .
Para comprobar si el firewall o isp bloquea el puerto 445, use la herramienta

AzFileDiagnostics o el Test-NetConnection cmdlet .
Para usar el Test-NetConnection cmdlet, se debe instalar el módulo Azure

PowerShell. Consulte Instalar Azure PowerShell módulo para obtener más
información. No olvide reemplazar <your-storage-account-name> y <your-resource-
group-name> por los nombres pertinentes de la cuenta de almacenamiento.
Azure PowerShell
$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"
# This command requires you to be logged into your Azure account and set
the subscription your storage account is under, run:
# Connect-AzAccount -SubscriptionId 'xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx'
# if you haven't already logged in.
$storageAccount = Get-AzStorageAccount -ResourceGroupName
$resourceGroupName -Name $storageAccountName
# The ComputerName, or host, is <storage-account>.file.core.windows.net

for Azure Public Regions.
# $storageAccount.Context.FileEndpoint is used because non-Public Azure
regions, such as sovereign clouds
# or Azure Stack deployments, will have different hosts for Azure file
shares (and other storage resources).
Test-NetConnection -ComputerName
([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -Port 445
Si la conexión se realizó correctamente, debería ver la siguiente salida:

Resultados
ComputerName : <your-storage-account-name>
RemoteAddress : <storage-account-ip-address>
RemotePort : 445
InterfaceAlias : <your-network-interface>
SourceAddress : <your-ip-address>
TcpTestSucceeded : True
７ Nota
Este comando devuelve la dirección IP actual de la cuenta de almacenamiento.

No se garantiza que esta dirección IP siga siendo la misma y puede cambiar en
cualquier momento. No codifique esta dirección IP de forma rígida en ningún
script ni en una configuración de firewall.
Soluciones para la causa 1

Solución 1: use Azure File Sync como punto de conexión QUIC Puede usar Azure
File Sync como solución alternativa para acceder a Azure Files desde clientes que
tienen bloqueado el puerto 445. Aunque Azure Files no admite directamente SMB a
través de QUIC, Windows Server 2022 Azure Edition admite el protocolo QUIC.
Puede crear una caché ligera de los recursos compartidos de archivos de Azure en
una máquina virtual de Windows Server 2022 Azure Edition mediante Azure File
Sync. Esta configuración usa el puerto 443, que es de salida ampliamente abierto
para admitir HTTPS, en lugar del puerto 445. Para obtener más información sobre
esta opción, consulte SMB a través de QUIC con Azure File Sync.
Solución 2: uso de VPN o ExpressRoute Al configurar una red privada virtual (VPN)
o ExpressRoute desde el entorno local a la cuenta de almacenamiento de Azure,
con Azure Files expuestas en la red interna mediante puntos de conexión privados,
el tráfico pasará por un túnel seguro en lugar de a través de Internet. Siga las
instrucciones para configurar una VPN para acceder a Azure Files desde Windows.
Solución 3: desbloquear el puerto 445 con la ayuda del administrador de ISP/TI

Trabaje con su departamento de TI o ISP para abrir el puerto 445 de salida a los
intervalos IP de Azure .
Solución 4: use herramientas basadas en API REST como Explorador de Storage o

PowerShell Azure Files también admite REST además de SMB. El acceso REST
funciona a través del puerto 443 (tcp estándar). Hay varias herramientas que se
escriben mediante la API REST que permiten una experiencia de interfaz de usuario
enriquecida. Explorador de Storage es uno de ellos. Descargue e instale Explorador
de Storage y conéctese al recurso compartido de archivos respaldado por Azure
Files. También puede usar PowerShell que también usa la API REST.
Causa 2: NTLMv1 está habilitado

El error del sistema 53 o el error del sistema 87 pueden producirse si la
comunicación NTLMv1 está habilitada en el cliente. Azure Files solo admite la
autenticación NTLMv2. Tener NTLMv1 habilitado crea un cliente menos seguro. Por
lo tanto, la comunicación se bloquea para Azure Files.
Para determinar si esta es la causa del error, compruebe que la siguiente subclave
del Registro no está establecida en un valor menor que 3:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel
Para obtener más información, vea el tema LmCompatibilityLevel en TechNet.
Revierta el LmCompatibilityLevel valor al valor predeterminado de 3 en la siguiente

subclave del Registro:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
La aplicación o el servicio no pueden acceder a una

unidad de Azure Files montada
Causa
Las unidades se montan por usuario. Si la aplicación o el servicio se ejecutan en una
cuenta de usuario diferente a la que montó la unidad, la aplicación no verá la
unidad.
Solución
Use una de las siguientes soluciones:
Monte la unidad desde la misma cuenta de usuario que contiene la aplicación.

Puede usar una herramienta como PsExec.
Pase el nombre y la clave de la cuenta de almacenamiento en los parámetros
de nombre de usuario y contraseña del net use comando.
Use el cmdkey comando para agregar las credenciales al Administrador de

credenciales. Realice esta acción desde una línea de comandos en el contexto
de la cuenta de servicio, ya sea a través de un inicio de sesión interactivo o
mediante runas .
Consola
cmdkey /add:<storage-account-name>.file.core.windows.net
/user:AZURE\<storage-account-name> /pass:<storage-account-key>
Asigne el recurso compartido directamente sin usar una letra de unidad

asignada. Es posible que algunas aplicaciones no se vuelvan a conectar a la
letra de unidad correctamente, por lo que el uso de la ruta de acceso UNC
completa podría ser más confiable:
net use * \\storage-account-name.file.core.windows.net\share
Después de seguir estas instrucciones, es posible que reciba el siguiente mensaje

de error al ejecutar net use para la cuenta de servicio del sistema o red: "Error del
sistema 1312. No existe una sesión de inicio de sesión especificada. Es posible que
ya se haya terminado". Si aparece este error, asegúrese de que el nombre de
usuario que se pasa a net use incluye información de dominio (por ejemplo:
[storage account name].file.core.windows.net ).
Ninguna carpeta con una letra de unidad en "Mi

equipo" o "Este EQUIPO"
Si asigna un recurso compartido de archivos de Azure como administrador
mediante el net use comando , parece que falta el recurso compartido.
Causa
De forma predeterminada, Windows Explorador de archivos no se ejecuta como

administrador. Si ejecuta net use desde un símbolo del sistema administrativo,
asigne la unidad de red como administrador. Dado que las unidades asignadas
están centradas en el usuario, la cuenta de usuario que ha iniciado sesión no
muestra las unidades si están montadas en otra cuenta de usuario.
Solución
Monte el recurso compartido desde una línea de comandos que no es de
administrador. Como alternativa, puede seguir este tema de TechNet para
configurar el valor del EnableLinkedConnections Registro.
Se produce un error en el comando net use si la

cuenta de almacenamiento contiene una barra
diagonal.
Causa
El net use comando interpreta una barra diagonal (/) como una opción de línea de
comandos. Si el nombre de la cuenta de usuario comienza con una barra diagonal,
se produce un error en la asignación de unidades.
Solución
Puede usar cualquiera de los pasos siguientes para solucionar el problema:
Ejecute el siguiente comando de PowerShell:
PowerShell
New-SmbMapping -LocalPath y: -RemotePath \\server\share -UserName

accountName -Password "password can contain / and \ etc"
Desde un archivo por lotes, puede ejecutar el comando de esta manera:
Echo new-smbMapping ... | powershell -command –
Coloque comillas dobles alrededor de la clave para solucionar este problema,

a menos que la barra diagonal sea el primer carácter. Si es así, use el modo
interactivo y escriba la contraseña por separado o vuelva a generar las claves
para obtener una clave que no comience con una barra diagonal.
No se puede acceder, modificar o eliminar un

recurso compartido de archivos de Azure (o
una instantánea de recurso compartido)
Error "El nombre de usuario o la contraseña son
incorrectos" después de una conmutación por error
iniciada por el cliente
En un escenario de conmutación por error iniciado por el cliente con cuentas de
almacenamiento con redundancia geográfica, los identificadores de archivos y las
concesiones no se conservan en la conmutación por error. Los clientes deben
desmontar y volver a montar los recursos compartidos de archivos.
Error "Sin acceso" al intentar acceder a un recurso

compartido de archivos de Azure o eliminarlo
Al intentar acceder a un recurso compartido de archivos de Azure o eliminarlo mediante
el Azure Portal, es posible que reciba el siguiente error:
Sin acceso Código de error: 403
Causa 1: Las reglas de red virtual o firewall están habilitadas en la

Compruebe que las reglas de red virtual y firewall están configuradas correctamente en
la cuenta de almacenamiento. Para probar si las reglas de firewall o red virtual están
causando el problema, cambie temporalmente la configuración de la cuenta de
almacenamiento a Permitir el acceso desde todas las redes. Para más información,
consulte Configuración de firewalls y redes virtuales de Azure Storage.
Causa 2: La cuenta de usuario no tiene acceso a la cuenta de

almacenamiento
Vaya a la cuenta de almacenamiento en la que se encuentra el recurso compartido de

archivos de Azure, seleccione Control de acceso (IAM) y compruebe que la cuenta de
usuario tiene acceso a la cuenta de almacenamiento. Para más información, consulte
Protección de la cuenta de almacenamiento con el control de acceso basado en rol de
Azure (RBAC de Azure).
Bloqueos y concesiones de archivos
Si no puede modificar o eliminar un recurso compartido de archivos o una instantánea
de Azure, puede deberse a bloqueos de archivos o concesiones. Azure Files proporciona
dos maneras de evitar la modificación o eliminación accidental de recursos compartidos
de archivos de Azure e instantáneas de recursos compartidos:
Bloqueos de recursos de cuenta de almacenamiento: todos los recursos de Azure,

incluida la cuenta de almacenamiento, admiten bloqueos de recursos. Un
administrador o servicios como Azure Backup pueden poner bloqueos en la cuenta
de almacenamiento. Existen dos variaciones de bloqueos de recursos: modificar,
que impide todas las modificaciones en la cuenta de almacenamiento y sus
recursos, y eliminar, lo que solo impide eliminaciones de la cuenta de
almacenamiento y sus recursos. Al modificar o eliminar recursos compartidos a
través del Microsoft.Storage proveedor de recursos, los bloqueos de recursos se
aplican a los recursos compartidos de archivos de Azure y a las instantáneas de
recursos compartidos. La mayoría de las operaciones del portal, Azure PowerShell
cmdlets para Azure Files con Rm en el nombre (por ejemplo, Get-
AzRmStorageShare ) y los comandos de la CLI de Azure en el share-rm grupo de
comandos (por ejemplo, az storage share-rm list ) usan el proveedor de

Microsoft.Storage recursos. Algunas herramientas y utilidades, como Explorador
de Storage, los cmdlets de administración de PowerShell Azure Files heredados sin

Rm el nombre (por ejemplo, Get-AzStorageShare ) y los comandos heredados de la
CLI de Azure Files en el share grupo de comandos (por ejemplo, az storage share
list ) usan API heredadas en la API de FileREST que omiten el Microsoft.Storage
proveedor de recursos y los bloqueos de recursos. Para obtener más información

sobre las API de administración heredadas expuestas en la API de FileREST,
consulte plano de control en Azure Files.
Concesiones de instantáneas de recursos compartidos o compartidos: las

concesiones de recursos compartidos son una especie de bloqueo propietario para
los recursos compartidos de archivos de Azure y las instantáneas de recursos
compartidos de archivos. Los administradores pueden colocar concesiones en
recursos compartidos de archivos de Azure individuales o instantáneas de recursos
compartidos de archivos llamando a la API a través de un script o mediante
servicios de valor agregado, como Azure Backup. Cuando se coloca una concesión
en un recurso compartido de archivos de Azure o una instantánea de recurso
compartido de archivos, la modificación o eliminación de la instantánea de recurso
compartido de archivos o recurso compartido se puede realizar con el
identificador de concesión. Los administradores también pueden liberar la
concesión antes de las operaciones de modificación, que requiere el identificador
de concesión, o interrumpir la concesión, que no requiere el identificador de
concesión. Para obtener más información sobre las concesiones de recursos
compartidos, consulte recurso compartido de concesión.
Dado que los bloqueos y concesiones de recursos pueden interferir con las operaciones
de administrador previstas en la cuenta de almacenamiento o los recursos compartidos
de archivos de Azure, es posible que desee quitar los bloqueos o concesiones de
recursos que se hayan colocado en los recursos manualmente o automáticamente
mediante servicios de valor agregado, como Azure Backup. El siguiente script quita
todos los bloqueos y concesiones de recursos. No olvide reemplazar <resource-group> y
<storage-account> por los valores adecuados para su entorno.
Antes de ejecutar el siguiente script, debe instalar la versión más reciente del módulo
de PowerShell de Azure Storage.
） Importante
Los servicios de valor agregado que toman bloqueos de recursos y comparten

concesiones de instantáneas en los recursos de Azure Files pueden volver a aplicar
periódicamente bloqueos y concesiones. La modificación o eliminación de recursos
bloqueados por servicios de valor agregado puede afectar al funcionamiento
normal de esos servicios, como la eliminación de instantáneas de recursos
compartidos administradas por Azure Backup.
PowerShell
# Parameters for storage account resource

$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"
# Get reference to storage account

# Remove resource locks

Get-AzResourceLock `
-ResourceType "Microsoft.Storage/storageAccounts" `
-ResourceGroupName $storageAccount.ResourceGroupName `
-ResourceName $storageAccount.StorageAccountName | `
Remove-AzResourceLock -Force | `
Out-Null
# Remove share and share snapshot leases

Get-AzStorageShare -Context $storageAccount.Context | `
Where-Object { $_.Name -eq $fileShareName } | `
ForEach-Object {
try {
$leaseClient =
[Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($_.ShareClien
t)
$leaseClient.Break() | Out-Null
} catch { }
}
No se puede modificar, mover o cambiar el

nombre o eliminar un archivo o directorio
Windows
En Windows, es posible que vea los siguientes errores.
Identificadores o concesiones de archivos huérfanos

Uno de los propósitos clave de un recurso compartido de archivos es que varios
usuarios y aplicaciones pueden interactuar simultáneamente con archivos y
directorios del recurso compartido. Para ayudar con esta interacción, los recursos
compartidos de archivos proporcionan varias formas de mediar el acceso a archivos
y directorios.
Al abrir un archivo desde un recurso compartido de archivos de Azure montado a

través de SMB, el sistema operativo o la aplicación solicita un identificador de
archivo, que es una referencia al archivo. Entre otras cosas, la aplicación especifica
un modo de uso compartido de archivos cuando solicita un identificador de
archivo, que especifica el nivel de exclusividad del acceso al archivo aplicado por
Azure Files:
None : tiene acceso exclusivo.
Read : otros usuarios pueden leer el archivo mientras lo tiene abierto.
Write : otros pueden escribir en el archivo mientras lo tiene abierto.

ReadWrite : una combinación de los Read modos de uso compartido y . Write
Delete : otros usuarios pueden eliminar el archivo mientras lo tiene abierto.
Aunque como protocolo sin estado, el protocolo FileREST no tiene un concepto de

identificadores de archivo, proporciona un mecanismo similar para mediar el acceso
a archivos y carpetas que el script, la aplicación o el servicio pueden usar:
concesiones de archivos. Cuando se concede un archivo, se trata como equivalente
a un identificador de archivo con un modo de uso compartido de archivos de None .
Aunque los identificadores de archivos y las concesiones tienen un propósito

importante, a veces los identificadores de archivos y las concesiones pueden
quedar huérfanos. Cuando esto sucede, esto puede causar problemas en la
modificación o eliminación de archivos. Es posible que vea mensajes de error como:
El proceso no puede acceder al archivo porque otro proceso usa el archivo.

La acción no se puede completar porque el archivo está abierto en otro
programa.
Otro usuario bloquea el documento para su edición.
Un cliente SMB marca el recurso especificado para su eliminación.
La resolución de este problema depende de si esto se debe a un identificador de

archivo huérfano o a una concesión.
７ Nota
Las concesiones REST las usan las aplicaciones para evitar que los archivos se
eliminen o modifiquen. Antes de interrumpir las concesiones, debe identificar
qué aplicación las está adquiriendo. De lo contrario, podría interrumpir el
comportamiento de la aplicación.
Causa 1
Un identificador de archivo impide que se modifique o elimine un archivo o

directorio. Puede usar el cmdlet De PowerShell Get-AzStorageFileHandle para ver
los identificadores abiertos.
Si todos los clientes SMB han cerrado sus identificadores abiertos en un archivo o
directorio y el problema continúa ocurriendo, puede forzar el cierre de un
identificador de archivo.
Solución 1
Para forzar el cierre de un identificador de archivo, use el cmdlet Close-

AzStorageFileHandle de PowerShell.
７ Nota
Los Get-AzStorageFileHandle cmdlets y Close-AzStorageFileHandle se incluyen
en el módulo Az PowerShell versión 2.4 o posterior. Para instalar el módulo Az
PowerShell más reciente, consulte Instalación del módulo Azure PowerShell.
Causa 2
Una concesión de archivos impide que se modifique o elimine un archivo. Puede
comprobar si un archivo tiene una concesión de archivos con los siguientes
comandos de PowerShell. Reemplace <resource-group> , <storage-account> , <file-
share> y <path-to-file> por los valores adecuados para el entorno.
PowerShell
# Set variables
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"
$fileShareName = "<file-share>"
$fileForLease = "<path-to-file>"
# Get reference to storage account

# Get reference to file

$file = Get-AzStorageFile `
-Context $storageAccount.Context `
-ShareName $fileShareName `
-Path $fileForLease
$fileClient = $file.ShareFileClient
# Check if the file has a file lease

$fileClient.GetProperties().Value
Si un archivo tiene una concesión, el objeto devuelto debe contener las siguientes
propiedades:
Resultados
LeaseDuration : Infinite
LeaseState : Leased
LeaseStatus : Locked
Solución 2
Para quitar una concesión de un archivo, puede liberarla o interrumpirla. Para
liberar la concesión, necesita el Valor LeaseId de la concesión, que se establece al
crear la concesión. No necesita el Valor LeaseId para interrumpir la concesión.
En el ejemplo siguiente se muestra cómo interrumpir la concesión del archivo

indicado en la causa 2 (este ejemplo continúa con las variables de PowerShell de la
causa 2):
PowerShell
$leaseClient =
[Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($fileClie
nt)
$leaseClient.Break() | Out-Null
No se puede montar una instantánea de

recurso compartido de archivos de Azure en
Linux
"Error de montaje(22): argumento no válido" al intentar

montar una instantánea de recurso compartido de
archivos de Azure en Linux
Causa
Si la snapshot opción del mount comando no se pasa en un formato reconocido, el
mount comando puede producir un error. Para confirmarlo, compruebe los mensajes de
registro del kernel (dmesg) y dmesg mostrará una entrada de registro como cifs: Bad
value for 'snapshot' .
Solución
Asegúrese de pasar la snapshot opción del mount comando en el formato correcto.
Consulte la página manual mount.cifs (por ejemplo, man mount.cifs ). Un error común es
pasar la marca de tiempo GMT en el formato incorrecto, como usar guiones o dos
puntos en lugar de puntos. Para obtener más información, consulte Montaje de una
instantánea de recurso compartido de archivos.
"Token de instantánea incorrecto" al intentar montar una
instantánea de recurso compartido de archivos de Azure
en Linux
Causa
Si se pasa la opción de instantánea mount a partir @GMT de , pero el formato sigue siendo
incorrecto (por ejemplo, con guiones y dos puntos en lugar de puntos), el mount
comando puede producir un error.
Solución
Asegúrese de pasar la marca de tiempo GMT en el formato correcto, que es @GMT-
year.month.day-hour.minutes.seconds . Para obtener más información, consulte Montaje
de una instantánea de recurso compartido de archivos.
"Error de montaje(2): no hay ningún archivo o directorio

de este tipo" al intentar montar una instantánea del
Causa
Si la instantánea que intenta montar no existe, el mount comando puede producir este
error. Para confirmarlo, compruebe los mensajes de registro del kernel (dmesg) y dmesg
mostrará una entrada de registro como:
Resultados
[Mon Dec 12 10:34:09 2022] CIFS: Attempting to mount

\\snapshottestlinux.file.core.windows.net\snapshot-test-share1
[Mon Dec 12 10:34:09 2022] CIFS: VFS: cifs_mount failed w/return code = -2
Solución
Asegúrese de que existe la instantánea que intenta montar. Para obtener más
información sobre cómo enumerar las instantáneas disponibles para un recurso
compartido de archivos de Azure determinado, consulte Montaje de una instantánea de
Cuota de disco o errores de red de demasiados
identificadores abiertos
Windows
Error 1816: no hay suficiente cuota disponible para

procesar este comando
Causa
El error 1816 se produce cuando se alcanza el límite superior de identificadores
abiertos simultáneos permitidos para un archivo o directorio en el recurso
compartido de archivos de Azure. Para obtener más información, consulte Azure
Files destinos de escala.
Solución
Reduzca el número de identificadores abiertos simultáneos cerrando algunos

identificadores y, a continuación, vuelva a intentarlo. Para obtener más información,
consulte Microsoft Azure Storage lista de comprobación de rendimiento y
escalabilidad.
Para ver los identificadores abiertos de un recurso compartido de archivos,

directorio o archivo, use el cmdlet Get-AzStorageFileHandle de PowerShell.
Para cerrar los identificadores abiertos de un recurso compartido de archivos, un

directorio o un archivo, use el cmdlet Close-AzStorageFileHandle de PowerShell.
７ Nota
Los Get-AzStorageFileHandle cmdlets y Close-AzStorageFileHandle se incluyen

en el módulo Az PowerShell versión 2.4 o posterior. Para instalar el módulo Az
PowerShell más reciente, consulte Instalación del módulo Azure PowerShell.
ERROR_UNEXP_NET_ERR (59) al realizar operaciones
en un identificador
Causa
Si almacena en caché o mantiene un gran número de identificadores abiertos
durante mucho tiempo, es posible que vea este error en el lado servidor debido a
motivos de limitación. Cuando el cliente almacena en caché un gran número de
identificadores, muchos de ellos pueden entrar en una fase de reconexión al mismo
tiempo, creando una cola en el servidor que debe limitarse. La lógica de reintento y
la limitación en el back-end para volver a conectarse tardan más tiempo que el
tiempo de espera del cliente. Esta situación se manifiesta como un cliente que no
puede usar un identificador existente para ninguna operación, con todas las
operaciones con errores con ERROR_UNEXP_NET_ERR (59).
También hay casos perimetrales en los que el identificador de cliente se desconecta

del servidor (por ejemplo, una interrupción de red que dura varios minutos) que
podrían provocar este error.
Solución
No mantenga un gran número de identificadores almacenados en caché. Cierre los

identificadores y vuelva a intentarlo. Use Get-AzStorageFileHandle y Close-
AzStorageFileHandle los cmdlets de PowerShell para ver o cerrar identificadores
abiertos.
Error "Está copiando un archivo en un destino

que no admite el cifrado"
Cuando se copia un archivo a través de la red, el archivo se descifra en el equipo de
origen, se transmite en texto no cifrado y se vuelve a cifrar en el destino. Sin embargo,
es posible que vea el siguiente error al intentar copiar un archivo cifrado: "Está copiando
el archivo en un destino que no admite el cifrado".
Causa
Este problema puede producirse si usa El sistema de cifrado de archivos (EFS). Los
archivos cifrados con BitLocker se pueden copiar en Azure Files. Sin embargo, Azure
Files no admite NTFS EFS.
Solución alternativa
Para copiar un archivo a través de la red, primero debe descifrarlo. Utilice uno de los
métodos siguientes:
Use el comando copy /d . Permite que los archivos cifrados se guarden como
archivos descifrados en el destino.
Establezca la siguiente clave del Registro:
Ruta de acceso = HKLM\Software\Policies\Microsoft\Windows\System
Tipo de valor = DWORD
Name = CopyFileAllowDecryptedRemoteDestination
Valor = 1
Tenga en cuenta que la configuración de la clave del Registro afecta a todas las
operaciones de copia realizadas en recursos compartidos de red.
Error ConditionHeadersNotSupported desde

una aplicación web mediante Azure Files desde
el explorador
El error ConditionHeadersNotSupported se produce al acceder al contenido hospedado
en Azure Files a través de una aplicación que usa encabezados condicionales, como un
explorador web, se produce un error de acceso. El error indica que no se admiten los
encabezados de condición.
Causa
Los encabezados condicionales aún no se admiten. Las aplicaciones que las
implementan tendrán que solicitar el archivo completo cada vez que se acceda al
archivo.
Cuando se carga un nuevo archivo, la propiedad CacheControl de forma
predeterminada es no-cache. Para forzar a la aplicación a solicitar el archivo cada vez, la
propiedad CacheControl del archivo debe actualizarse de no-cache a no-cache, no-
store, must-revalidate. Esto se puede lograr mediante Explorador de Azure Storage.
Consulte también
Solución de problemas de autenticación y autorización de Azure Files (SMB)
Solución de problemas Azure Files smb generales en Linux
Solución de problemas de Azure Files NFS generales en Linux

ayuda
en la comunidad de Azure. También puede enviar comentarios sobre el producto con los
comentarios de la comunidad de Azure .
Comentarios
¿Le ha resultado útil esta página?  Sí  No
Solución de problemas de autenticación
y autorización basados en identidades
Azure Files (SMB)
Artículo • 15/12/2023
En este artículo se enumeran los problemas comunes al usar recursos compartidos de

archivos de Azure SMB con autenticación basada en identidades. También proporciona
posibles causas y soluciones para estos problemas. La autenticación basada en
identidades no se admite actualmente para recursos compartidos de archivos de Azure
NFS.
Se aplica a
ﾉ Expandir tabla
Error 5 al montar un recurso compartido de

archivos de Azure
Al intentar montar un recurso compartido de archivos, es posible que reciba el siguiente
error:
Error del sistema 5. Acceso denegado.
Causa: Los permisos de nivel de recurso compartido son

incorrectos
Si los usuarios finales acceden al recurso compartido de archivos de Azure mediante
Servicios de dominio de Active Directory (AD DS) o Servicios de dominio de Microsoft
Entra autenticación, el acceso al recurso compartido de archivos produce un error de
"Acceso denegado" si los permisos de nivel de recurso compartido son incorrectos.
７ Nota
Este error puede deberse a problemas distintos de permisos incorrectos de nivel de

recurso compartido. Para obtener información sobre otras posibles causas y
soluciones, consulte Solución de problemas de conectividad y acceso Azure Files.
Solución
Valide que los permisos están configurados correctamente:
Servicios de dominio de Active Directory (AD DS) consulte Asignación de

permisos de nivel de recurso compartido.
Las asignaciones de permisos de nivel de recurso compartido son compatibles con

grupos y usuarios que se han sincronizado de AD DS con Microsoft Entra id.
mediante Microsoft Entra Connect Sync o Microsoft Entra Connect Cloud Sync.
Confirme que los grupos y los usuarios a los que se les asignan permisos de nivel
de recurso compartido no son grupos "solo en la nube" no admitidos.
Servicios de dominio de Microsoft Entra consulte Asignación de permisos de nivel

de recurso compartido.
Error de AadDsTenantNotFound al habilitar la

autenticación de Servicios de dominio de
Microsoft Entra para Azure Files "No se pueden
encontrar inquilinos activos con el identificador
de inquilino Microsoft Entra tenant-id"
Causa
Error AadDsTenantNotFound al intentar habilitar la autenticación de Servicios de
dominio de Microsoft Entra para Azure Files en una cuenta de almacenamiento donde
no se crea Servicios de dominio de Microsoft Entra en el Microsoft Entra inquilino de la
suscripción asociada.
Solución
Habilite Servicios de dominio de Microsoft Entra en el inquilino Microsoft Entra de la
suscripción en la que se implementa la cuenta de almacenamiento. Necesita privilegios
de administrador del inquilino de Microsoft Entra para crear un dominio administrado.
Si no es el administrador del inquilino de Microsoft Entra, póngase en contacto con el
administrador y siga las instrucciones paso a paso para crear y configurar un dominio
administrado Servicios de dominio de Microsoft Entra.
No se pueden montar recursos compartidos de

archivos de Azure con credenciales de AD
Pasos de autodiagnóstico
En primer lugar, asegúrese de que ha seguido los pasos para habilitar Azure Files
autenticación de AD DS.
En segundo lugar, intente montar el recurso compartido de archivos de Azure con la

clave de cuenta de almacenamiento. Si el recurso compartido no se puede montar,
descargue AzFileDiagnostics para ayudarle a validar el entorno de ejecución del
cliente. AzFileDiagnostics puede detectar configuraciones de cliente incompatibles que
podrían provocar un error de acceso para Azure Files, proporcionar instrucciones
prescriptivas sobre la corrección automática y recopilar los seguimientos de diagnóstico.
En tercer lugar, puede ejecutar el Debug-AzStorageAccountAuth cmdlet para realizar un

conjunto de comprobaciones básicas en la configuración de AD con el usuario de AD
que ha iniciado sesión. Este cmdlet se admite en la versión posterior de AzFilesHybrid
v0.1.2+ . Debe ejecutar este cmdlet con un usuario de AD que tenga permiso de
propietario en la cuenta de almacenamiento de destino.
PowerShell

El cmdlet realiza estas comprobaciones en secuencia y proporciona instrucciones para

los errores:
1. CheckADObjectPasswordIsCorrect : asegúrese de que la contraseña configurada en

la identidad de AD que representa la cuenta de almacenamiento coincide con la de
la clave kerb1 o kerb2 de la cuenta de almacenamiento. Si la contraseña es
incorrecta, puede ejecutar Update-AzStorageAccountADObjectPassword para
restablecer la contraseña.
2. CheckADObject : confirme que hay un objeto en Active Directory que representa la
cuenta de almacenamiento y tiene el SPN correcto (nombre de entidad de
servicio). Si el SPN no está configurado correctamente, ejecute el Set-AD cmdlet
devuelto en el cmdlet de depuración para configurar el SPN.
3. CheckDomainJoined : valide que la máquina cliente está unida a un dominio a AD. Si
el equipo no está unido a un dominio a AD, consulte Unión de un equipo a un
dominio para obtener instrucciones sobre la unión a un dominio.
4. CheckPort445Connectivity : compruebe que el puerto 445 está abierto para la
conexión SMB. Si el puerto 445 no está abierto, consulte la herramienta de
solución de problemas AzFileDiagnostics para ver los problemas de conectividad
con Azure Files.
5. CheckSidHasAadUser : compruebe que el usuario de AD que ha iniciado sesión esté
sincronizado con Microsoft Entra identificador. Si desea buscar si un usuario de AD
específico está sincronizado con Microsoft Entra identificador, puede especificar y
-UserName -Domain en los parámetros de entrada. Para un SID determinado,
comprueba si hay un usuario Microsoft Entra asociado.

6. CheckAadUserHasSid : compruebe que el usuario de AD que ha iniciado sesión esté
sincronizado con Microsoft Entra identificador. Si desea buscar si un usuario de AD
específico está sincronizado con Microsoft Entra identificador, puede especificar y
-UserName -Domain en los parámetros de entrada. Para un usuario Microsoft Entra
determinado, comprueba su SID.

7. CheckGetKerberosTicket : intente obtener un vale de Kerberos para conectarse a la
cuenta de almacenamiento. Si no hay un token kerberos válido, ejecute el klist
get cifs/storage-account-name.file.core.windows.net cmdlet y examine el código
de error para determinar la causa del error de recuperación de vales.

8. CheckStorageAccountDomainJoined : compruebe si se ha habilitado la autenticación
de AD y se rellenan las propiedades de AD de la cuenta. Si no es así, habilite la
autenticación de AD DS en Azure Files.
9. CheckUserRbacAssignment : compruebe si la identidad de AD tiene la asignación de
roles RBAC adecuada para proporcionar permisos de nivel de recurso compartido
para acceder a Azure Files. Si no es así, configure el permiso de nivel de recurso
compartido. (Compatible con AzFilesHybrid v0.2.3 o versiones posteriores)
10. CheckUserFileAccess : compruebe si la identidad de AD tiene el permiso de
directorio o archivo (ACL de Windows) adecuado para acceder a Azure Files. Si no
es así, configure el permiso de nivel de directorio o archivo. (Compatible con
AzFilesHybrid v0.2.3 o versiones posteriores)
No se pueden configurar permisos de nivel de
directorio o archivo (ACL de Windows) con
Windows Explorador de archivos
Síntoma
Puede experimentar uno de los síntomas que se describen a continuación al intentar
configurar las ACL de Windows con Explorador de archivos en un recurso compartido de
archivos montado:
Después de hacer clic en Editar permiso en la pestaña Seguridad, el Asistente para

permisos no se carga.
Al intentar seleccionar un nuevo usuario o grupo, la ubicación del dominio no
muestra el dominio de AD DS correcto.
Usa varios bosques de AD y recibe el siguiente mensaje de error: "Los
controladores de dominio de Active Directory necesarios para buscar los objetos
seleccionados en los siguientes dominios no están disponibles. Asegúrese de que
los controladores de dominio de Active Directory están disponibles e intente
volver a seleccionar los objetos."
Solución
Se recomienda configurar los permisos de nivel de directorio o archivo mediante icacls
en lugar de usar Windows Explorador de archivos.
Errores al ejecutar Join-

AzStorageAccountForAuth cmdlet
Error: "El servicio de directorio no pudo asignar un

identificador relativo"
Este error podría producirse si un controlador de dominio que contiene el rol FSMO
maestro de RID no está disponible o se quitó del dominio y se restauró de la copia de
seguridad. Confirme que todos los controladores de dominio están en ejecución y
disponibles.
Error: "No se pueden enlazar parámetros posicionales
porque no se han dado nombres"
Este error probablemente se desencadene por un error de sintaxis en el Join-
AzStorageAccountforAuth comando. Compruebe si hay errores ortográficos o errores de
sintaxis en el comando y compruebe que la versión más reciente del módulo

AzFilesHybrid (https://github.com/Azure-Samples/azure-files-samples/releases ) está
instalada.
Azure Files compatibilidad local con la

autenticación de AD DS para el cifrado
Kerberos AES-256
Azure Files admite el cifrado Kerberos AES-256 para la autenticación de AD DS a partir
del módulo AzFilesHybrid v0.2.2. AES-256 es el método de cifrado recomendado y es el
método de cifrado predeterminado que comienza en el módulo AzFilesHybrid v0.2.5. Si
ha habilitado la autenticación de AD DS con una versión de módulo inferior a v0.2.2,
tendrá que descargar el módulo AzFilesHybrid más reciente y ejecutar powerShell a
continuación. Si aún no ha habilitado la autenticación de AD DS en la cuenta de
almacenamiento, siga estas instrucciones.
） Importante

para usar AES-256, debería ejecutar klist purge en el cliente y, a continuación,
volver a montar el recurso compartido de archivos para obtener nuevos vales de
Kerberos con AES-256.
PowerShell
Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -

StorageAccountName $StorageAccountName
Como parte de la actualización, el cmdlet girará las claves kerberos, lo que es necesario
para cambiar a AES-256. No es necesario volver a girar a menos que quiera volver a
generar ambas contraseñas.
La identidad de usuario que anteriormente
tenía la asignación de roles Propietario o
Colaborador sigue teniendo acceso a la clave
de la cuenta de almacenamiento
Los roles propietario y colaborador de la cuenta de almacenamiento conceden la
capacidad de enumerar las claves de la cuenta de almacenamiento. La clave de cuenta
de almacenamiento permite el acceso total a los datos de la cuenta de almacenamiento,
incluidos los recursos compartidos de archivos, los contenedores de blobs, las tablas y
las colas, y el acceso limitado a las operaciones de administración de Azure Files a través
de las API de administración heredadas expuestas a través de la API FileREST. Si va a
cambiar las asignaciones de roles, debe tener en cuenta que los usuarios que se quitan
de los roles Propietario o Colaborador pueden seguir manteniendo el acceso a la cuenta
de almacenamiento a través de claves de cuenta de almacenamiento guardadas.
Solución 1
Puede solucionar este problema fácilmente girando las claves de la cuenta de
almacenamiento. Se recomienda girar las claves de una en una, cambiando el acceso de
una a otra a medida que se giran. Hay dos tipos de claves compartidas que proporciona
la cuenta de almacenamiento: las claves de cuenta de almacenamiento, que
proporcionan acceso de superadministrador a los datos de la cuenta de
almacenamiento, y las claves Kerberos, que funcionan como un secreto compartido
entre la cuenta de almacenamiento y el controlador de dominio Windows Server Active
Directory para Windows Server Active Directory Escenarios.
Para rotar las claves Kerberos de una cuenta de almacenamiento, consulte Actualización
de la contraseña de la identidad de la cuenta de almacenamiento en AD DS.
Portal
Vaya a la cuenta de almacenamiento deseada en el Azure Portal. En la tabla de

contenido de la cuenta de almacenamiento deseada, seleccione Claves de acceso
en el encabezado Seguridad y redes . En el panel Clave de acceso , seleccione Girar
clave encima de la clave deseada.
Establecer los permisos de API en una
aplicación recién creada
Después de habilitar Microsoft Entra autenticación Kerberos, deberá conceder
explícitamente el consentimiento del administrador a la nueva aplicación Microsoft
Entra registrada en el inquilino de Microsoft Entra para completar la configuración.
Puede configurar los permisos de API desde el Azure Portal siguiendo estos pasos.
1. Abra Microsoft Entra id.
2. Seleccione Registros de aplicaciones en el panel izquierdo.
3. Seleccione Todas las aplicaciones en el panel derecho.


4. Seleccione la aplicación con el nombre coincidente [Cuenta de almacenamiento]

$storageAccountName.file.core.windows.net.
5. Seleccione Permisos de API en el panel izquierdo.
6. Seleccione Agregar permisos en la parte inferior de la página.
7. Seleccione Conceder consentimiento de administrador para "DirectoryName".
Posibles errores al habilitar Microsoft Entra

autenticación Kerberos para usuarios híbridos
Es posible que se produzcan los siguientes errores al habilitar Microsoft Entra
autenticación Kerberos para cuentas de usuario híbridas.
Error: concesión del consentimiento del administrador

deshabilitado
En algunos casos, Microsoft Entra administrador puede deshabilitar la capacidad de
conceder consentimiento al administrador para Microsoft Entra aplicaciones. A
continuación se muestra la captura de pantalla del aspecto que puede tener en la Azure
Portal.

Si este es el caso, pida al administrador de Microsoft Entra que conceda el

consentimiento del administrador a la nueva aplicación de Microsoft Entra. Para buscar y
ver los administradores, seleccione roles y administradores y, a continuación, seleccione
Administrador de aplicaciones en la nube.
Error: "Error en la solicitud a Azure AD Graph con el

código BadRequest"
Causa 1: Una directiva de administración de aplicaciones impide

que se creen credenciales
Al habilitar Microsoft Entra autenticación Kerberos, es posible que se produzca este
error si se cumplen las condiciones siguientes:
1. Usa la característica beta/preview de las directivas de administración de

aplicaciones.
2. Usted (o el administrador) ha establecido una directiva para todo el inquilino que:
No tiene ninguna fecha de inicio o tiene una fecha de inicio antes del 1 de
enero de 2019.
Establece una restricción en las contraseñas de entidad de servicio, que no
permite contraseñas personalizadas o establece una duración máxima de
contraseña de menos de 365,5 días.
Actualmente no hay ninguna solución alternativa para este error.
Causa 2: Ya existe una aplicación para la cuenta de almacenamiento

También puede encontrar este error si previamente ha habilitado Microsoft Entra
autenticación Kerberos mediante pasos de versión preliminar limitada manuales. Para
eliminar la aplicación existente, el cliente o su administrador de TI pueden ejecutar el
siguiente script. Al ejecutar este script, se quitará la antigua aplicación creada
manualmente y se permitirá que la nueva experiencia cree y administre
automáticamente la aplicación recién creada. Después de iniciar la conexión a Microsoft
Graph, inicie sesión en la aplicación Herramientas de línea de comandos de Microsoft
Graph en el dispositivo y conceda permisos a la aplicación.
PowerShell
$storageAccount = "exampleStorageAccountName"
$tenantId = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
Install-Module Microsoft.Graph
Import-Module Microsoft.Graph
Connect-MgGraph -TenantId $tenantId -Scopes
"User.Read","Application.Read.All"
$application = Get-MgApplication -Filter "DisplayName eq

'${storageAccount}'"
if ($null -ne $application) {
Remove-MgApplication -ObjectId $application.ObjectId
}
Error: la contraseña de la entidad de servicio ha expirado

en Microsoft Entra id.
Si previamente ha habilitado Microsoft Entra autenticación Kerberos mediante pasos de
versión preliminar limitada manuales, la contraseña de la entidad de servicio de la
cuenta de almacenamiento expirará cada seis meses. Una vez que expire la contraseña,
los usuarios no podrán obtener vales de Kerberos para el recurso compartido de
archivos.
Para mitigar esto, tiene dos opciones: rotar la contraseña de la entidad de servicio en
Microsoft Entra cada seis meses o seguir estos pasos para deshabilitar Microsoft Entra
Kerberos, eliminar la aplicación existente y volver a configurar Microsoft Entra Kerberos.
Asegúrese de guardar las propiedades de dominio (domainName y domainGUID) antes

de deshabilitar Microsoft Entra Kerberos, ya que las necesitará durante la
reconfiguración si desea configurar permisos de directorio y de nivel de archivo
mediante Windows Explorador de archivos. Si no guardó las propiedades de dominio,
puede configurar los permisos de nivel de directorio o archivo mediante icacls como
solución alternativa.
1. Deshabilitar Microsoft Entra Kerberos
2. Eliminación de la aplicación existente
3. Vuelva a configurar Microsoft Entra Kerberos mediante el Azure Portal
Una vez que haya vuelto a configurar Microsoft Entra Kerberos, la nueva experiencia
creará y administrará automáticamente la aplicación recién creada.
Error 1326: el nombre de usuario o la contraseña son

incorrectos al usar private link
Si se conecta a una cuenta de almacenamiento a través de un punto de conexión
privado o un vínculo privado mediante Microsoft Entra autenticación Kerberos, al
intentar montar un recurso compartido de archivos a través net use de u otro método,
se le pedirán credenciales al cliente. Es probable que el usuario escriba sus credenciales
en , pero las credenciales se rechazan.
Causa
Esto se debe a que el cliente SMB ha intentado usar Kerberos pero ha producido un
error, por lo que vuelve a usar la autenticación NTLM y Azure Files no admite el uso de
la autenticación NTLM para las credenciales de dominio. El cliente no puede obtener un
vale de Kerberos para la cuenta de almacenamiento porque el FQDN del vínculo privado
no está registrado en ninguna aplicación Microsoft Entra existente.
Solución
La solución consiste en agregar el FQDN privateLink a la aplicación Microsoft Entra de la

cuenta de almacenamiento antes de montar el recurso compartido de archivos. Puede
agregar el identificador necesarioUris al objeto de aplicación mediante el Azure Portal
siguiendo estos pasos.
1. Abra Microsoft Entra id.
2. Seleccione Registros de aplicaciones en el panel izquierdo.
3. Seleccione Todas las aplicaciones.
4. Seleccione la aplicación con el nombre coincidente [Cuenta de almacenamiento]

$storageAccountName.file.core.windows.net.
5. Seleccione Manifiesto en el panel izquierdo.
6. Copie y pegue el contenido existente para que tenga una copia duplicada.
7. Edite el manifiesto JSON. Para cada <storageAccount>.file.core.windows.net
entrada, agregue una entrada correspondiente
<storageAccount>.privatelink.file.core.windows.net . Por ejemplo, si el
manifiesto tiene el siguiente valor para identifierUris :
JSON
"identifierUris": [
"api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
"api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
"api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
"HOST/<storageaccount>.file.core.windows.net",
"CIFS/<storageaccount>.file.core.windows.net",
"HTTP/<storageaccount>.file.core.windows.net"
],
A continuación, debe editar el identifierUris campo para lo siguiente:
JSON
"identifierUris": [
"api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
"api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
"api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
"HOST/<storageaccount>.file.core.windows.net",
"CIFS/<storageaccount>.file.core.windows.net",
"HTTP/<storageaccount>.file.core.windows.net",
"api://<tenantId>/HOST/<storageaccount>.privatelink.file.core.windows.n
et",
"api://<tenantId>/CIFS/<storageaccount>.privatelink.file.core.windows.n
et",
"api://<tenantId>/HTTP/<storageaccount>.privatelink.file.core.windows.n
et",
"HOST/<storageaccount>.privatelink.file.core.windows.net",
"CIFS/<storageaccount>.privatelink.file.core.windows.net",
"HTTP/<storageaccount>.privatelink.file.core.windows.net"
],
8. Revise el contenido y seleccione Guardar para actualizar el objeto de aplicación

con el nuevo identificadorUris.
9. Actualice las referencias DNS internas para que apunten al vínculo privado.
10. Vuelva a intentar montar el recurso compartido.

Error AADSTS50105
La solicitud se interrumpió por el siguiente error AADSTS50105:
El administrador ha configurado la aplicación "Nombre de aplicación empresarial"

para bloquear a los usuarios a menos que se les conceda específicamente acceso
(asignado) a la aplicación. El usuario que ha iniciado sesión '{EmailHidden}' está
bloqueado porque no es un miembro directo de un grupo con acceso ni tiene
acceso asignado directamente por un administrador. Póngase en contacto con el
administrador para asignar acceso a esta aplicación.
Causa
Si configura "asignación necesaria" para la aplicación empresarial correspondiente, no

podrá obtener un vale de Kerberos y Microsoft Entra registros de inicio de sesión
mostrarán un error aunque los usuarios o grupos estén asignados a la aplicación.
Solución
No seleccione Asignación necesaria para Microsoft Entra aplicación para la cuenta de
almacenamiento porque no rellenamos los derechos en el vale kerberos que se
devuelve al solicitante. Para obtener más información, vea Error AADSTS50105: el
usuario que ha iniciado sesión no está asignado a un rol para la aplicación.
Consulte también
Solución de problemas de conectividad Azure Files (SMB)

ayuda
Comentarios
Solución de problemas de rendimiento
Azure Files
Artículo • 28/09/2023
En este artículo se enumeran los problemas comunes relacionados con el rendimiento

del recurso compartido de archivos de Azure y se proporcionan posibles causas y
soluciones alternativas. Para obtener el máximo valor de esta guía de solución de
problemas, se recomienda leer primero Descripción Azure Files rendimiento.
Se aplica a
Solución de problemas generales de

rendimiento
En primer lugar, descarte algunas razones comunes por las que podría tener problemas
de rendimiento.
Está ejecutando un sistema operativo antiguo.

Si la máquina virtual cliente (VM) ejecuta Windows 8.1 o Windows Server 2012 R2, o un
kernel o una distribución de Linux anterior, es posible que experimente problemas de
rendimiento al acceder a recursos compartidos de archivos de Azure. Actualice el
sistema operativo cliente o aplique las correcciones siguientes.
Windows
Consideraciones sobre Windows 8.1 y Windows Server

2012 R2
Es posible que los clientes que ejecutan Windows 8.1 o Windows Server 2012 R2
vean una latencia mayor de la esperada al acceder a recursos compartidos de
archivos de Azure para cargas de trabajo intensivas de E/S. Asegúrese de que la
revisión de KB3114025 está instalada. Esta revisión mejora el rendimiento de los
identificadores de creación y cierre.
Puede ejecutar el siguiente script para comprobar si la revisión se ha instalado:
reg query
HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies
Si la revisión está instalada, se muestra la siguiente salida:
HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Paramet
ers\Policies {96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1
７ Nota
Las imágenes de Windows Server 2012 R2 en Azure Marketplace tienen

KB3114025 de revisiones instaladas de forma predeterminada, a partir de
diciembre de 2015.
La carga de trabajo se está limitando

Las solicitudes se limitan cuando se alcanzan los límites de operaciones de E/S por
segundo (IOPS), entrada o salida de un recurso compartido de archivos. Por ejemplo, si
el cliente supera las IOPS de línea base, el servicio Azure Files lo limitará. La limitación
puede dar lugar a que el cliente experimente un rendimiento deficiente.
Para comprender los límites de los recursos compartidos de archivos estándar y

premium, consulte Destinos de escalado de archivos y recursos compartidos de
archivos. En función de la carga de trabajo, a menudo se puede evitar la limitación al
pasar de recursos compartidos de archivos de Azure estándar a premium.
Para obtener más información sobre cómo la limitación en el nivel de recurso

compartido o en la cuenta de almacenamiento puede provocar problemas de latencia
alta, bajo rendimiento y rendimiento general, consulte Uso compartido o cuenta de
almacenamiento limitada.
Latencia alta, bajo rendimiento o baja IOPS

Causa 1: Se está limitando el uso compartido o la cuenta
de almacenamiento
Para confirmar si se está limitando el recurso compartido o la cuenta de
almacenamiento, puede acceder a las métricas de Azure y usarlas en el portal. También
puede crear alertas que le notificarán si un recurso compartido se está limitando o está
a punto de limitarse. Consulte Solución de problemas de Azure Files mediante la
creación de alertas.
） Importante
En el caso de las cuentas de almacenamiento estándar con recursos compartidos

de archivos grandes (LFS) habilitados, la limitación se produce en el nivel de cuenta.
Para los recursos compartidos de archivos premium y los recursos compartidos de
archivos estándar sin LFS habilitado, la limitación se produce en el nivel de recurso
compartido.
1. En el Azure Portal, vaya a la cuenta de almacenamiento.
2. En el panel izquierdo, en Supervisión, seleccione Métricas.
3. Seleccione Archivo como espacio de nombres de métrica para el ámbito de la

4. Seleccione Transacciones como métrica.
5. Agregue un filtro para Tipo de respuesta y, a continuación, compruebe si se ha

limitado alguna solicitud.
En el caso de los recursos compartidos de archivos estándar que no tienen

recursos compartidos de archivos grandes habilitados, se registran los siguientes
tipos de respuesta si una solicitud está limitada en el nivel de recurso compartido:
En el caso de los recursos compartidos de archivos estándar que tienen recursos

compartidos de archivos grandes habilitados, se registran los siguientes tipos de
respuesta si una solicitud está limitada en el nivel de cuenta de cliente:
ClientAccountRequestThrottlingError
ClientAccountBandwidthThrottlingError
En el caso de los recursos compartidos de archivos premium, se registran los
siguientes tipos de respuesta si una solicitud está limitada en el nivel de recurso
compartido:
Si se ha autenticado una solicitud limitada con Kerberos, es posible que vea un

prefijo que indica el protocolo de autenticación, como:
KerberosSuccessWithShareEgressThrottling
KerberosSuccessWithShareIngressThrottling
Para obtener más información sobre cada tipo de respuesta, consulte Dimensiones
de métricas.
Solución
Si usa un recurso compartido de archivos estándar, habilite recursos compartidos

de archivos grandes en la cuenta de almacenamiento y aumente el tamaño de la
cuota de recursos compartidos de archivos para aprovechar la compatibilidad con
recursos compartidos de archivos de gran tamaño. Los recursos compartidos de
archivos grandes admiten excelentes límites de IOPS y ancho de banda. Consulte
Azure Files objetivos de escalabilidad y rendimiento para obtener más información.
Si usa un recurso compartido de archivos Premium, aumente el tamaño del recurso
compartido de archivos aprovisionado para aumentar el límite de IOPS. Para
obtener más información, consulte Descripción del aprovisionamiento de recursos
compartidos de archivos premium.
Causa 2: Carga de trabajo pesada de metadatos o espacio

de nombres
Si la mayoría de las solicitudes están centradas en metadatos (como createfile ,
openfile , closefile , queryinfo o querydirectory ), la latencia será peor que la de las
operaciones de lectura y escritura.
Para determinar si la mayoría de las solicitudes están centradas en metadatos, comience

siguiendo los pasos del 1 al 4, como se ha descrito anteriormente en la causa 1. En el
paso 5, en lugar de agregar un filtro para Tipo de respuesta, agregue un filtro de
propiedad para el nombre de la API.
Soluciones alternativas
Compruebe si la aplicación se puede modificar para reducir el número de

operaciones de metadatos.
Separe el recurso compartido de archivos en varios recursos compartidos de

archivos dentro de la misma cuenta de almacenamiento.
Agregue un disco duro virtual (VHD) en el recurso compartido de archivos y monte

el disco duro virtual desde el cliente para realizar operaciones de archivo en los
datos. Este enfoque funciona para escenarios o escenarios de un solo escritor o
lector con varios lectores y sin escritores. Dado que el sistema de archivos es
propiedad del cliente en lugar de Azure Files, esto permite que las operaciones de
metadatos sean locales. La configuración ofrece un rendimiento similar al del
almacenamiento conectado directamente localmente. Sin embargo, dado que los
datos están en un DISCO duro virtual, no se puede acceder a ellos a través de
ningún otro medio que no sea el montaje smb, como la API REST o a través de la
Azure Portal.
1. Desde la máquina que necesita acceder al recurso compartido de archivos de

Azure, monte el recurso compartido de archivos con la clave de cuenta de
almacenamiento y asígnelo a una unidad de red disponible (por ejemplo, Z:).
2. Vaya a Administración de discos y seleccione Action Create VHD (Crear vhd
de acción>).
3. Establezca Ubicación en la unidad de red a la que está asignado el recurso
compartido de archivos de Azure, establezca Tamaño del disco duro virtual
según sea necesario y seleccione Tamaño fijo.
4. Seleccione Aceptar. Una vez completada la creación del VHD, se montará
automáticamente y aparecerá un nuevo disco sin asignar.
5. Haga clic con el botón derecho en el nuevo disco desconocido y seleccione
Inicializar disco.
6. Haga clic con el botón derecho en el área sin asignar y cree un nuevo
volumen simple.
7. Debería ver que aparece una nueva letra de unidad en Administración de
discos que representa este VHD con acceso de lectura y escritura (por
ejemplo, E:). En Explorador de archivos, debería ver el nuevo VHD en la
unidad de red del recurso compartido de archivos de Azure asignado (Z: en
este ejemplo). Para ser claro, debe haber dos letras de unidad presentes: la
asignación de red estándar del recurso compartido de archivos de Azure en
Z:y la asignación de VHD en la unidad E:.
8. Debería haber un rendimiento mucho mejor en las operaciones de metadatos
pesadas en los archivos de la unidad asignada de VHD (E:) frente a la unidad
asignada del recurso compartido de archivos de Azure (Z:). Si lo desea, debe
ser posible desconectar la unidad de red asignada (Z:) y seguir teniendo
acceso a la unidad vhd montada (E:).
Para montar un VHD en un cliente Windows, también puede usar el Mount-

DiskImage cmdlet de PowerShell.
Para montar un disco duro virtual en Linux, consulte la documentación de la
distribución de Linux. Este es un ejemplo .
Causa 3: Aplicación de un solo subproceso

Si la aplicación que usa es de un solo subproceso, esta configuración puede dar lugar a
un rendimiento de IOPS significativamente menor que el rendimiento máximo posible,
en función del tamaño del recurso compartido aprovisionado.
Solución
Aumente el paralelismo de la aplicación aumentando el número de subprocesos.
Cambie a aplicaciones donde sea posible el paralelismo. Por ejemplo, para las
operaciones de copia, puede usar AzCopy o RoboCopy de clientes Windows o el
comando paralelo de clientes Linux.
Causa 4: El número de canales SMB supera los cuatro

Si usa SMB multicanal y el número de canales que tiene supera los cuatro, esto
provocará un rendimiento deficiente. Para determinar si el recuento de conexiones
supera los cuatro, use el cmdlet get-SmbClientConfiguration de PowerShell para ver la
configuración actual del recuento de conexiones.
Solución
Establezca la configuración de Windows por NIC para SMB para que el total de canales
no supere los cuatro. Por ejemplo, si tiene dos NIC, puede establecer el máximo por NIC
en dos mediante el siguiente cmdlet de PowerShell: Set-SmbClientConfiguration -
ConnectionCountPerRssNetworkInterface 2 .
Causa 5: El tamaño de lectura anticipada es demasiado

pequeño (solo NFS)
A partir de la versión 5.4 del kernel de Linux, el cliente NFS de Linux usa un valor
predeterminado read_ahead_kb de 128 kibibytes (KiB). Este pequeño valor podría reducir
la cantidad de rendimiento de lectura de archivos grandes.
Solución
Se recomienda aumentar el valor del parámetro kernel read_ahead_kb a 15 mebibytes
(MiB). Para cambiar este valor, establezca el tamaño de lectura anticipada de forma
persistente agregando una regla en udev, un administrador de dispositivos de kernel de
Linux. Siga estos pasos:
1. En un editor de texto, cree el archivo /etc/udev/rules.d/99-nfs.rules escribiendo y

guardando el texto siguiente:
Resultados
SUBSYSTEM=="bdi" \
, ACTION=="add" \
, PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi)
{ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
, ATTR{read_ahead_kb}="15360"
2. En una consola, aplique la regla udev ejecutando el comando udevadm como

superusuario y volviendo a cargar los archivos de reglas y otras bases de datos.
Para que udev tenga en cuenta el nuevo archivo, solo tiene que ejecutar este
comando una vez.
Bash
sudo udevadm control --reload
Latencia muy alta para las solicitudes
Causa
La máquina virtual cliente podría encontrarse en una región diferente al recurso
compartido de archivos. Otra razón para una latencia alta podría deberse a la latencia
causada por el cliente o la red.
Solución
Ejecute la aplicación desde una máquina virtual que se encuentre en la misma
región que el recurso compartido de archivos.
Para la cuenta de almacenamiento, revise las métricas de transacción
SuccessE2ELatency y SuccessServerLatency mediante Azure Monitor en Azure
Portal. Una diferencia alta entre los valores de métricas SuccessE2ELatency y
SuccessServerLatency es una indicación de latencia que probablemente se debe a
la red o al cliente. Consulte Métricas de transacciones en Azure Files Referencia de
datos de supervisión.
El cliente no puede lograr el rendimiento

máximo admitido por la red
Causa
Una posible causa es la falta de compatibilidad multicanal smb para recursos
compartidos de archivos estándar. Actualmente, Azure Files solo admite un solo canal
para recursos compartidos de archivos estándar, por lo que solo hay una conexión
desde la máquina virtual cliente al servidor. Esta única conexión se fija a un único núcleo
en la máquina virtual cliente, por lo que el rendimiento máximo posible de una máquina
virtual está enlazado por un único núcleo.
En el caso de los recursos compartidos de archivos premium, habilite SMB
multicanal.
La obtención de una máquina virtual con un núcleo más grande podría ayudar a
mejorar el rendimiento.
La ejecución de la aplicación cliente desde varias máquinas virtuales aumentará el
rendimiento.
Use las API REST siempre que sea posible.
Para los recursos compartidos de archivos de Azure NFS, nconnect está disponible.
Consulte Mejora del rendimiento del recurso compartido de archivos de Azure NFS
con nconnect.
Rendimiento lento en un recurso compartido

de archivos de Azure montado en una máquina
virtual Linux
Causa 1: Almacenamiento en caché

Una posible causa del rendimiento lento es el almacenamiento en caché deshabilitado.
El almacenamiento en caché puede ser útil si tiene acceso a un archivo repetidamente.
De lo contrario, puede ser una sobrecarga. Compruebe si usa la memoria caché antes de
deshabilitarla.

Para comprobar si el almacenamiento en caché está deshabilitado, busque la cache=
entrada.
Cache=none indica que el almacenamiento en caché está deshabilitado. Vuelva a montar
el recurso compartido mediante el comando de montaje predeterminado o agregando

explícitamente la cache=strict opción al comando mount para asegurarse de que el
modo de almacenamiento en caché predeterminado o el modo de almacenamiento en
caché "estricto" está habilitado.
En algunos escenarios, la serverino opción de montaje puede hacer que el ls

comando se ejecute stat en cada entrada de directorio. Este comportamiento produce
una degradación del rendimiento al enumerar un directorio grande. Puede comprobar
las opciones de montaje en la entrada /etc/fstab :
//azureuser.file.core.windows.net/cifs /cifs cifs

vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777
También puede comprobar si se usan las opciones correctas ejecutando el sudo mount |
grep cifs comando y comprobando su salida. A continuación se muestra una salida de
ejemplo:
Resultados
//azureuser.file.core.windows.net/cifs on /cifs type cifs

(rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,n
oforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777,
dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsiz
e=1048576,actimeo=1)
Si la cache=strict opción o serverino no está presente, vuelva a desmontar y montar

Azure Files ejecutando el comando mount desde la documentación. A continuación,
vuelva a comprobar que la entrada /etc/fstab tiene las opciones correctas.
Causa 2: Limitación
Es posible que esté experimentando una limitación y que las solicitudes se envíen a una
cola. Para comprobarlo, aproveche las métricas de Azure Storage en Azure Monitor.
También puede crear alertas que le notifiquen si un recurso compartido se está
limitando o está a punto de limitarse. Consulte Solución de problemas de Azure Files
mediante la creación de alertas.

Asegúrese de que la aplicación está dentro de los destinos de escala de Azure Files. Si
usa recursos compartidos de archivos de Azure estándar, considere la posibilidad de
cambiar a Premium.
El rendimiento en los clientes Linux es menor

que el de los clientes de Windows.
Causa
Se trata de un problema conocido con la implementación del cliente SMB en Linux.
Distribuya la carga entre varias máquinas virtuales.
En la misma máquina virtual, use varios puntos de montaje con una nosharesock
opción y distribuya la carga entre estos puntos de montaje.
En Linux, intente montar con una nostrictsync opción para evitar forzar un
vaciado smb en cada fsync llamada. Para Azure Files, esta opción no interfiere con
la coherencia de los datos, pero podría dar lugar a metadatos de archivo obsoletos
en listas de directorios ( ls -l comando). Consultar directamente los metadatos de
archivo mediante el stat comando devolverá los metadatos de archivo más
actualizados.
Latencias elevadas para cargas de trabajo con

muchos metadatos que implican amplias
operaciones abiertas o cerradas
Causa
Falta de compatibilidad con las concesiones de directorio.
Si es posible, evite usar un identificador de apertura y cierre excesivo en el mismo
directorio en un breve período de tiempo.
En el caso de las máquinas virtuales Linux, aumente el tiempo de espera de caché
de entrada de directorio especificando actimeo=<sec> como una opción de
montaje. De forma predeterminada, el tiempo de espera es de 1 segundo, por lo
que un valor mayor, como 30 segundos, podría ayudar.
En el caso de las máquinas virtuales CentOS Linux o Red Hat Enterprise Linux
(RHEL), actualice el sistema a CentOS Linux 8.2 o RHEL 8.2. Para otras
distribuciones de Linux, actualice el kernel a la versión 5.0 o posterior.
Enumeración lenta de archivos y carpetas
Causa
Este problema puede producirse si no hay suficiente memoria caché en el equipo cliente
para directorios grandes.
Solución
Para resolver este problema, ajuste el valor del Registro para permitir el
DirectoryCacheEntrySizeMax almacenamiento en caché de listas de directorios más
grandes en el equipo cliente:
Ubicación: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
Nombre del valor: DirectoryCacheEntrySizeMax
Tipo de valor: DWORD
Por ejemplo, puede establecerlo en 0x100000 y ver si el rendimiento mejora.
Copia lenta de archivos hacia y desde recursos

Es posible que vea un rendimiento lento al intentar transferir archivos al servicio de
Azure Files. Si no tiene un requisito de tamaño mínimo de E/S específico, se recomienda
usar 1 MiB como tamaño de E/S para un rendimiento óptimo.
Windows
Copia lenta de archivos hacia y desde Azure Files en

Windows
Si conoce el tamaño final de un archivo que está ampliando con escrituras y el
software no tiene problemas de compatibilidad cuando la cola no escrita del
archivo contiene ceros, establezca el tamaño del archivo de antemano en
lugar de hacer que cada escritura sea una escritura extensible.
Use el método de copia correcto:

Use AzCopy para cualquier transferencia entre dos recursos compartidos de
archivos.
Use Robocopy entre recursos compartidos de archivos en un equipo local.
Excesivas llamadas
DirectoryOpen/DirectoryClose
Causa
Si el número de llamadas DirectoryOpen/DirectoryClose se encuentra entre las
principales llamadas API y no espera que el cliente realice tantas llamadas, el problema
podría deberse al software antivirus instalado en la máquina virtual cliente de Azure.
Hay una corrección para este problema disponible en la actualización de la plataforma
de abril para Windows .
SMB multicanal no se está desencadenando
Causa
Cambios recientes en la configuración multicanal de SMB sin volver a montar.
Solución
Después de realizar cambios en la configuración multicanal del cliente SMB de
Windows o de la cuenta SMB, debe desmontar el recurso compartido, esperar 60
segundos y volver a montar el recurso compartido para desencadenar el
multicanal.
En el caso del sistema operativo cliente Windows, genere carga de E/S con una
profundidad de cola elevada, por ejemplo, QD=8, por ejemplo, copiando un
archivo para desencadenar SMB multicanal. Para el sistema operativo del servidor,
SMB multicanal se desencadena con QD=1, lo que significa que en cuanto se inicia
cualquier E/S en el recurso compartido.
Rendimiento lento al descomprimir archivos

Según el método de compresión exacto y la operación de descompresión utilizada, las
operaciones de descompresión pueden funcionar más lentamente en un recurso
compartido de archivos de Azure que en el disco local. Esto suele deberse a que las
herramientas de descompresión realizan varias operaciones de metadatos en el proceso
de realizar la descompresión de un archivo comprimido. Para obtener el mejor
rendimiento, se recomienda copiar el archivo comprimido del recurso compartido de
archivos de Azure en el disco local, descomprimirlo allí y, a continuación, usar una
herramienta de copia como Robocopy (o AzCopy) para copiar de nuevo en el recurso
compartido de archivos de Azure. El uso de una herramienta de copia como Robocopy
puede compensar el menor rendimiento de las operaciones de metadatos en Azure Files
en relación con el disco local mediante el uso de varios subprocesos para copiar datos
en paralelo.
Alta latencia en sitios web hospedados en

recursos compartidos de archivos
Causa
La notificación de cambio de archivo de número alto en los recursos compartidos de
archivos puede dar lugar a latencias altas. Esto suele ocurrir con sitios web hospedados
en recursos compartidos de archivos con una estructura de directorios anidada
profunda. Un escenario típico es la aplicación web hospedada en IIS, donde la
notificación de cambio de archivo está configurada para cada directorio en la
configuración predeterminada. Cada cambio (ReadDirectoryChangesW) en el recurso
compartido para el que está registrado el cliente inserta una notificación de cambio del
servicio de archivos al cliente, que toma los recursos del sistema, y el problema empeora
con el número de cambios. Esto puede provocar una limitación de recursos compartidos
y, por tanto, provocar una mayor latencia del lado cliente.
Para confirmarlo, puede usar métricas de Azure en el portal.

2. En el menú de la izquierda, en Supervisión, seleccione Métricas.
3. Seleccione Archivo como espacio de nombres de métrica para el ámbito de la
4. Seleccione Transacciones como métrica.
5. Agregue un filtro para ResponseType y compruebe si alguna solicitud tiene un
código de respuesta de SuccessWithThrottling (para SMB o NFS) o
ClientThrottlingError (para REST).
Solución
Si no se usa la notificación de cambio de archivo, deshabilite la notificación de
cambio de archivo (preferida).
Deshabilite la notificación de cambio de archivo actualizando FCNMode.
Actualice el intervalo de sondeo del proceso de trabajo de IIS (W3WP) a 0
estableciendo
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\Confi
gPollMilliSeconds en el Registro y reiniciando el proceso W3WP. Para obtener
información sobre esta configuración, consulte Claves comunes del Registro
que usan muchas partes de IIS.
Aumente la frecuencia del intervalo de sondeo de notificaciones de cambio de

archivo para reducir el volumen.
Actualice el intervalo de sondeo del proceso de trabajo W3WP a un valor mayor

(por ejemplo, 10 o 30 minutos) según sus necesidades. Establezca
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPo
llMilliSeconds en el registro y reinicie el proceso W3WP.
Si el directorio físico asignado del sitio web tiene una estructura de directorios
anidada, puede intentar limitar el ámbito de las notificaciones de cambio de
archivo para reducir el volumen de notificaciones. De forma predeterminada, IIS
usa la configuración de Web.config archivos en el directorio físico al que está
asignado el directorio virtual, así como en cualquier directorio secundario de ese
directorio físico. Si no desea usar Web.config archivos en directorios secundarios,
especifique false para el allowSubDirConfig atributo en el directorio virtual.
Puede encontrar más detalles aquí.
Establezca la configuración del directorio allowSubDirConfig virtual de IIS en

Web.Config para false excluir los directorios secundarios físicos asignados del
ámbito.
Vea también
Solución de problemas de Azure Files mediante la creación de alertas
Descripción del rendimiento Azure Files
Introducción a las alertas en Microsoft Azure
Preguntas más frecuentes sobre Azure Files

ayuda
Comentarios
Solución de problemas de Azure Files en
Linux (SMB)
Artículo • 23/11/2023
En este artículo se enumeran los problemas comunes que pueden producirse al usar
recursos compartidos de archivos de Azure SMB con clientes Linux. También
proporciona posibles causas y soluciones para estos problemas.
Puede usar AzFileDiagnostics para automatizar la detección de síntomas y asegurarse

de que el cliente Linux tiene los requisitos previos correctos. Ayuda a configurar el
entorno para obtener un rendimiento óptimo. También puede encontrar esta
información en el solucionador de problemas de recursos compartidos de archivos de
Azure .
） Importante
Este artículo solo se aplica a los recursos compartidos SMB. Para obtener más
información sobre los recursos compartidos de NFS, consulte Solución de
problemas de recursos compartidos de archivos de Azure de NFS.
Se aplica a
Se perdieron marcas de tiempo al copiar

archivos
En las plataformas Linux/Unix, el cp -p comando produce un error si los distintos
usuarios poseen el archivo 1 y el archivo 2.
Causa
La marca f de fuerza en COPYFILE da como resultado la ejecución cp -p -f en Unix.
Este comando también no puede conservar la marca de tiempo del archivo que no
posee.
Use el usuario de la cuenta de almacenamiento para copiar los archivos:
str_acc_name=[storage account name]
sudo useradd $str_acc_name

sudo passwd $str_acc_name
su $str_acc_name
cp -p filename.txt /share
ls: no se puede acceder a 'path>'<: error de

entrada/salida
Al intentar enumerar archivos en un recurso compartido de archivos de Azure mediante
el ls comando , el comando se bloquea al enumerar los archivos. Obtiene el siguiente
error:
ls: no se puede acceder a '<path>': error de entrada/salida
Solución
Actualice el kernel de Linux a las siguientes versiones que tengan una corrección para
este problema:
4.4.87+
4.9.48+
4.12.11+
Todas las versiones que son mayores o iguales que 4.13
No se pueden crear vínculos simbólicos: ln: no

se pudo crear el vínculo simbólico 't': operación
no admitida
Causa
De forma predeterminada, el montaje de recursos compartidos de archivos de Azure en
Linux mediante SMB no habilita la compatibilidad con vínculos simbólicos (vínculos
simbólicos). Es posible que vea un error como este:
Bash
sudo ln -s linked -n t
Resultados
ln: failed to create symbolic link 't': Operation not supported
Solución
El cliente SMB de Linux no admite la creación de vínculos simbólicos de estilo Windows
a través del protocolo SMB 2 o 3. Actualmente, el cliente Linux admite otro estilo de
vínculos simbólicos denominados vínculos simbólicos minshall+francés para las
operaciones de creación y seguimiento. Los clientes que necesiten vínculos simbólicos
pueden usar la opción de montaje "mfsymlinks". Se recomienda "mfsymlinks" porque
también es el formato que usan los Mac.
Para usar vínculos simbólicos, agregue lo siguiente al final del comando de montaje
smb:
Bash
,mfsymlinks
Por lo tanto, el comando es similar al siguiente:
Bash
sudo mount -t cifs //<storage-account-name>.file.core.windows.net/<share-

name> <mount-point> -o vers=<smb-version>,username=<storage-account-
name>,password=<storage-account-
key>,dir_mode=0777,file_mode=0777,serverino,mfsymlinks
A continuación, puede crear vínculos simbólicos como se sugiere en la wiki .
No se puede acceder a carpetas o archivos

cuyo nombre tiene un espacio o un punto al
final
No puede acceder a carpetas o archivos desde el recurso compartido de archivos de
Azure mientras se monta en Linux. Los comandos como du y ls o aplicaciones de
terceros podrían producir un error "No tal archivo o directorio" al acceder al recurso
compartido; sin embargo, puede cargar archivos en estas carpetas a través de la Azure
Portal.
Causa
Las carpetas o archivos se cargaron desde un sistema que codifica los caracteres al final
del nombre en un carácter diferente. Los archivos cargados desde un equipo Macintosh
pueden tener un carácter "0xF028" o "0xF029" en lugar de 0x20 (espacio) o 0X2E
(punto).
Solución
Use la opción mapchars en el recurso compartido al montar el recurso compartido en
Linux:
En lugar de:
Bash
sudo mount -t cifs $smbPath $mntPath -o

vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino
Use lo siguiente:
Bash
sudo mount -t cifs $smbPath $mntPath -o

vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino,
mapchars
Problemas de DNS con la migración en vivo de

cuentas de Azure Storage
Las E/S de archivo en el sistema de archivos montado comienzan a dar errores de "Host
está inactivo" o "Permiso denegado". Los registros dmesg de Linux en el cliente
muestran errores repetidos como:
Resultados
Status code returned 0xc000006d STATUS_LOGON_FAILURE

cifs_setup_session: 2 callbacks suppressed
CIFS VFS: \\contoso.file.core.windows.net Send error in SessSetup = -13
También verá que el FQDN del servidor ahora se resuelve en una dirección IP diferente a
la que está conectado actualmente.
Causa
Con fines de equilibrio de carga de capacidad, las cuentas de almacenamiento a veces
se migran en vivo de un clúster de almacenamiento a otro. La migración de cuentas
desencadena Azure Files tráfico que se redirigirá desde el clúster de origen al clúster de
destino mediante la actualización de las asignaciones DNS para que apunten al clúster
de destino. Esto bloquea todo el tráfico al clúster de origen desde esa cuenta. Se espera
que el cliente SMB tome las actualizaciones de DNS y redirija más tráfico al clúster de
destino. Sin embargo, debido a un error en el cliente de kernel SMB de Linux, esta
redirección no surte efecto. Como resultado, el tráfico de datos sigue yendo al clúster
de origen, que ha dejado de atender esta cuenta después de la migración.
Puede mitigar este problema reiniciando el sistema operativo cliente, pero podría volver
a encontrarse con el problema si no actualiza el sistema operativo cliente a una versión
de distribución de Linux con compatibilidad con la migración de cuentas. Tenga en
cuenta que es posible que umount y remount del recurso compartido parezcan corregir
el problema temporalmente.
Solución
Para una corrección permanente, actualice el sistema operativo cliente a una versión de
distribución de Linux con compatibilidad con la migración de cuentas. Se han enviado
varias correcciones para el cliente de kernel SMB de Linux al kernel principal de Linux. La
versión del kernel 5.15+ y Keyutils-1.6.2+ tienen las correcciones. Algunas distribuciones
han devuelto estas correcciones y puede comprobar si existen las siguientes
correcciones en la versión de distribución que usa:
cifs: en cifs_reconnect, vuelva a resolver el nombre de host.
cifs: use la salida de expiración de dns_query para programar la siguiente

resolución.
cifs: establezca un mínimo de 120 s para la siguiente resolución dns.
cifs: para que coincida con los servidores de archivos, asegúrese de que el nombre
de host del servidor coincida
cifs: corregir la pérdida de memoria de smb3_fs_context_dup::server_hostname
dns: aplique un TTL predeterminado a los registros obtenidos de getaddrinfo()
No se puede montar el recurso compartido de

archivos SMB cuando FIPS está habilitado
Cuando Federal Information Processing Standard (FIPS) está habilitado en una
máquina virtual Linux, no se puede montar el recurso compartido de archivos SMB. Los
registros dmesg de Linux en el cliente muestran errores como:
Resultados
kernel: CIFS: VFS: Could not allocate crypto hmac(md5)

kernel: CIFS: VFS: Error -2 during NTLMSSP authentication
kernel: CIFS: VFS: \\contoso.file.core.windows.net Send error in SessSetup =
-2
kernel: CIFS: VFS: cifs_mount failed w/return code = -2
） Importante
FIPS es un conjunto de estándares que el gobierno de Ee. UU. usa para garantizar la
seguridad y la integridad de los sistemas informáticos. Cuando un sistema está en
modo FIPS, cumple los requisitos criptográficos específicos descritos por estos
estándares.
Causa
El cliente del recurso compartido de archivos SMB usa la autenticación NTLMSSP, que
requiere el algoritmo hash MD5. Sin embargo, en el modo FIPS, el algoritmo MD5 está
restringido porque no es compatible con FIPS. MD5 es una función hash ampliamente
utilizada que genera un valor hash de 128 bits. Sin embargo, MD5 se considera inseguro
para fines criptográficos.
Cómo comprobar si el modo FIPS está habilitado

Para comprobar si el modo FIPS está habilitado en el cliente, ejecute el siguiente
comando. Si el valor se establece en 1, se habilita FIPS.
Bash
sudo cat /proc/sys/crypto/fips_enabled
Solución
Para resolver este problema, habilite la autenticación Kerberos para el recurso
compartido de archivos SMB. Si FIPS está habilitado involuntariamente, consulte option2
para deshabilitarlo.
Opción 1: Habilitar la autenticación Kerberos para el recurso compartido de archivos

SMB
Para montar un recurso compartido de archivos SMB en la máquina virtual Linux donde
FIPS está habilitado, use la autenticación Kerberos/Azure AD. Para obtener más
información, consulte Habilitación de la autenticación de Active Directory a través de
SMB para clientes Linux que acceden a Azure Files.
Opción 2: Deshabilitar FIPS para montar el recurso compartido de Samba
1. Cambie el valor sysctl de crypto.fips_enabled a 0 en /etc/sysctl.conf .
2. Modifique el GRUB_CMDLINE_LINUX_DEFAULT archivo en /etc/default/grub y quite el

parámetro fips=1 .
3. Vuelva a generar el archivo de configuración grub2 con el siguiente comando:
Bash
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
4. Vuelva a generar la imagen de initramfs con el siguiente comando:
sudo dracut -fv
5. Reinicie la máquina virtual.
Para obtener más información, consulte los siguientes documentos de distribuidores de

Linux:
RedHat: ¿Por qué habilitar el modo FIPS en los montajes CIFS de interrupción del
kernel?
SUSE: Se produce un error en el montaje CIFS "error de montaje(2): No hay ningún
archivo o directorio de este tipo"
¿Necesita ayuda?
Vea también

ayuda
Comentarios
Solución de problemas de recursos
compartidos de archivos de Azure NFS
Artículo • 26/06/2023
En este artículo se enumeran los problemas comunes relacionados con los recursos
compartidos de archivos de Azure NFS y se proporcionan posibles causas y soluciones
alternativas.
） Importante
El contenido de este artículo solo se aplica a los recursos compartidos de NFS. Para
solucionar problemas de SMB en Linux, consulte Solución de problemas de Azure
Files en Linux (SMB). Los recursos compartidos de archivos de Azure NFS no se
admiten para Windows.
Se aplica a
Error de chgrp "filename": argumento no válido

(22)
Causa 1: la asignación no está deshabilitada

Dado que Azure Files no permite el UID/GID alfanumérico, debe deshabilitar el
idmapping.
Causa 2: la asignación de identidades se deshabilitó, pero

se volvió a habilitar después de encontrar un nombre de
archivo o directorio incorrecto
Aunque deshabilite correctamente el idmapping, se puede volver a habilitar
automáticamente en algunos casos. Por ejemplo, cuando Azure Files encuentra un
nombre de archivo incorrecto, devuelve un error. Al ver este código de error, un cliente
linux NFS 4.1 decide volver a habilitar idmapping y envía solicitudes futuras con UID/GID
alfanumérico. Para obtener una lista de caracteres no admitidos en Azure Files, consulte
este artículo. Dos puntos es uno de los caracteres no admitidos.
Asegúrese de que ha deshabilitado el idmapping y de que no hay nada que lo vuelva a
habilitar. A continuación, realice los pasos siguientes:
1. Desmonte el recurso compartido.
2. Deshabilite el idmapping con:
Bash
sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
3. Vuelva a montar el recurso compartido.
4. Si ejecuta rsync, ejecute rsync con el —numeric-ids argumento de un directorio que

no tenga un nombre de archivo o directorio incorrecto.
No se puede crear un recurso compartido NFS
Causa: Configuración de la cuenta de almacenamiento no

admitida
NFS solo está disponible en cuentas de almacenamiento con la siguiente configuración:
Nivel: Premium
Tipo de cuenta: FileStorage
Regiones: lista de regiones admitidas
Solución
Siga las instrucciones de Creación de un recurso compartido NFS.
No se puede conectar a un recurso compartido
de archivos de Azure NFS ni montarlo
Causa 1: La solicitud se origina desde un cliente en una

red o dirección IP que no es de confianza
A diferencia de SMB, NFS no tiene autenticación basada en el usuario. La autenticación
de un recurso compartido se basa en la configuración de la regla de seguridad de red.
Para asegurarse de que los clientes solo establecen conexiones seguras con el recurso
compartido NFS, debe usar el punto de conexión de servicio o los puntos de conexión
privados. Para acceder a recursos compartidos desde el entorno local además de puntos
de conexión privados, debe configurar una conexión VPN o ExpressRoute. Las
direcciones IP agregadas a la lista de permitidos de la cuenta de almacenamiento para
el firewall se omiten. Debe usar uno de los métodos siguientes para configurar el acceso
a un recurso compartido NFS:
Punto de conexión de servicio
Al que accede el punto de conexión público.
Solo está disponible en la misma región.
No se puede usar el emparejamiento de red virtual para el acceso compartido.
Debe agregar cada red virtual o subred individualmente a la lista de permitidos.
Para el acceso local, puede usar puntos de conexión de servicio con

ExpressRoute, VPN de punto a sitio y de sitio a sitio. Se recomienda usar un
punto de conexión privado porque es más seguro.
En el diagrama siguiente se muestra la conectividad mediante puntos de

conexión públicos:

Punto de conexión privado
El acceso es más seguro que el punto de conexión de servicio.
El acceso al recurso compartido de NFS a través de private link está disponible

desde dentro y fuera de la región de Azure de la cuenta de almacenamiento
(entre regiones y locales).
El emparejamiento de redes virtuales con redes virtuales hospedadas en el

punto de conexión privado proporciona al recurso compartido NFS acceso a los
clientes de redes virtuales emparejadas.
Puede usar puntos de conexión privados con ExpressRoute, VPN de punto a

sitio y VPN de sitio a sitio.

Causa 2: La transferencia segura necesaria está habilitada
Los recursos compartidos de archivos de Azure NFS no admiten actualmente el cifrado
doble. Azure proporciona una capa de cifrado para todos los datos en tránsito entre
centros de datos de Azure mediante MACSec. Solo puede acceder a recursos
compartidos de NFS desde redes virtuales de confianza y a través de túneles VPN. No
hay cifrado de capa de transporte adicional disponible en recursos compartidos NFS.
Solución
Deshabilite la transferencia segura necesaria en la hoja de configuración de la cuenta
de almacenamiento.
Causa 3: el paquete nfs-utils, nfs-client o nfs-common no

está instalado
Antes de ejecutar el mount comando, instale el paquete nfs-utils, nfs-client o nfs-
common.
Para comprobar si el paquete NFS está instalado, ejecute:
RHEL
Los mismos comandos de esta sección se aplican a CentOS y Oracle Linux.
Bash
sudo rpm -qa | grep nfs-utils
Solución
Si el paquete no está instalado, instale el paquete mediante el comando específico de la
distribución.
RHEL
Los mismos comandos de esta sección se aplican a CentOS y Oracle Linux.
Versión 7.X del sistema operativo
Bash
sudo yum install nfs-utils
Versión 8.X o 9.X del sistema operativo
Bash
sudo dnf install nfs-utils
Causa 4: Puerto de bloqueo de firewall 2049

El protocolo NFS se comunica con su servidor a través del puerto 2049. Asegúrese de
que este puerto está abierto a la cuenta de almacenamiento (el servidor NFS).
Solución
Compruebe que el puerto 2049 está abierto en el cliente ejecutando el siguiente
comando. Si el puerto no está abierto, ábralo.
Bash
sudo nc -zv <storageaccountnamehere>.file.core.windows.net 2049

ls se bloquea para la enumeración de
directorios grandes en algunos kernels
Causa: se introdujo un error en el kernel de Linux v5.11 y

se corrigió en la versión 5.12.5.
Algunas versiones del kernel tienen un error que hace que las listas de directorios den
lugar a una secuencia de READDIR sin fin. Los directorios pequeños donde todas las
entradas se pueden enviar en una llamada no tienen este problema. El error se introdujo
en el kernel de Linux v5.11 y se corrigió en la versión 5.12.5. Así que cualquier cosa
intermedia tiene el error. RHEL 8.4 tiene esta versión del kernel.
Solución alternativa: Degradación o actualización del kernel

La degradación o actualización del kernel a cualquier cosa fuera del kernel afectado
debe resolver el problema.
¿Necesita ayuda?
Vea también

ayuda
Comentarios
¿Le ha resultado útil esta página? ﾂ Yes ﾄ No
Obtener ayuda en Microsoft Q&A

mediante la creación de alertas
Artículo • 26/06/2023
En este artículo se explica cómo crear y recibir alertas si un recurso compartido de

archivos de Azure se está limitando o está a punto de limitarse. Las solicitudes se limitan
cuando se alcanzan los límites de operaciones de E/S por segundo (IOPS), entrada o
salida de un recurso compartido de archivos.
） Importante
En el caso de las cuentas de almacenamiento estándar con recursos compartidos

de archivos grandes (LFS) habilitados, la limitación se produce en el nivel de cuenta.
Para los recursos compartidos de archivos premium y los recursos compartidos de
archivos estándar sin LFS habilitado, la limitación se produce en el nivel de recurso
compartido.
Se aplica a
Creación de una alerta si se está limitando un

1. Vaya a la cuenta de almacenamiento en el Azure Portal.
2. En la sección Supervisión , haga clic en Alertasy, a continuación, haga clic en +

Nueva regla de alertas.
3. Haga clic en Editar recurso, seleccione el tipo de recurso Archivo de la cuenta de

almacenamiento y, a continuación, haga clic en Listo. Por ejemplo, si el nombre de
la cuenta de almacenamiento es contoso , seleccione el contoso/file recurso.
4. Haga clic en Agregar condición para agregar una condición.
5. Verá una lista de señales admitidas para la cuenta de almacenamiento y seleccione

la métrica Transacciones .
6. En la hoja Configurar lógica de señal , haga clic en la lista desplegable Nombre de

dimensión y seleccione Tipo de respuesta.
7. Haga clic en la lista desplegable Valores de dimensión y seleccione los tipos de

respuesta adecuados para el recurso compartido de archivos.
En el caso de los recursos compartidos de archivos estándar que no tienen

recursos compartidos de archivos grandes habilitados, seleccione los siguientes
tipos de respuesta (las solicitudes están limitadas en el nivel de recurso
compartido):
En el caso de los recursos compartidos de archivos estándar que tienen recursos

compartidos de archivos grandes habilitados, seleccione los siguientes tipos de
respuesta (las solicitudes están limitadas en el nivel de cuenta de almacenamiento):
ClientAccountRequestThrottlingError
ClientAccountBandwidthThrottlingError
En el caso de los recursos compartidos de archivos premium, seleccione los

siguientes tipos de respuesta (las solicitudes están limitadas en el nivel de recurso
compartido):
７ Nota
Si los tipos de respuesta no aparecen en la lista desplegable Valores de

dimensión , esto significa que el recurso no se ha limitado. Para agregar los
valores de dimensión, junto a la lista desplegable Valores de dimensión ,
seleccione Agregar valor personalizado, escriba el tipo de respuesta (por
ejemplo, SuccessWithThrottling), seleccione Aceptar y repita estos pasos
para agregar todos los tipos de respuesta aplicables al recurso compartido de
archivos.
8. En el caso de los recursos compartidos de archivos premium, seleccione la lista

desplegable Nombre de dimensión y seleccione Recurso compartido de archivos.
En el caso de los recursos compartidos de archivos estándar, vaya al paso 10.
７ Nota
Si el recurso compartido de archivos es un recurso compartido de archivos

estándar , la dimensión Recurso compartido de archivos no enumerará los
recursos compartidos de archivos porque las métricas por recurso compartido
no están disponibles para los recursos compartidos de archivos estándar. Las
alertas de limitación de recursos compartidos de archivos estándar se
desencadenarán si se limita cualquier recurso compartido de archivos dentro
de la cuenta de almacenamiento y la alerta no identificará qué recurso
compartido de archivos se limitó. Dado que las métricas por recurso
compartido no están disponibles para los recursos compartidos de archivos
estándar, se recomienda tener solo un recurso compartido de archivos por
9. Seleccione la lista desplegable Valores de dimensión y seleccione los recursos

compartidos de archivos en los que desea alertar.
10. Defina los parámetros de alerta (valor de umbral, operador, granularidad de

agregación y frecuencia de evaluación) y seleccione Listo.
 Sugerencia

un valor de umbral razonable si el recurso compartido de archivos se está
limitando actualmente. Si usa un umbral dinámico, el gráfico de métricas
mostrará los umbrales calculados en función de los datos recientes.
11. Seleccione Agregar grupos de acciones para agregar un grupo de acciones

(correo electrónico, SMS, etc.) a la alerta, ya sea seleccionando un grupo de
acciones existente o creando un nuevo grupo de acciones.
12. Rellene los detalles de la alerta, como el nombre de la regla de alerta, la

descripción y la gravedad.
13. Seleccione Crear regla de alertas para crear la alerta.
Creación de una alerta si un recurso

compartido de archivos Premium está a punto
de limitarse
2. En la sección Supervisión , seleccione Alertas y, a continuación, seleccione Nueva

regla de alertas.
3. Seleccione Editar recurso, seleccione el tipo de recurso Archivo de la cuenta de

almacenamiento y, a continuación, seleccione Listo. Por ejemplo, si el nombre de la
cuenta de almacenamiento es contoso, seleccione el recurso contoso/file.
4. Seleccione Seleccionar condición para agregar una condición.
5. En la lista de señales que se admiten para la cuenta de almacenamiento, seleccione

la métrica Salida .
７ Nota
Debe crear tres alertas independientes para recibir alertas cuando los valores
de entrada, salida o transacción superen los umbrales establecidos. Esto se
debe a que una alerta se desencadena solo cuando se cumplen todas las
condiciones. Por ejemplo, si coloca todas las condiciones en una alerta, solo
se le avisará si la entrada, la salida y las transacciones superan sus cantidades
de umbral.
6. Desplácese hacia abajo. En la lista desplegable Nombre de dimensión , seleccione

Recurso compartido de archivos.
7. En la lista desplegable Valores de dimensión , seleccione el recurso compartido de

archivos o recursos compartidos en los que desea alertar.
8. Defina los parámetros de alerta seleccionando valores en las listas desplegables

Operador, Valor de umbral, Granularidad de agregación y Frecuencia de
evaluación y, a continuación, seleccione Listo.
Las métricas de salida, entrada y transacciones se expresan por minuto, aunque se

aprovisiona la salida, la entrada y la E/S por segundo. Por lo tanto, por ejemplo, si
la salida aprovisionada es de 90 MiB/s y desea que el umbral sea el 80 por ciento
de la salida aprovisionada, seleccione los siguientes parámetros de alerta:
Para Valor de umbral: 75497472

Para operador: mayor o igual que
Para Tipo de agregación: promedio
En función del ruido que desee que sea la alerta, también puede seleccionar
valores para Granularidad de agregación y Frecuencia de evaluación. Por ejemplo,
si desea que la alerta examine la entrada media durante el período de tiempo de 1
hora y desea que la regla de alertas se ejecute cada hora, seleccione lo siguiente:
Para granularidad de agregación: 1 hora

Para frecuencia de evaluación: 1 hora
9. Seleccione Agregar grupos de acciones y agregue un grupo de acciones (por

ejemplo, correo electrónico o SMS) a la alerta seleccionando un grupo de acciones
existente o creando uno nuevo.
10. Escriba los detalles de la alerta, como el nombre de la regla de alertas, la

descripción y la gravedad.
11. Seleccione Crear regla de alertas para crear la alerta.
７ Nota
Para recibir una notificación de que el recurso compartido de archivos

Premium está a punto de limitarse debido a la entrada aprovisionada,
siga las instrucciones anteriores, pero con el siguiente cambio:
En el paso 5, seleccione la métrica Ingress (Entrada) en lugar de
Egreso.
Para recibir una notificación de que el recurso compartido de archivos

Premium está a punto de limitarse debido a IOPS aprovisionadas, siga las
instrucciones anteriores, pero con los siguientes cambios:
En el paso 5, seleccione la métrica Transacciones en lugar de Salida.
En el paso 10, la única opción para Tipo de agregación es Total. Por
lo tanto, el valor de umbral depende de la granularidad de
agregación seleccionada. Por ejemplo, si desea que el umbral sea del
80 por ciento de las IOPS de línea base aprovisionadas y selecciona 1
hora para Granularidad de agregación, el valor umbral sería la IOPS
de línea base (en bytes) × 0,8 × 3600.
Vea también
Descripción del rendimiento Azure Files
Introducción a las alertas en Microsoft Azure

ayuda
Comentarios
¿Le ha resultado útil esta página? ﾂ Yes ﾄ No
Obtener ayuda en Microsoft Q&A

Solución de problemas al realizar copias
de seguridad de recursos compartidos
de archivos de Azure
Artículo • 14/06/2023
En este artículo se proporciona información de solución de problemas para cualquier

problema que pueda experimentar durante la configuración de la copia de seguridad o
la restauración de recursos compartidos de archivos de Azure mediante el servicio Azure
Backup.
Problemas de configuración comunes
No se pudo encontrar la cuenta de almacenamiento para

configurar la copia de seguridad para los recursos
Espere a que la detección finalice.
Compruebe si algún recurso compartido de archivos de la cuenta de

almacenamiento ya está protegido con otro almacén de Recovery Services.
７ Nota
Todos los recursos compartidos de archivos de una cuenta de

almacenamiento solo se pueden proteger en un almacén de Recovery
Services. Puede usar este script para encontrar el almacén de Recovery
Services donde está registrada la cuenta de almacenamiento.
Asegúrese de que el recurso compartido de archivos no esté presente en ninguna

de las cuentas de almacenamiento no admitidas. Puede consultar la Matriz de
compatibilidad de copia de seguridad de recursos compartidos de archivos de
Azure para encontrar las cuentas de almacenamiento admitidas.
Asegúrese de que la cuenta de almacenamiento y el almacén de Recovery Services

están presentes en la misma región.
Asegúrese de que la longitud combinada del nombre de la cuenta de

almacenamiento y el nombre del grupo de recursos no supere los 84 caracteres en
el caso de cuentas de almacenamiento nuevas y 77 caracteres en el caso de
cuentas de almacenamiento clásicas.
Compruebe la configuración del firewall de la cuenta de almacenamiento para

asegurarse de que se concede la excepción "Permitir que los servicios de Azure de
la lista de servicios de confianza accedan a esta cuenta de almacenamiento". Puede
consultar este vínculo para ver los pasos para conceder la excepción.
Error en la detección de estados del portal de las cuentas

de almacenamiento
Si tiene una suscripción de asociado (habilitada para CSP), haga caso omiso del error. Si
la suscripción no está habilitada para CSP y las cuentas de almacenamiento no se
pueden detectar, póngase en contacto con el servicio de soporte técnico.
Error de registro o validación de la cuenta de

almacenamiento seleccionada
Vuelva a intentar el registro. Si el problema persiste, póngase en contacto con el soporte
técnico.
No se pudieron mostrar ni encontrar los recursos

compartidos de archivos en la cuenta de almacenamiento
seleccionada
Asegúrese de que la cuenta de almacenamiento existe en el grupo de recursos, y
de que no se ha eliminado ni movido después de la última validación o el último
registro en el almacén.
Asegúrese de que el recurso compartido de archivos que desea proteger no se ha
eliminado.
Asegúrese de que la cuenta de almacenamiento es una cuenta de almacenamiento
admitida para la copia de seguridad de recursos compartidos de archivos. Puede
consultar la Matriz de compatibilidad de copia de seguridad de recursos
compartidos de archivos de Azure para encontrar las cuentas de almacenamiento
admitidas.
Compruebe si el recurso compartido de archivos ya está protegido en el mismo
almacén de Recovery Services.
Compruebe la configuración de enrutamiento de red de la cuenta de
almacenamiento para asegurarse de que la preferencia de enrutamiento está
establecida como enrutamiento de red de Microsoft.
Error en la configuración de copia de seguridad del
recurso compartido de archivos (o en la configuración de
la directiva de protección)
Vuelva a intentar la configuración para ver si el problema persiste.
Asegúrese de que el recurso compartido de archivos que desea proteger no se ha
eliminado.
Si está intentando proteger varios recursos compartidos de archivos a la vez, y
algunos de ellos generan error, reintente la configuración de la copia de seguridad
en los recursos compartidos de archivos que han dado error.
No se puede eliminar el almacén de Recovery Services

después de desproteger un recurso compartido de
archivos
En Azure Portal, abra Almacén>Infraestructura de Backup>Cuentas de
almacenamiento. Seleccione Anular el registro para quitar las cuentas de
almacenamiento del almacén de Recovery Services.
７ Nota
Un almacén de Recovery Services solo se puede eliminar después de anular el

registro de todas las cuentas de almacenamiento registradas en el almacén.
Errores de copia de seguridad o restauración

comunes
７ Nota
Consulte este documento para asegurarse de que dispone de los permisos

necesarios para realizar operaciones de copia de seguridad o restauración.
FileShareNotFound: no se pudo realizar la operación

porque no se encuentra el recurso compartido de
archivos
Código de error: FileShareNotFound
Mensaje de error: No se pudo realizar la operación porque no se encuentra el recurso
Asegúrese de que el recurso compartido de archivos que intenta proteger no se ha

eliminado.
UserErrorFileShareEndpointUnreachable: la cuenta de
almacenamiento no se encuentra o no se admite
Código de error: UserErrorFileShareEndpointUnreachable
Mensaje de error: La cuenta de almacenamiento no se encuentra o no se admite.
Asegúrese de que la cuenta de almacenamiento existe en el grupo de recursos y

de que no se ha eliminado o quitado del grupo de recursos tras la validación final.

admitida para la copia de seguridad de recursos compartidos de archivos.
AFSMaxSnapshotReached: ha alcanzado el límite máximo

de instantáneas para este recurso compartido de
archivos. Podrá tomar más cuando expiren las más
antiguas
Código de error: AFSMaxSnapshotReached
Mensaje de error: Ha alcanzado el límite máximo de instantáneas para este recurso

compartido de archivos. Podrá tomar más cuando expiren las más antiguas.
Este error puede producirse al crear varias copias de seguridad a petición para un
Hay un límite de 200 instantáneas por recurso compartido de archivos, incluidas
las realizadas por Azure Backup. Las copias de seguridad programadas antiguas (o
instantáneas) se borran automáticamente. Las copias de seguridad a petición (o
instantáneas) deben eliminarse si se alcanza el límite máximo.
Elimine las copias de seguridad a petición (instantáneas de recurso compartido de

archivos de Azure) desde el portal de Azure Files.
７ Nota
Si elimina las instantáneas creadas por Azure Backup, perderá los puntos de
recuperación.
UserErrorStorageAccountNotFound: no se pudo realizar

la operación porque la cuenta de almacenamiento
especificada ya no existe
Código de error: UserErrorStorageAccountNotFound
Mensaje de error: No se pudo realizar la operación porque la cuenta de almacenamiento

especificada ya no existe.
Asegúrese de que la cuenta de almacenamiento todavía existe y no se ha eliminado.
UserErrorDTSStorageAccountNotFound: los detalles de la

cuenta de almacenamiento proporcionados son
incorrectos
Código de error: UserErrorDTSStorageAccountNotFound
Mensaje de error: Los detalles de cuenta de almacenamiento proporcionados son

incorrectos.
Asegúrese de que la cuenta de almacenamiento todavía existe y no se ha eliminado.
UserErrorResourceGroupNotFound: el grupo de recursos

no existe
Código de error: UserErrorResourceGroupNotFound
Mensaje de error: El grupo de recursos no existe.
Seleccione un grupo de recursos existente o cree uno nuevo.
ParallelSnapshotRequest: ya hay un trabajo de copia de

seguridad en curso para el recurso compartido de
archivos
Código de error: ParallelSnapshotRequest
Mensaje de error: Ya hay un trabajo de copia de seguridad en curso para el recurso
La copia de seguridad del recurso compartido de archivos no admite solicitudes de

instantáneas paralelas en el mismo recurso compartido de archivos.
Espere a que el trabajo de copia de seguridad existente finalice e inténtelo de

nuevo. Si no encuentra un trabajo de copia de seguridad en el almacén de
Recovery Services, compruebe otros almacenes de Recovery Services de la misma
suscripción.
UserErrorStorageAccountInternetRoutingNotSupported:
Azure Backup no admite las cuentas de almacenamiento
con configuración de enrutamiento de Internet
Código de error: UserErrorStorageAccountInternetRoutingNotSupported
Mensaje de error: Azure Backup no admite las cuentas de almacenamiento con

configuración de enrutamiento de Internet
Asegúrese de que la preferencia de enrutamiento establecida para la cuenta de

almacenamiento que hospeda el recurso compartido de archivos con copia de
seguridad es el enrutamiento de red de Microsoft.
FileshareBackupFailedWithAzureRpRequestThrottling/
FileshareRestoreFailedWithAzureRpRequestThrottling:
error de operación de restauración o copia de seguridad
de archivos compartidos debido a la limitación del
servicio de almacenamiento. Esto puede ser debido a que
el servicio de almacenamiento está ocupado procesando
otras solicitudes para la cuenta de almacenamiento dada.
Código de error: FileshareBackupFailedWithAzureRpRequestThrottling/
FileshareRestoreFailedWithAzureRpRequestThrottling
Mensaje de error: Error de operación de restauración o copia de seguridad de archivos

compartidos debido a la limitación del servicio de almacenamiento. Esto puede ser
debido a que el servicio de almacenamiento está ocupado procesando otras solicitudes
para la cuenta de almacenamiento dada.
Intente realizar la operación de copia de seguridad o restauración en otro momento.

TargetFileShareNotFound: no se encontró el recurso
compartido de archivos de destino
Código de error: TargetFileShareNotFound
Mensaje de error: No se encontró el recurso compartido de archivos de destino.
Asegúrese de que existe la cuenta de almacenamiento seleccionada y de que no se

ha eliminado el recurso compartido de archivos de destino.

admitida para la copia de seguridad de recursos compartidos de archivos.
UserErrorStorageAccountIsLocked:error de los trabajos de

copia de seguridad o restauración debido al estado
Bloqueado de la cuenta de almacenamiento
Código de error: UserErrorStorageAccountIsLocked
Mensaje de error: Error de los trabajos de copia de seguridad o restauración debido al

estado Bloqueado de la cuenta de almacenamiento.
Quite el bloqueo de la cuenta de almacenamiento o use eliminar bloqueo en lugar de

leer bloqueo y reintente la operación de copia de seguridad o restauración.
DataTransferServiceCoFLimitReached: no se pudo llevar a

cabo la recuperación porque el número de archivos con
errores es superior al umbral permitido
Código de error: DataTransferServiceCoFLimitReached
Mensaje de error: No se pudo llevar a cabo la recuperación porque el número de

archivos con errores es superior al umbral permitido.
Los motivos de los errores de recuperación se muestran en un archivo (la ruta de

acceso se proporciona en los detalles del trabajo). Corrija los errores y vuelva a
intentar la operación de restauración solo de los archivos con errores.
Causas comunes de errores de restauración de archivos:

Los archivos con errores están actualmente en uso.
Existe un directorio con el mismo nombre que el archivo con errores en el
directorio principal.
DataTransferServiceAllFilesFailedToRecover: error en la
recuperación porque no se pudo recuperar ningún
archivo
Código de error: DataTransferServiceAllFilesFailedToRecover
Mensaje de error: Error de recuperación. No se pudo recuperar ningún archivo.

acceso se proporciona en los detalles del trabajo). Solucione los errores y vuelva a
intentar la operación de restauración solo de los archivos con error.

UserErrorDTSSourceUriNotValid: error en la restauración

porque uno de los archivos del origen no existe
Código de error: DataTransferServiceSourceUriNotValid
Mensaje de error: Error en la restauración porque uno de los archivos del origen no
existe.
Los elementos seleccionados no están presentes en los datos del punto de

recuperación. Para recuperar los archivos, proporcione la lista de archivos correcta.
La instantánea del recurso compartido de archivos que corresponde al punto de
recuperación se elimina manualmente. Seleccione un punto de recuperación
diferente y vuelva a intentar la operación de restauración.
UserErrorDTSDestLocked: ya hay un trabajo de

recuperación en curso para el mismo destino
Código de error: UserErrorDTSDestLocked
Mensaje de error: Ya hay un trabajo de recuperación en curso para el mismo destino.
La copia de seguridad de recursos compartidos de archivos no admite la

recuperación en paralelo en el mismo recurso compartido de archivos de destino.
Espere a que la recuperación existente finalice e inténtelo de nuevo. Si no

encuentra un trabajo de recuperación en el almacén de Recovery Services,
compruebe otros almacenes de Recovery Services de la misma suscripción.
UserErrorTargetFileShareFull: no se puede realizar la

operación de restauración porque el recurso compartido
de archivos de destino está lleno
Código de error: UserErrorTargetFileShareFull
Mensaje de error: No se puede realizar la operación de restauración porque el recurso

compartido de archivos de destino está lleno.
Aumente la cuota de tamaño del recurso compartido de archivos de destino para

albergar los datos de restauración y vuelva a intentar la operación de restauración.
UserErrorTargetFileShareQuotaNotSufficient: no se puede
realizar la restauración del recurso compartido de
archivos de destino porque la cuota de tamaño de
almacenamiento no es suficiente
Código de error: UserErrorTargetFileShareQuotaNotSufficient
Mensaje de error: No se puede realizar la restauración del recurso compartido de

archivos de destino porque la cuota de tamaño de almacenamiento no es suficiente.
Aumente la cuota de tamaño del recurso compartido de archivos de destino para

albergar los datos de restauración y vuelva a intentar la operación.
File Sync PreRestoreFailed: la operación de restauración

produjo un error porque, a su vez, se produjo un error al
realizar las operaciones previas de restauración en los
recursos del servicio de sincronización de archivos
asociados con el recurso compartido de archivos de
destino
Código de error: File Sync PreRestoreFailed
Mensaje de error: La operación de restauración produjo un error porque, a su vez, se

produjo un error al realizar las operaciones previas de restauración en los recursos del
servicio de sincronización de archivos asociados con el recurso compartido de archivos
de destino.
Intente restaurar los datos en otro momento. Si el problema persiste, póngase en
contacto con el servicio de soporte técnico de Microsoft.
AzureFileSyncChangeDetectionInProgress: la detección de
cambios en el servicio Azure File Sync está en curso para
el recurso compartido de archivos de destino. La
detección de cambios se desencadenó mediante una
restauración anterior en el recurso compartido de
archivos de destino
Código de error: AzureFileSyncChangeDetectionInProgress
Mensaje de error: La detección de cambios en el servicio Azure File Sync está en curso
para el recurso compartido de archivos de destino. La detección de cambios se
desencadenó mediante una restauración anterior en el recurso compartido de archivos
de destino.
Use otro recurso compartido de archivos de destino. Como alternativa, puede esperar a
que se complete la detección de cambios en el servicio Azure File Sync para el recurso
compartido de archivos de destino antes de volver a intentar la restauración.
UserErrorAFSRecoverySomeFilesNotRestored: uno o
varios archivos no se pudieron recuperar correctamente.
Para más información, consulte la lista de archivos que
han dado error en la ruta de acceso anterior
Código de error: UserErrorAFSRecoverySomeFilesNotRestored
Mensaje de error: Uno o varios archivos no se pudieron recuperar correctamente. Para

más información, consulte la lista de archivos que han dado error en la ruta de acceso
anterior.

acceso se proporciona en los detalles del trabajo). Corrija los motivos y vuelva a
intentar la operación de restauración solo de los archivos con errores.

UserErrorAFSSourceSnapshotNotFound: no se encuentra
la instantánea del recurso compartido de archivos de
Azure correspondiente a este punto de recuperación
Código de error: UserErrorAFSSourceSnapshotNotFound
Mensaje de error: No se encuentra la instantánea del recurso compartido de archivos de

Azure correspondiente a este punto de recuperación.
Asegúrese de que la instantánea de recurso compartido de archivos, que se

corresponde con el punto de recuperación que está intentando usar para la
recuperación, todavía existe.
７ Nota
Si elimina una instantánea de recurso compartido de archivos creada por

Azure Backup, los puntos de recuperación correspondientes se volverán
inutilizables. Se recomienda no eliminar las instantáneas para garantizar la
recuperación.
Intente seleccionar otro punto de restauración para recuperar los datos.
UserErrorAnotherRestoreInProgressOnSameTarget: hay
otro trabajo de restauración en curso en el mismo recurso
compartido de archivos de destino
Código de error: UserErrorAnotherRestoreInProgressOnSameTarget
Mensaje de error: Hay otro trabajo de restauración en curso en el mismo recurso

compartido de archivos de destino.
Use otro recurso compartido de archivos de destino. Como alternativa, puede cancelar o
esperar a que la otra restauración se complete.
UserErrorSourceOrTargetAccountNotAccessible
Código de error: UserErrorSourceOrTargetAccountNotAccessible
Mensaje de error: La cuenta de almacenamiento de origen o de destino no es accesible

desde el servicio de restauración de Azure Files.
Acciones recomendadas: asegúrese de que las siguientes configuraciones de la cuenta
de almacenamiento estén configuradas correctamente para realizar una restauración
correcta:
Asegúrese de que las claves de almacenamiento no están rotadas durante la

restauración.
Compruebe la configuración de red en la(s) cuenta(s) de almacenamiento y

asegúrese de que permite los servicios propios de Microsoft.
Asegúrese de que la cuenta de almacenamiento de destino tenga la siguiente

configuración: El ámbito permitido para las operaciones de copia está establecido
en Desde cuentas de almacenamiento en el mismo inquilino de Azure AD.

Errores comunes de modificación de directivas
BMSUserErrorConflictingProtectionOperation: hay otra

operación de protección de configuración en curso para
este elemento
Código de error: BMSUserErrorConflictingProtectionOperation
Mensaje de error: Hay otra operación de protección de configuración en curso para este
elemento.
Espere a que termine la operación de modificación de directivas anterior y vuelva a

intentarlo en otro momento.
BMSUserErrorObjectLocked: hay otra operación en curso

en el elemento seleccionado
Código de error: BMSUserErrorObjectLocked
Mensaje de error: Hay otra operación en curso en el elemento seleccionado.
Espere a que la otra operación en curso termine y vuelva a intentarlo en otro momento.
Errores comunes relacionados con la
eliminación temporal
UserErrorRestoreAFSInSoftDeleteState: este punto de

restauración no está disponible porque la instantánea
asociada al punto está en un recurso compartido de
archivos que está en estado de eliminación temporal
Código de error: UserErrorRestoreAFSInSoftDeleteState
Mensaje de error: Este punto de restauración no está disponible porque la instantánea

asociada al punto está en un recurso compartido de archivos que está en estado de
eliminación temporal.
No puede realizar una operación de restauración cuando el recurso compartido de

archivos se encuentra en estado de eliminación temporal. Restaure el recurso
compartido de archivos desde el portal de Files o use el script Undelete y luego intente
realizar la restauración.
UserErrorRestoreAFSInDeleteState: los puntos de

restauración mostrados no están disponibles porque el
recurso compartido de archivos asociado que contiene
las instantáneas del punto de restauración se ha
eliminado permanentemente
Código de error: UserErrorRestoreAFSInDeleteState
Mensaje de error: Los puntos de restauración mostrados no están disponibles porque el

recurso compartido de archivos asociado que contiene las instantáneas del punto de
restauración se ha eliminado permanentemente.
Compruebe si se ha eliminado el recurso compartido de archivos del que se ha realizado

una copia de seguridad. Si se encontraba en un estado de eliminación temporal,
compruebe si el período de retención de eliminación temporal es superior y no se ha
recuperado. En cualquiera de estos casos, perderá todas las instantáneas de forma
permanente y no podrá recuperar los datos.
７ Nota
Se recomienda no eliminar el recurso compartido de archivos del que se ha
realizado una copia de seguridad, o bien, si se encuentra en estado de eliminación
temporal, recuperarlo antes de que finalice el período de retención de eliminación
temporal, con el fin de evitar que se pierdan todos los puntos de restauración.
UserErrorBackupAFSInSoftDeleteState: no se pudo
realizar la copia de seguridad porque el recurso
compartido de archivos de Azure está en estado de
eliminación temporal
Código de error: UserErrorBackupAFSInSoftDeleteState
Mensaje de error: No se pudo realizar la copia de seguridad porque el recurso

compartido de archivos de Azure está en estado de eliminación temporal.
Recupere el recurso compartido de archivos desde el portal de Files o mediante el script

Undelete para continuar con la copia de seguridad e impedir la eliminación permanente
de los datos.
UserErrorBackupAFSInDeleteState: no se pudo realizar la

copia de seguridad porque el recurso compartido de
archivos asociado de Azure se eliminó permanentemente
Código de error: UserErrorBackupAFSInDeleteState
Mensaje de error: No se pudo realizar la copia de seguridad porque el recurso

compartido de archivos asociado de Azure se eliminó permanentemente
Compruebe si se ha eliminado permanentemente el recurso compartido de archivos del

que se ha realizado una copia de seguridad. En caso afirmativo, detenga la copia de
seguridad de este recurso compartido de archivos para evitar errores repetidos de copia
de seguridad. Para obtener información sobre cómo detener la protección, vea
Detención de la protección en un recurso compartido de archivos de Azure.
Pasos siguientes
Para más información sobre la copia de seguridad de recursos compartidos de archivos
de Azure, consulte:
Copia de seguridad de recursos compartidos de archivos de Azure

Preguntas frecuentes acerca de la copia de seguridad de recursos compartidos de
archivos de Azure
Solución de problemas de ClientOtherErrors
en Azure Files
Artículo • 20/10/2023
En este artículo se enumeran los clientOtherErrors que puede encontrar al usar recursos
compartidos de archivos de Azure SMB. En general, clientOtherErrors son principalmente
inofensivos y se esperan errores. Se produce un error en las solicitudes, pero el sistema sigue
comportándose según lo esperado. Es normal ver una cantidad significativa de estos errores
registrados.
Se aplica a
¿Qué son ClientOtherErrors?

ClientOtherError suele significar errores esperados del lado cliente, como "no encontrado" y "el
recurso ya existe". En los archivos de registro de almacenamiento del lado servidor, estas
operaciones se registran con un estado de transacción de ClientOtherErrors.
Por ejemplo, el cliente SMB de Windows que interactúa con sistemas de archivos remotos no
siempre conoce las funcionalidades del sistema de archivos remoto. Podría ser Windows Server,
Azure Files o alguna otra implementación de servidor SMB. Por lo tanto, el cliente SMB realizará
llamadas al servidor de archivos remoto con determinadas API. Si se produce un error en estas
API, se revertirá al uso de una API diferente o incluso simplemente omitirá estos errores. En
función del protocolo de solicitud y respuesta de SMB, se espera que se produzca un error en un
gran número de solicitudes aunque el sistema se haya comportado correctamente. Esto puede
deberse a errores de autorización, intentos de crear un archivo con un nombre que ya existe o
intentos de abrir un archivo que no existe.
Registro e informes
Para solucionar problemas de ClientOtherErrors, puede crear una configuración de diagnóstico y
usar Azure Monitor para la generación de informes. También puede analizar los registros para ver
las solicitudes con errores, incluido ClientOtherErrors, o usar consultas kusto.
También puede recopilar un seguimiento de ProcMon de un cliente que coincida con la dirección
IP que se muestra en los registros. Agregue un filtro para ver solo el tráfico a Azure Files.
Common ClientOtherErrors
En la tabla siguiente se enumeran los clientOtherErrors comunes, junto con una explicación de
cada error.
Operación Estado Explicación del error
QueryFullEaInformation STATUS_NOT_IMPLEMENTED Este error se devuelve porque

Azure Files no implementa esta
API. Azure Files no admite
actualmente atributos
extendidos.
UnknownFileClass=48 STATUS_NOT_SUPPORTED Esta es la

FileNormalizedNameInformation
llamada API. Se trata de una
nueva compatibilidad con
Windows Server y actualmente
Azure Files no admite esta API.
Fileopen 492 STATUS_ACCESS_DENIED El autor de la llamada no tiene

los permisos necesarios para
abrir el archivo. En el caso del
acceso Kerberos, la ACL
deniega el acceso del autor de
la llamada.
Fileopen 257 STATUS_OBJECT_NAME_INVALID La ruta de acceso de la

solicitud abierta no es válida
(por ejemplo, la ruta de acceso
es demasiado larga o
demasiado profunda).
Fileopen 12 STATUS_FILE_IS_ADIRECTORY El autor de la llamada abre un

directorio sin usar los
parámetros correctos
CreateFile (por ejemplo, la
intención de Copia de
seguridad).
Fileopen 8 STATUS_SHARING_VIOLATION El autor de la llamada está

abriendo un archivo que ya se
ha abierto con restricciones
(por ejemplo, exclusivo u otros
solo pueden leer).
Fileopen 6 El autor de la llamada abre un

STATUS_OBJECT_NAME_NOT_FOUND archivo que no existe.
FSCTL_QUERY_NETWORK_INTERFACE_INFO STATUS_INVALID_DEVICE_REQUEST Esto solo se usa para Azure

(IOCTL) Files cuando los clientes han
Operación Estado habilitado
Explicaciónladel
característica
error
multicanal. En otros casos, no
es necesario y se devuelve una
solicitud de dispositivo no
válida cuando se consulta
desde el cliente.
QueryStreamInformation STATUS_NOT_IMPLEMENTED Algunos sistemas de archivos

tienen el concepto de
secuencias de datos
alternativas u otras secuencias,
como la secuencia de punto de
reanálisis. Azure Files no tiene
este concepto, por lo que no
se admite la API.
Inesperado (IOCTL) STATUS_INVALID_DEVICE_REQUEST Se trata

FSCTL_QUERY_FILE_REGIONS de ,
un concepto de región que es
específico de NTFS/refs y no
tiene sentido en relación con
Azure Files. Por lo tanto, no
implementamos este código
FSCTL.
ChangeNotify STATUS_CANCELLED Aplicaciones como el

Explorador de Windows Shell
se suscriben para cambiar las
notificaciones de los archivos.
De este modo, cuando las
propiedades cambian en un
archivo, el Explorador de
Windows Shell se actualiza
automáticamente en la vista. El
cliente puede optar por
cancelar esta suscripción (por
ejemplo, si el usuario ha
cambiado las vistas en el
Explorador y ya no la necesita).
En ese caso, se devuelve
STATUS_CANCELLED al cliente
para confirmar que la
suscripción se ha cancelado.
FSCTL_DFS_GET_REFERRALS (IOCTL) STATUS_FS_DRIVER_REQUIRED Se trata de una solicitud de

referencia DFS. Azure Files no
admite DFS y este es el estado
correcto que se devuelve
cuando el sistema no admite
DFS.
FileSupersede STATUS_ACCESS_DENIED La sustitución de archivos es

una operación en la que se
elimina un archivo existente y
se coloca un nuevo archivo en
Operación Estado Explicación del error
su lugar. Si el autor de la
llamada no tiene permiso para
eliminar el archivo existente, se
producirá un error en la
llamada.
FileCreate 7 STATUS_OBJECT_NAME_INVALID Esto sucede cuando una

solicitud para crear un nuevo
archivo tiene un nombre
solicitado no válido (por
ejemplo, con caracteres no
admitidos).
FileCreate 3 STATUS_OBJECT_NAME_COLLISION Esto sucede cuando una

solicitud para crear un nuevo
archivo tiene un nombre
solicitado que coincide con un
archivo existente.
Leer STATUS_ACCESS_DENIED Esto sucede cuando se realiza

una solicitud de lectura en un
archivo con un identificador
que no tiene acceso concedido
de lectura (por ejemplo, el
archivo se abrió con el acceso
de escritura deseado).
TreeConnect STATUS_ACCESS_DENIED En el contexto de la

autenticación Kerberos, el
llamador no tiene permisos de
nivel de recurso compartido
asignados a través de RBAC o
la característica "Permisos de
recurso compartido
predeterminados". Si no se
establece la característica
"Permisos de recurso
compartido predeterminados",
los autores de llamadas que
sean identidades de equipo
obtendrán de forma coherente
este error de acceso en el
recurso compartido.
Vea también
Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la
comunidad de Azure. También puede enviar comentarios de productos a la comunidad de
comentarios de Azure .
Comentarios
API REST de Azure Files
Artículo • 06/07/2023
Azure Files proporciona recursos compartidos de archivos en la nube hospedados a los

que puede acceder (montar) mediante protocolos de sistema de archivos estándar del
sector, como SMB y NFS. Al montar un recurso compartido de archivos en el equipo
mediante SMB o NFS, el sistema operativo redirige las solicitudes de API para el sistema
de archivos local. El redireccionamiento incluye solicitudes de API locales que realiza
mediante interfaces de .NET System.IO o métodos abiertos, de lectura o escritura de
Python. Esto significa que los usuarios de estas aplicaciones no necesitan hacer nada
especial o incluso saber que sus datos están en un recurso compartido de archivos
remoto en lugar del almacenamiento local.
Azure Files también proporciona una API REST, que a menudo se denomina API
FileREST. Para usar la API FileREST, cree solicitudes HTTPS en los puntos de conexión
HTTPS de FileREST. Puede escribir código para crear solicitudes HTTPS usted mismo,
pero proporcionamos SDK de Azure que usan la API FileREST para usted,
proporcionando un contenedor de lenguaje idiomático a través de la API FileREST en
lenguajes populares como C#, Java, Python, JavaScript y Go.
Dado que la API FileREST se diseñó específicamente para Azure Files, le permite acceder
a características de Azure Files a las que no se puede acceder a través de SMB o NFS.
También le permite realizar ciertas operaciones, como copiar, de forma más eficaz de lo
que se puede a través de SMB o NFS.
La naturaleza sin estado de HTTPS hace que la API FileREST sea útil para los servicios en
la nube o las aplicaciones que necesitan acceder a muchos recursos compartidos de
archivos de Azure. Por ejemplo, puede adjuntar servicios o aplicaciones de valor
agregado a un recurso compartido de archivos de Azure para agregar una
funcionalidad. Estos servicios o aplicaciones pueden incluir antivirus, copia de seguridad,
administración de datos o productos de replicación. Azure File Sync y Azure Backup son
servicios importantes de Microsoft que usan ampliamente la API FileREST para agregar
valor sobre un recurso compartido de archivos de Azure propiedad del cliente.
Considere la posibilidad de usar la API FileREST si va a crear aplicaciones o servicios de

valor añadido, especialmente si proporciona esos servicios a los clientes. Si va a
construir una aplicación de línea de negocio, especialmente una que los usuarios usarán
en un recurso compartido de archivos de Azure montado, puede usar SMB/NFS o
FileREST. Sin embargo, es posible que encuentre que el uso de SMB o NFS proporciona
una ruta de acceso más sencilla, ya que esos protocolos le permiten usar las API nativas
del sistema de archivos.
Si tiene una aplicación existente escrita con las API nativas del sistema de archivos, no es
necesario volver a escribirla para aprovechar las ventajas de Azure Files. La propuesta de
valor clave de Azure Files expone las API nativas del sistema de archivos mediante el uso
de SMB o NFS.
Para obtener más información sobre Azure Files, incluida la implementación, las redes y
la configuración de identidad, consulte:

Introducción a las opciones de autenticación basadas en la identidad de
Azure Files para el acceso con SMB
Plano de control
En Azure, el plano de control se proporciona a través de Azure Resource Manager, que
proporciona una manera común de exponer los recursos de Azure que administrará el
cliente. La unidad de administración de nivel superior es la cuenta de almacenamiento.
La cuenta de almacenamiento es un recurso con seguimiento en Azure Files y otros
servicios de almacenamiento, como Azure Blob Storage.
El proveedor de recursos de almacenamiento administra la cuenta de almacenamiento,

que tiene el espacio de nombres Microsoft.Storage . El proveedor de recursos de
almacenamiento también expone la administración de recursos secundarios o recursos
proxy que permiten la administración de los servicios de almacenamiento agrupados en
la cuenta de almacenamiento. Para Azure Files, hay dos recursos de proxy pertinentes:
Recurso FileService . Proporciona la configuración específica de Azure Files que se

aplican a todos los recursos compartidos de archivos de la cuenta de
almacenamiento. El FileService recurso es un elemento secundario de la cuenta
de almacenamiento. Una cuenta de almacenamiento siempre tiene solo un
FileService recurso: default .
Recurso FileShare . Representa un recurso compartido de archivos o una

instantánea de un recurso compartido de archivos. El FileShare recurso es un
elemento secundario del FileService recurso y puede contener un número
infinito de recursos compartidos de archivos.
Aunque un FileService recurso puede contener un número infinito de recursos, el uso

de FileShare un número muy grande no es una buena idea porque todo dentro de una
cuenta de almacenamiento comparte un grupo definido de E/S, ancho de banda y otros
límites. Para más información, consulte Objetivos de escalabilidad y rendimiento de
Azure Files.
Para obtener información sobre cómo llamar a las API del plano de control, consulte:
Cuenta de almacenamiento
FileService
FileShare
Las operaciones en los FileService objetos y FileShare también se pueden realizar a

través del plano de datos. Se trata de un artefacto de Azure Files Resource Manager de
Azure previa. Aunque estas API son totalmente compatibles, en la mayoría de los casos
debe usar las API del proveedor de recursos de almacenamiento para administrar Azure
Files por estos motivos:
Las operaciones expuestas a través de Azure Resource Manager usar Azure Active
Directory (Azure AD) para la autenticación y autorización, por lo que puede
administrar Azure Files mediante el control de acceso basado en rol (RBAC). Puede
autorizar la aplicación o el servicio para llamar mediante programación a estas API
con una entidad de servicio de Azure AD.
Puede llamar a las API de Azure Resource Manager de forma imperativa, ya sea a
través de la API REST directamente o a través de un SDK. O bien, puede llamarlos
declarativamente declarando qué recursos deben implementarse a través de
plantillas de Azure. Para los recursos que deben crearse repetidamente juntos (por
ejemplo, en las implementaciones de servicio), el uso de plantillas puede
simplificar considerablemente el trabajo necesario.
Aunque se recomienda usar el proveedor de recursos de almacenamiento para

administrar los recursos de almacenamiento, el uso de las API de administración
del plano de datos FileREST le proporcionará un mejor rendimiento en los casos
que requieren una gran escala. Un ejemplo de este caso es una carga de trabajo
que crea o modifica miles de recursos compartidos de archivos dentro de la misma
Microsoft.Storage storageAccounts/fileServices/shares desencadena una
operación del plano de control a través del proveedor de recursos de
almacenamiento.
Microsoft.Storage storageAccounts/fileServices/fileshares es una operación
del plano de datos. Establecer roles de nivel de recurso compartido, como lector
de recursos compartidos de SMB de datos de almacenamiento, debe ser una
operación de plano de datos y debe usar este recurso.
Plano de datos
Azure Files proporciona un sistema de archivos jerárquico para datos no estructurados.
La API FileREST modela los dos objetos importantes en el espacio del sistema de
archivos: archivos y directorios. Para obtener información sobre cómo llamar a las API de
FileREST, consulte:
Operaciones en Azure Files (se prefieren las API del plano de control)
Operaciones en recursos compartidos de archivos (prefieren las API del plano de
control)
Operaciones en directorios
Operaciones en archivos
Vea también
Referencia de API REST de Azure Storage
Características no admitidas en Azure Files
conceptos de Azure Files
Bibliotecas cliente de Azure Storage
para .NET
Artículo • 09/01/2024
Las bibliotecas cliente de Azure Storage para .NET ofrecen una interfaz práctica para
realizar llamadas a Azure Storage. Para más información sobre Azure Storage, consulte
Introducción a Azure Storage.
Bibliotecas para el acceso a datos

La versión más reciente de la biblioteca cliente de Azure Storage para el acceso a datos
es la versión 12.x.x. Microsoft recomienda usar la versión 12.x.x para las nuevas
aplicaciones.
Si no puede actualizar las aplicaciones existentes a la versión 12.x.x, Microsoft

recomienda usar la versión 11.x.x.
Versión 12.x.x
Las bibliotecas cliente de la versión 12.x.x para .NET forman parte del SDK de Azure para
.NET. El código fuente de las bibliotecas cliente de Azure Storage para .NET está
disponible en GitHub .
Use las bibliotecas 12.x.x.x siguientes para trabajar con blobs, archivos y colas:
ﾉ Expandir tabla
Biblioteca Referencia Paquete Source
Azure.Storage.Blobs.Batch NuGet GitHub
Azure.Storage.Blobs Referencia NuGet GitHub
Azure.Storage.Common NuGet GitHub
Azure.Storage.Files.DataLake Referencia NuGet GitHub
Azure.Storage.Files.Shares Referencia NuGet GitHub
Azure.Storage.Queues Referencia NuGet GitHub
Versión 11.x.x.x
El código fuente de las bibliotecas cliente de Azure Storage para .NET está disponible en
GitHub .
Use las siguientes bibliotecas de la versión 11.x.x para trabajar con blobs, archivos y
colas:
ﾉ Expandir tabla
Microsoft.Azure.Storage.Blob Referencia NuGet GitHub
Microsoft.Azure.Storage.Common NuGet GitHub
Microsoft.Azure.Storage.File Referencia NuGet GitHub
Microsoft.Azure.Storage.Queue Referencia NuGet GitHub
Bibliotecas para la administración de recursos

La versión más reciente de la biblioteca cliente de Azure Storage para la administración
de recursos es la versión 1.x.x. Microsoft recomienda usar la versión 1.x.x para las nuevas
aplicaciones.
Si no puede actualizar las aplicaciones existentes a la versión 1.x.x, Microsoft

recomienda usar la versión 25.x.x.
Versión 1.x.x
Use la biblioteca 1.x.x.x siguiente para trabajar con el proveedor de recursos de Azure
Storage:
ﾉ Expandir tabla
Azure.ResourceManager.Storage Referencia NuGet GitHub
Versión 25.x.x
Use la biblioteca 25.x.x.x siguiente para trabajar con el proveedor de recursos de Azure
Storage:
ﾉ Expandir tabla
Microsoft.Azure.Management.Storage Referencia NuGet GitHub
Problemas conocidos
En esta sección se detallan los problemas conocidos de las bibliotecas cliente de Azure
Storage para .NET.
Mensaje de error InvalidHeaderValue al usar la versión

beta del SDK
En escenarios poco frecuentes, las aplicaciones que se han actualizado a la versión beta
más reciente o disponible con carácter general del SDK pueden recibir un
InvalidHeaderValue mensaje de error. Este problema puede producirse al usar
cualquiera de las bibliotecas de Storage. El mensaje de error es similar al ejemplo

siguiente:
Consola
HTTP/1.1 400 The value for one of the HTTP headers is not in the correct
format.
Content-Length: 328
Content-Type: application/xml
Server: Microsoft-HTTPAPI/2.0
x-ms-request-id: <REMOVED>
Date: Fri, 19 May 2023 17:10:33 GMT
<?xml version="1.0" encoding="utf-8"?><Error><Code>InvalidHeaderValue</Code>

<Message>The value for one of the HTTP headers is not in the correct format.
RequestId:<REMOVED>
Time:2023-05-19T17:10:34.2972651Z</Message><HeaderName>x-ms-
version</HeaderName><HeaderValue>yyyy-mm-dd</HeaderValue></Error>
Si ha actualizado a la versión beta más reciente o disponible con carácter general del
SDK y experimenta este error, se recomienda cambiar a la versión anterior disponible
con carácter general del SDK para ver si el problema se resuelve. Si el problema persiste
o si la recomendación no es factible, abra una incidencia de soporte técnico para
explorar más opciones.
６ Colaborar con nosotros en Comentarios de Azure SDK
GitHub for .NET
El origen de este contenido se Azure SDK for .NET es un proyecto
puede encontrar en GitHub, de código abierto. Seleccione un
donde también puede crear y vínculo para proporcionar
revisar problemas y solicitudes comentarios:
de incorporación de cambios.
Para más información, consulte  Abrir incidencia con la
nuestra guía para documentación
colaboradores.
 Proporcionar comentarios sobre
el producto
Bibliotecas de Azure Storage para Java
Artículo • 09/01/2024
Las bibliotecas de Azure Storage para Java proporcionan clases para trabajar con datos
en su cuenta de Almacenamiento de Azure y con la propia cuenta de almacenamiento.
Para más información sobre Azure Storage, consulte Introducción a Azure Storage.
Biblioteca cliente para el acceso a datos

La biblioteca cliente de Azure Storage para Java admite Blob Storage, Queue Storage,
Azure Files y Azure Data Lake Storage Gen2 (biblioteca de versión preliminar).
Agregar el paquete al proyecto

Agregue las siguientes dependencias al archivo de Maven pom.xml según corresponda:
XML
<dependency>
<groupId>com.azure</groupId>
<artifactId>azure-storage-blob</artifactId>
<version>12.4.0</version>
</dependency>
<dependency>
<artifactId>azure-storage-queue</artifactId>
</dependency>
<dependency>
<artifactId>azure-storage-file-share</artifactId>
</dependency>
<dependency>
<artifactId>azure-storage-file-datalake</artifactId>
<version>12.0.0-preview.6</version>
</dependency>
Para obtener más información sobre cómo agregar una dependencia en Java, consulte
Adición de una dependencia .
Ejemplo de uso
En el ejemplo siguiente se crea un contenedor de almacenamiento y se carga un archivo
local en el contenedor de almacenamiento.
Java
String yourSasToken = "<insert-your-sas-token>";

/* Create a new BlobServiceClient with a SAS Token */
BlobServiceClient blobServiceClient = new BlobServiceClientBuilder()
.endpoint("https://your-storage-account-url.storage.windows.net")
.sasToken(yourSasToken)
.buildClient();
/* Create a new container client */

try {
containerClient = blobServiceClient.createBlobContainer("my-container-
name");
} catch (BlobStorageException ex) {
// The container may already exist, so don't throw an error
if (!ex.getErrorCode().equals(BlobErrorCode.CONTAINER_ALREADY_EXISTS)) {
throw ex;
}
}
/* Upload the file to the container */

BlobClient blobClient = containerClient.getBlobClient("my-remote-file.jpg");
blobClient.uploadFromFile("my-local-file.jpg");
Para obtener más ejemplos, revise el archivo Léame de la biblioteca cliente .
Paquetes disponibles
En la tabla siguiente se describen las versiones recomendadas de la biblioteca cliente de
almacenamiento para Java.
ﾉ Expandir tabla
Versión de la Servicios Maven Referencia/Javadoc Source, Readme,

biblioteca admitidos Examples
Versión 12 Blob, Queue, File Blob Blob Blob (inicio

y Data Lake Cola Cola rápido)
Archivo Archivo Cola
Data Lake Data Lake Archivo
Data Lake
Versión 8 Blob, Queue, File Todos los Referencia de la Todos los

y Table servicios versión 8 servicios (inicio
Versión de la Servicios Maven Referencia/Javadoc rápido)
Source, Readme,
biblioteca admitidos Examples
Consulte la página Versiones del SDK de Azure para obtener más información sobre
cómo instalar y usar los paquetes en versión preliminar.
Biblioteca cliente para la administración de

recursos
Use el proveedor de recursos de Azure Storage para administrar cuentas de
almacenamiento, claves de cuenta, niveles de acceso, etc. Para usar la biblioteca del
proveedor de recursos, agregue una dependencia al archivo de Maven pom.xml . La
versión más reciente de la biblioteca del proveedor de recursos está disponible en
Maven .
Para obtener más información sobre la biblioteca del proveedor de recursos, consulte la
referencia de administración . El código fuente de la biblioteca del proveedor de
recursos está disponible en el repositorio del SDK de Java de Azure .
En el ejemplo siguiente se crea una nueva cuenta de almacenamiento en la suscripción y

se recuperan sus claves de acceso.
Java
StorageAccount storageAccount =
azureResourceManager.storageAccounts().define(storageAccountName)
.withRegion(Region.US_EAST)
.withNewResourceGroup(rgName)
.create();
// get a list of storage account keys related to the account

List<StorageAccountKey> storageAccountKeys = storageAccount.getKeys();
for (StorageAccountKey key : storageAccountKeys) {
System.out.println("Key name: " + key.keyName() + " with value "+
key.value());
}
Problemas conocidos
Las versiones anteriores del SDK de Azure Storage para Java (v12) tienen uno o varios
problemas críticos conocidos, que se detallan a continuación. Estos problemas pueden
afectar a la escritura o lectura de datos de la cuenta de Azure Storage. Si usa una versión
anterior de una biblioteca cliente, se recomienda actualizar a la versión más reciente.
ﾉ Expandir tabla
Biblioteca de cliente Versiones Versión mínima con Acción recomendada

afectadas seguridad demostrada
Blob de Azure De 12.0 a 12.10.0, 12.22.1 Actualización a la

Storage de 12.19.0 a 12.22.0 versión más reciente
Azure File Data Lake De 12.0 a 12.7.0 12.8.0 Actualización a la

versión más reciente
Recurso compartido 12.0 a 12.4.1 12.5.0 Actualización a la

de archivos de Azure versión más reciente
Cola de Azure 12.0 a 12.6.0 12.7.0 Actualización a la

Storage versión más reciente
criptografía de Azure 12.0 a 12.16.1 12.17.0 Actualización a la

Blob Storage versión más reciente
Si tiene alguna pregunta o necesita ayuda adicional, cree una incidencia de soporte
técnico con las siguientes opciones:
Tipo de problema: Requisitos previos técnicos

Tipo de servicio: Blob Storage
Resumen: #JavaSDKv12
Tipo de problema: desarrollo
Subtipo de problema: biblioteca cliente o SDK
Lista de problemas conocidos

1. Problema de sobrescritura del búfer con BlobOutputStream
2. Datos no válidos cargados durante los reintentos
3. Carga que se devuelve incorrectamente como correcta cuando IOException se
produce
4. Datos incorrectos que se descargan con downloadToFile
5. No se respeta el parámetro overwrite al cargar un archivo grande, lo que da lugar
a una sobrescritura incorrecta.
6. Operación de sobrescritura invertida para el parámetro de sobrescritura, lo que da
lugar a una sobrescritura incorrecta
7. El contenido del mensaje se borra incorrectamente cuando solo se establece el
tiempo de espera de visibilidad
8. Cifrado del lado cliente actualizado para usar AES-GCM debido a vulnerabilidades
de seguridad en modo CBC
9. Datos incorrectos que se descargan con downloadToFile() cuando se reintentan las
solicitudes REST subyacentes
10. Mensaje de error InvalidHeaderValue al usar la versión beta del SDK
1. Problema de sobrescritura del búfer con

BlobOutputStream
Descripción del problema

Si se usa un BlobOutputStream objeto para cargar blobs, en algunos escenarios, este uso
puede dar lugar a que un objeto no válido se escriba en Azure Blob Storage.
BlobOutputStream el objeto se puede obtener a través de
BlockBlobClient.getBlobOutputStream() .
Cargar un archivo mayor que el valor de MaxSingleUploadSize usar el write() método

de la BlobOutputStream clase da como resultado que un objeto no válido se escriba en
Azure Blob Storage. El valor predeterminado de MaxSingleUploadSize es 256 MiB. Puede
cambiar este valor llamando al setMaxSingleUploadSizeLong() método de la
ParallelTransferOptions clase .
Una vez que el tamaño de los datos de entrada cruza MaxSingleUploadSize , el write()
método de BlobOutputStream vuelve antes de realizar una copia profunda de los datos
de entrada. Si la aplicación que invoca sobrescribe la matriz de bytes de datos de
entrada con otros datos antes de que se produzca la copia en profundidad, los datos no
válidos se pueden escribir en el blob.
Detalles del problema
ﾉ Expandir tabla
Biblioteca de Versiones Versión mínima con Acción recomendada

cliente afectadas seguridad demostrada
Blob de Azure 12.0 a 12.10.0 12.10.1 Actualización a la versión más

Storage reciente o al mínimo 12.22.1
Pasos recomendados
1. Actualice las versiones de la biblioteca cliente según la tabla anterior.
2. Compruebe si el código de la aplicación llama a
BlockBlobClient.getBlobOutputStream() . Si lo encuentra, la aplicación se ve
afectada.
Además, puede identificar los blobs potencialmente afectados debido a este problema
en la cuenta de Azure Storage. Siga estos pasos para identificar los blobs
potencialmente afectados:
1. Compruebe si la aplicación usa BlobOutputStream para cargar blobs (obtenidos a

través de BlockBlobClient.getBlobOutputStream() ). Si no es así, este problema no
afecta a la aplicación. Sin embargo, se recomienda actualizar la aplicación para que
use la versión 12.22.1 o posterior.
2. Obtenga el valor de la MaxSingleUploadSize aplicación (256 MiB de forma
predeterminada). Examine el código para obtener setMaxSingleUploadSizeLong() el
método de la ParallelTransferOptions clase y obtenga el valor que proporcionó
para esta propiedad.
3. Identifique el período de tiempo en el que la aplicación usó la versión de la
biblioteca cliente con este problema (de 12.0 a 12.10.0)
4. Identifique todos los blobs cargados en esta ventana de tiempo. Puede obtener
una lista de blobs mediante una llamada a la List Blobs operación con PowerShell
PowerShell, la CLI de Azure u otra herramienta. También puede aprovechar la
característica de inventario de blobs.
Siguiendo estos pasos indicará blobs que podrían verse afectados por el problema
crítico y que pueden no ser válidos. Inspeccione estos blobs para determinar cuáles
pueden ser no válidos.
Volver a la lista de problemas conocidos
2. Datos no válidos cargados durante los reintentos
Las bibliotecas cliente que se enumeran a continuación tienen un error que puede
cargar datos incorrectos durante los reintentos después de una solicitud de servicio con
errores (por ejemplo, un reintento causado por una respuesta HTTP 500).
ﾉ Expandir tabla
Blob de Azure De 12.0 a 12.7.0 Actualización a la versión más

Storage 12.6.1 reciente o al mínimo 12.22.1
Azure File Data Lake De 12.0 a 12.2.0 Actualización a la versión más

12.1.2 reciente o al mínimo 12.8.0
Recurso compartido 12.0 a 12.4.1 12.5.0 Actualización a la versión más

de archivos de Azure reciente o al mínimo 12.5.0
Pasos recomendados
1. Actualice las versiones de la biblioteca cliente según la tabla anterior.
Nota: Azure no tiene la capacidad de recuperar objetos escritos incorrectamente. Como

cualquier posible impacto se produce antes de la carga, Azure no tiene una copia válida
de ningún objeto afectado. Si tiene el archivo original, se puede volver a cargar en la
3. Cargar la devolución incorrecta como correcta cuando

IOException se produce
Todas las sobrecargas de void BlobClient.upload() y void

BlobClient.uploadWithResponse() detectan silenciosamente las respuestas de error del
servicio de almacenamiento. El método debe devolver o iniciarse como su indicador de

éxito o error. La excepción, que debería haberse registrado y propagado, en su lugar, se
escribiría directamente en el error estándar y, a continuación, se tragó, a pesar de haber
producido el único indicador de error para la API. Por lo tanto, el método devuelve
correctamente, lo que hace que el autor de la llamada piense que la operación se
completó. Esto da como resultado que el blob no se haya escrito en el almacenamiento,
a pesar de que la biblioteca indica que se ha realizado correctamente.
ﾉ Expandir tabla

Pasos recomendados
Actualice las versiones de la biblioteca cliente según la tabla anterior.
4. Datos incorrectos descargados con downloadToFile

La escritura asincrónica de búfer tiene una condición de carrera en la que el búfer entre
la secuencia de red y la secuencia de archivos se podría reutilizar para los datos
entrantes antes de vaciarse en el archivo. Esto hace que el archivo descargado esté
dañado, donde algunos datos se repiten inmediatamente, sobrescribiendo los datos
válidos en su lugar. El objeto de Storage sigue siendo correcto.
ﾉ Expandir tabla


Pasos recomendados
5. No se respeta el parámetro overwrite al cargar un

archivo grande, lo que da lugar a una sobrescritura
incorrecta.
La marca de sobrescritura no se respeta en los casos en los que hay otro trabajo de
carga paralelo en curso. Esto produce que no sobrescriba un objeto en Storage cuando
se pretende.
ﾉ Expandir tabla

Blob de Azure 12.0 12.1.0 Actualización a la versión más

Pasos recomendados
6. Operación de sobrescritura invertida para el parámetro

de sobrescritura, lo que da lugar a una sobrescritura
incorrecta

El parámetro overwrite y la operación de sobrescritura se invierten en
DataLakeFileClient.flush(long) las funciones y DataLakeFileClient.flush(long, bool)
. Ningún otro comportamiento de la biblioteca llama a estos métodos. Esto da como

resultado sobrescribir un objeto en Storage cuando el usuario no tenía intención de
sobrescribirlo cuando se pretende.
ﾉ Expandir tabla
Azure File Data De 12.0 a 12.8.0 Actualización a la versión más

Lake 12.7.0 reciente o al mínimo 12.8.0
Pasos recomendados
7. El contenido del mensaje se borra incorrectamente

cuando solo se establece el tiempo de espera de
visibilidad
El contenido del mensaje de cola se borra en error cuando solo se estableció o actualizó
el tiempo de espera de visibilidad.
ﾉ Expandir tabla

Cola de Azure 12.0 a 12.6.0 12.7.0 Actualización a la versión más

Pasos recomendados
8. Cifrado del lado cliente actualizado para usar AES-GCM

debido a vulnerabilidades de seguridad en modo CBC
Para mitigar una vulnerabilidad de seguridad que se encuentra en el modo CBC, el SDK
de Java v12 ha publicado una nueva versión del cifrado del lado cliente denominada v2,
que usa AES-GCM para el cifrado del lado cliente en lugar del modo CBC. Los SDK
actualizados son compatibles con versiones anteriores y proporcionan la capacidad de
leer y escribir datos cifrados con la versión v1 . Para obtener información completa, lea
Actualización del cifrado del lado cliente en el SDK para solucionar la vulnerabilidad de
seguridad . En la sección 2 de la entrada de blog se describen los pasos que se deben
seguir para ver si este problema le afecta.
ﾉ Expandir tabla

criptografía de Azure 12.0 a 12.16.1 12.17.0 Actualización a la versión

Blob Storage más reciente
Pasos recomendados
Actualice las versiones de la biblioteca cliente según la tabla anterior. Lea Actualización
del cifrado del lado cliente en el SDK para solucionar la vulnerabilidad de seguridad
para la acción recomendada.
9. Datos incorrectos que se descargan con

downloadToFile() cuando se reintentan las solicitudes
REST subyacentes

La biblioteca de Azure SDK para Java Storage tenía un error en el que los datos
incorrectos se podían escribir en un archivo con el downloadToFile() método cuando
algunas de las solicitudes REST de almacenamiento subyacentes experimentaron un
error de red a mitad de camino. Este error se introdujo originalmente en el verano de
2022 y fue revisado en mayo de 2023 volviendo al comportamiento anterior. Las
versiones afectadas son 12.19.0 a 12.22.0. La revisión está en la versión 12.22.1.
ﾉ Expandir tabla

Blob de Azure De 12.19.0 a 12.22.1 Actualización a la versión más

Pasos recomendados
10. Mensaje de error InvalidHeaderValue al usar la versión

beta del SDK

siguiente:
Consola
format.
Content-Length: 328
Date: Fri, 19 May 2023 17:10:33 GMT

RequestId:<REMOVED>

GitHub for Java
El origen de este contenido se Azure SDK for Java es un proyecto
puede encontrar en GitHub, de código abierto. Seleccione un
donde también puede crear y vínculo para proporcionar
revisar problemas y solicitudes comentarios:
colaboradores.
el producto
para Python
Artículo • 09/01/2024
Paquetes de cliente (12.X.X): más reciente

ﾉ Expandir tabla
Nombre del paquete Referencia Administrador de Source

paquetes
Storage Blob Referencia PyPi GitHub
Cola de almacenamiento Referencia PyPi GitHub
Recurso compartido de archivos de Referencia PyPi GitHub

almacenamiento
Storage File Data Lake (versión preliminar) Referencia PyPi GitHub
Paquetes de cliente (2.X.X): heredado

ﾉ Expandir tabla

paquetes

almacenamiento
Administración
ﾉ Expandir tabla
Nombre del paquete Referencia Administrador de paquetes Source
Administración del almacenamiento Referencia PyPi GitHub

Instalación de las bibliotecas
Cliente
Las bibliotecas cliente de Azure Storage constan de 3 paquetes: Blob, File Share y
Queue. Para instalar el paquete Blob, ejecute:
Bash
pip install azure-storage-blob
Administración
Bash
pip install azure-mgmt-storage
Ejemplos
ﾉ Expandir tabla
Artículo Descripción
Introducción a Azure Blob Cree, lea, actualice, restrinja el acceso y elimine archivos y objetos
Storage en Python Azure Storage.
Administración de cuentas Crear, actualizar y eliminar cuentas de almacenamiento. Recupere y

de Azure Storage regenere las claves de acceso de la cuenta de almacenamiento.
Vea más código de Python ejemplo que puede usar en sus aplicaciones.
Problemas conocidos
Storage para Python.
beta del SDK

siguiente:
Consola
format.
Content-Length: 328
Date: Fri, 19 May 2023 17:10:33 GMT

RequestId:<REMOVED>
６ Colaborar con nosotros en

GitHub
El origen de este contenido se
puede encontrar en GitHub,
donde también puede crear y
revisar problemas y solicitudes
Para más información, consulte
nuestra guía para
colaboradores.
Comentarios de Azure SDK
for Python
Azure SDK for Python es un proyecto
de código abierto. Seleccione un
vínculo para proporcionar
comentarios:
 Abrir incidencia con la

documentación

el producto
Biblioteca de Azure Storage para
JavaScript
Artículo • 09/01/2024
Azure Storage es un servicio administrado por Microsoft que proporciona

almacenamiento en la nube de alta disponibilidad, seguro, duradero, escalable y
redundante. Las siguientes bibliotecas de JavaScript facilitan el consumo del servicio
Azure Storage.
Paquetes de cliente (12.X.X)

ﾉ Expandir tabla
Servicio Paquete de NPM Ejemplos Guía de introducción
Storage Blob @azure/storage- storage-blob- Lectura y escritura de objetos y

blob typescript- archivos de Blob de Azure
examples Storage
storage-blob-
JavaScript-
examples
Archivos de @azure/storage- storage-file-

almacenamiento file-share share-typescript-
examples
storage-file-
share-javascript-
examples
Storage Queue @azure/storage- storage-queue- Envío y recepción de mensajes

queue typescript- entre aplicaciones conectadas a
examples la nube con
storage-queue- Cola de Azure Storage
JavaScript-
examples
Storage Table azure-storage - Lectura y escritura de datos

(Heredado) estructurados de gran tamaño
con la tabla de Azure Storage
Tabla de datos @azure/data-table data-table- Lectura y escritura de datos

typescript- estructurados de gran tamaño
examples con la tabla de Azure Storage
data-table-
JavaScript-
examples
Instale el módulo npm con npm install seguido de package-name . Por ejemplo,
Bash
npm install @azure/storage-blob
y examine los ejemplos de los vínculos proporcionados en la tabla anterior.
Obtenga más información sobre los paquetes de cliente aquí: Bibliotecas de cliente de
Azure Storage para JavaScript .
Obtenga más guías de introducción en Examinar ejemplos de código .
Paquete de administración
Instalación del módulo npm

Instale el módulo npm de administración de Azure Storage.
Bash
npm install @azure/arm-storage
Ejemplo
Encontrará ejemplos de uso de este módulo en Node.js, así como aplicaciones de
explorador en el archivo Léame del módulo .
Problemas conocidos
Storage para JavaScript.

beta del SDK

siguiente:
Consola
format.
Content-Length: 328
Date: Fri, 19 May 2023 17:10:33 GMT

RequestId:<REMOVED>

GitHub for JavaScript
El origen de este contenido se Azure SDK for JavaScript es un
puede encontrar en GitHub, proyecto de código abierto.
donde también puede crear y Seleccione un vínculo para
revisar problemas y solicitudes proporcionar comentarios:
colaboradores.
el producto
Referencia de la API de REST de
proveedor de recursos de
Artículo • 26/07/2023
El proveedor de recursos de almacenamiento (SRP) permite administrar la cuenta de

almacenamiento y los recursos relacionados mediante programación.
El proveedor de recursos de almacenamiento requiere que se controle el control de

versiones de todas las solicitudes. Para realizar una solicitud en el SRP, debe especificar
la versión que desea usar para esa operación. Las versiones admitidas actualmente son:
2023-01-01
2022-09-01
2022-05-01
01-09-2021
2021-08-01
01-06-2021
2021-04-01
2021-02-01
01-01-2021
2020-08-01-preview
2019-06-01
01-04-2019
2018-11-01
2018-07-01
2018-03-01-preview
2018-02-01
2017-10-01
2017-06-01
2016-12-01
2016-05-01
2016-01-01
2015-06-15
2015-05-01-preview
biblioteca cliente de administración de
Microsoft Azure Storage para .NET
Artículo • 18/04/2023
Microsoft Azure Storage es un servicio administrado por Microsoft que proporciona

redundante.
Esta biblioteca admite la administración de recursos Microsoft Azure Storage, incluida la

creación de nuevas cuentas de almacenamiento.
Esta biblioteca sigue las nuevas directrices del SDK de Azure y proporciona muchas
funcionalidades principales:
- Support MSAL.NET, Azure.Identity is out of box for supporting MSAL.NET.

- Support [OpenTelemetry](https://opentelemetry.io/) for distributed
tracing.
- HTTP pipeline with custom policies.
- Better error-handling.
- Support uniform telemetry across all languages.
Introducción
Instalar el paquete
Instale la biblioteca de administración de Microsoft Azure Storage para .NET con
NuGet :
CLI de .NET
dotnet add package Azure.ResourceManager.Storage
Requisitos previos
En primer lugar, para instalar el paquete microsoft Azure Identity :
CLI de .NET
dotnet add package Azure.Identity
Configure una manera de autenticarse en Microsoft Azure con Azure Identity.
Estas son algunas opciones:
Mediante el inicio de sesión de la CLI de Azure.

A través de Visual Studio.
Establecer variables de entorno .
Puede encontrar más información y diferentes enfoques de autenticación mediante

Microsoft Azure Identity en este documento.
Autenticación del cliente

La opción predeterminada para crear un cliente autenticado es usar
DefaultAzureCredential . Dado que todas las API de administración pasan por el mismo
punto de conexión, para interactuar con los recursos, solo se tiene que crear un
ArmClient de nivel superior.
Para autenticarse en Microsoft Azure y crear un ArmClient , realice el código siguiente:
C#
using Azure.Identity;
using Azure.ResourceManager;
ArmClient armClient = new ArmClient(new DefaultAzureCredential());
Puede encontrar más documentación para la Azure.Identity.DefaultAzureCredential

clase en este documento.
Conceptos clave
Los conceptos clave del Microsoft Azure SDK para .NET se pueden encontrar aquí
Ejemplos
Administración de cuentas de almacenamiento .
Administración de contenedores de blobs .

Administración de recursos compartidos de archivos .
Si encuentra un error o tiene una sugerencia, abra un problema a través de
problemas de GitHub y asegúrese de agregar la etiqueta "Versión preliminar" al
problema.
Si necesita ayuda, compruebe las preguntas anteriores o realice otras nuevas en
StackOverflow mediante etiquetas de Azure y .NET.
Si tiene problemas con la autenticación, vaya a la documentación de
DefaultAzureCredential.
Pasos siguientes
Para obtener más información sobre el SDK de Microsoft Azure, consulte este sitio
web .
Contribuir
Para más información sobre cómo contribuir a este repositorio, consulte la guía de
contribución .
Este proyecto agradece las contribuciones y sugerencias. La mayoría de las

contribuciones requieren que acepte un Contrato de licencia para el colaborador (CLA)
que declara que tiene el derecho a concedernos y nos concede los derechos para usar
su contribución. Para más detalles, visite https://cla.microsoft.com .
Al enviar una solicitud de incorporación de cambios, un bot de CLA determinará

automáticamente si necesita proporcionar un CLA y decorar la solicitud de
incorporación de cambios correctamente (por ejemplo, etiqueta, comentario). Siga las
instrucciones que le dará el bot. Solo tendrá que realizar esta acción una vez en todos
los repositorios mediante nuestro CLA.
El proyecto ha adoptado el Código de conducta de código abierto de Microsoft . Para

más información, consulte las preguntas frecuentes del código de conducta o escriba
un correo electrónico a opencode@microsoft.com si tiene cualquier otra pregunta o
comentario.
Management
Reference
Packages
ﾉ Expand table
com.microsoft.azure.management.storage
para Python
Artículo • 09/01/2024
Paquetes de cliente (12.X.X): más reciente

ﾉ Expandir tabla

paquetes

almacenamiento
Storage File Data Lake (versión preliminar) Referencia PyPi GitHub
Paquetes de cliente (2.X.X): heredado

ﾉ Expandir tabla

paquetes

almacenamiento
Administración
ﾉ Expandir tabla
Administración del almacenamiento Referencia PyPi GitHub

Instalación de las bibliotecas
Cliente
Las bibliotecas cliente de Azure Storage constan de 3 paquetes: Blob, File Share y
Queue. Para instalar el paquete Blob, ejecute:
Bash
pip install azure-storage-blob
Administración
Bash
pip install azure-mgmt-storage
Ejemplos
ﾉ Expandir tabla
Artículo Descripción
Introducción a Azure Blob Cree, lea, actualice, restrinja el acceso y elimine archivos y objetos
Storage en Python Azure Storage.
Administración de cuentas Crear, actualizar y eliminar cuentas de almacenamiento. Recupere y

de Azure Storage regenere las claves de acceso de la cuenta de almacenamiento.
Vea más código de Python ejemplo que puede usar en sus aplicaciones.
Problemas conocidos
Storage para Python.
beta del SDK

siguiente:
Consola
format.
Content-Length: 328
Date: Fri, 19 May 2023 17:10:33 GMT

RequestId:<REMOVED>
６ Colaborar con nosotros en

GitHub
El origen de este contenido se
puede encontrar en GitHub,
donde también puede crear y
revisar problemas y solicitudes
nuestra guía para
colaboradores.
Comentarios de Azure SDK
for Python
Azure SDK for Python es un proyecto
de código abierto. Seleccione un
vínculo para proporcionar
comentarios:
 Abrir incidencia con la

documentación

el producto
Biblioteca de Azure Storage para
JavaScript
Artículo • 09/01/2024
Azure Storage es un servicio administrado por Microsoft que proporciona

redundante. Las siguientes bibliotecas de JavaScript facilitan el consumo del servicio
Azure Storage.
Paquetes de cliente (12.X.X)

ﾉ Expandir tabla
Storage Blob @azure/storage- storage-blob- Lectura y escritura de objetos y

blob typescript- archivos de Blob de Azure
examples Storage
storage-blob-
JavaScript-
examples
Archivos de @azure/storage- storage-file-

almacenamiento file-share share-typescript-
examples
storage-file-
share-javascript-
examples
Storage Queue @azure/storage- storage-queue- Envío y recepción de mensajes

queue typescript- entre aplicaciones conectadas a
examples la nube con
storage-queue- Cola de Azure Storage
JavaScript-
examples
Storage Table azure-storage - Lectura y escritura de datos

(Heredado) estructurados de gran tamaño
con la tabla de Azure Storage
Tabla de datos @azure/data-table data-table- Lectura y escritura de datos

typescript- estructurados de gran tamaño
examples con la tabla de Azure Storage
data-table-
JavaScript-
examples
Instale el módulo npm con npm install seguido de package-name . Por ejemplo,
Bash
npm install @azure/storage-blob
y examine los ejemplos de los vínculos proporcionados en la tabla anterior.
Obtenga más información sobre los paquetes de cliente aquí: Bibliotecas de cliente de
Azure Storage para JavaScript .
Obtenga más guías de introducción en Examinar ejemplos de código .
Paquete de administración
Instalación del módulo npm

Instale el módulo npm de administración de Azure Storage.
Bash
npm install @azure/arm-storage
Ejemplo
Encontrará ejemplos de uso de este módulo en Node.js, así como aplicaciones de
explorador en el archivo Léame del módulo .
Problemas conocidos
Storage para JavaScript.

beta del SDK

siguiente:
Consola
format.
Content-Length: 328
Date: Fri, 19 May 2023 17:10:33 GMT

RequestId:<REMOVED>

GitHub for JavaScript
El origen de este contenido se Azure SDK for JavaScript es un
puede encontrar en GitHub, proyecto de código abierto.
donde también puede crear y Seleccione un vínculo para
revisar problemas y solicitudes proporcionar comentarios:
colaboradores.
el producto
Guía para desarrolladores de Spring
Cloud para desarrolladores de Azure
Artículo • 23/10/2023
Este artículo se aplica a: ✔️Versión 4.14.0 ✔️versión 5.8.0
Spring es un marco de trabajo de aplicaciones de código abierto desarrollado por

VMware que ofrece un método modular simplificado para crear aplicaciones Java.
Spring Cloud Azure es un proyecto de código abierto que proporciona una integración
perfecta de Spring con Azure.
Para obtener más información sobre las versiones admitidas, vea Asignación de
versiones de Spring.
Obtener ayuda
Si tiene alguna pregunta sobre esta documentación, cree un problema de GitHub en
uno de los siguientes repositorios de GitHub. También se admiten las solicitudes de
incorporación de cambios.
ﾉ Expandir tabla
Repositorios de GitHub Descripción
Azure/azure-sdk-for-java Este repositorio contiene el código fuente.
MicrosoftDocs/azure-dev-docs Este repositorio contiene la documentación.
Novedades de la versión 4.0 desde la versión

3.10.x
En esta documentación se tratan los cambios realizados en la versión 4.0 desde la
versión 3.10. Esta versión principal aporta una mejor seguridad, dependencias más
ajustadas, compatibilidad con la preparación de producción y mucho más.
 Sugerencia
Para obtener más información sobre la migración a la versión 4.0, consulte Guía de
migración para la versión 4.0.
En la lista siguiente se resumen algunos de los cambios que proporciona Spring Cloud
Azure 4.0:
Una experiencia de desarrollo unificada, con el nombre de proyecto unificado, el

identificador de artefacto y las propiedades.
Administración simplificada de dependencias mediante una sola spring-cloud-
azure-dependencies boM.
Se expandió Soporte técnico de Azure en Spring Initializr para cubrir Kafka,

Event Hubs, Azure Cache for Redis y App de Azure Configuration.
Rediseñó las dependencias del módulo Spring para quitar capas y entrelazamiento
excesivos.
Compatibilidad de identidad administrada con App de Azure Configuración, Event
Hubs, Service Bus, Azure Cosmos DB, Key Vault, Storage Blob y Cola de Storage.
Compatibilidad continua con los métodos de autenticación en el SDK de Azure
subyacente de nuestras bibliotecas de Spring, como el token de SAS y la
autenticación de credenciales de token con Service Bus y Event Hubs.
La cadena de credenciales ahora está habilitada de forma predeterminada, lo que
permite a las aplicaciones obtener credenciales de las propiedades de la
aplicación, las variables de entorno, la identidad administrada, los IDE, etc. Para
más información, consulte la sección DefaultAzureCredential de la biblioteca
cliente de Azure Identity para Java.
Control de acceso pormenorizado en el nivel de recurso (como la cola de Service
Bus) para permitir una mejor gobernanza de seguridad y cumplimiento de las
directivas de TI.
Más opciones expuestas en una forma de spring-idioma a través de una cobertura
de configuración automática significativamente mejorada de los clientes de Azure
SDK para escenarios sincrónicos y asincrónicos.
Se han agregado indicadores de estado para App de Azure Configuration, Event
Hubs, Azure Cosmos DB, Key Vault, Storage Blob, Storage Queue y Storage File.
Compatibilidad de Spring Cloud Sleuth con todos los SDK de Azure basados en
HTTP.
Guía de migración para la versión 4.0

Para obtener más información sobre la migración a la versión 4.0, consulte Guía de
migración para la versión 4.0.
Introducción
Configuración de dependencias
Lista de materiales (L. MAT)
XML
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.azure.spring</groupId>
<artifactId>spring-cloud-azure-dependencies</artifactId>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
７ Nota
Si usa Spring Boot 3.x, asegúrese de establecer la spring-cloud-azure-dependencies

versión 5.8.0 en . Para obtener más información sobre la spring-cloud-azure-
dependencies versión, consulte Qué versión de Spring Cloud Azure debería usar .
Dependencias de inicio
Spring Cloud Azure Starters es un conjunto de descriptores de dependencia
convenientes que se van a incluir en la aplicación. Cada inicio contiene todas las
dependencias y dependencias transitivas necesarias para empezar a usar su módulo de
Azure de Spring Cloud correspondiente. Estos inicios aumentan el desarrollo de
aplicaciones de Spring Boot con servicios de Azure.
Por ejemplo, si desea empezar a usar Spring y Azure Cosmos DB para la persistencia de
datos, incluya la dependencia en el spring-cloud-azure-starter-cosmos proyecto.
En la tabla siguiente se enumeran los inicios de aplicaciones proporcionados por Spring

Cloud Azure en el com.azure.spring grupo:
ﾉ Expandir tabla
Nombre Descripción
spring-cloud-azure-starter El inicio principal, incluida la compatibilidad con la configuració

n automática.
spring-cloud-azure-starter-acti El inicio para usar microsoft Entra ID con Spring Security.

ve-directory
spring-cloud-azure-starter-acti El inicio para usar Azure Active Directory B2C con Spring Securit
ve-directory-b2c y.
spring-cloud-azure-starter-ap El inicio para usar App de Azure Configuration.

pconfiguration
spring-cloud-azure-starter-cos El inicio para usar Azure Cosmos DB.

mos
spring-cloud-azure-starter-eve El inicio para usar Azure Event Hubs.

nthubs
spring-cloud-azure-starter-key Inicio para usar Azure Key Vault.

vault
spring-cloud-azure-starter-key El inicio para usar secretos de Azure Key Vault.

vault-secrets
spring-cloud-azure-starter-key El inicio para usar certificados de Azure Key Vault.

vault-certificates
spring-cloud-azure-starter-ser El inicio para usar Azure Service Bus.

vicebus
spring-cloud-azure-starter-ser El inicio para usar Azure Service Bus y JMS.

vicebus-jms
spring-cloud-azure-starter-sto El inicio para usar Azure Storage.

rage
spring-cloud-azure-starter-sto El inicio para usar Azure Storage Blob.

rage-blob
spring-cloud-azure-starter-sto El inicio para usar el recurso compartido de archivos de Azure St

rage-file-share orage.
spring-cloud-azure-starter-sto El inicio para usar la cola de Azure Storage.

rage-queue
spring-cloud-azure-starter-act El inicio para usar el accionador de Spring Boot, que proporcion

uador a características listas para producción.
En la tabla siguiente se enumeran los inicios para la compatibilidad con Spring Data:
ﾉ Expandir tabla
Nombre Descripción
spring-cloud-azure-starter-data-cosmos El inicio para usar Spring Data para Azure Cosmos DB.
En la tabla siguiente se enumeran los inicios para la compatibilidad con Spring

Integration:
ﾉ Expandir tabla
Nombre Descripción
spring-cloud-azure-starter-integration-eve El inicio para usar Azure Event Hubs e Integración d

nthubs e Spring.
spring-cloud-azure-starter-integration-ser El inicio para usar Azure Service Bus e Integración d

vicebus e Spring.
spring-cloud-azure-starter-integration-stor Inicio para usar La cola de Azure Storage e Integraci

age-queue ón de Spring.
En la tabla siguiente se enumeran los inicios para la compatibilidad con Spring Cloud
Stream:
ﾉ Expandir tabla
Nombre Descripción
spring-cloud-azure-starter-stream-ev Los inicios para usar Azure Event Hubs y Spring Cloud Str
enthubs eam Binder.
spring-cloud-azure-starter-stream-ser El inicio para usar Azure Service Bus y Spring Cloud Strea
vicebus m Binder.
En la tabla siguiente se enumeran los inicios para la compatibilidad con MySQL:
ﾉ Expandir tabla
Nombre Descripción
spring-cloud-azure-starter-jd Los inicios para usar Azure MySQLs y JDBC a través de la autentica
bc-mysql ción de Microsoft Entra.
En la tabla siguiente se enumeran los inicios para la compatibilidad con PostgreSQL:

ﾉ Expandir tabla
Nombre Descripción
spring-cloud-azure-starter-jdb Los inicios para usar Azure PostgreSQL y JDBC a través de la aut
c-postgresql enticación de Microsoft Entra.
Aprendizaje de Spring Cloud en Azure

Hemos preparado una lista completa de ejemplos para mostrar el uso. Puede encontrar
estos ejemplos en Spring Cloud Azure Samples (Ejemplos de Azure de Spring Cloud).
Artículo • 19/10/2023
Vea Supervisión de Azure Files para más información sobre la recopilación y el análisis de datos de supervisión de Azure Files.
Se aplica a
Métricas
En las tablas siguientes se indican las métricas de plataforma recopiladas para Azure Files.
Métricas de capacidad
Los valores de las métricas de capacidad se actualizan diariamente (hasta 24 horas). El intervalo de agregación define el intervalo de tiempo
para el que se presentan los valores de las métricas. El intervalo de agregación que se admite en las métricas de capacidad es una hora
(PT1H).
Azure Files proporciona las siguientes métricas de capacidad en Azure Monitor.
Nivel de cuenta
En esta tabla se muestran métricas de nivel de cuenta.
Métrica Descripción
UsedCapacity La cantidad de almacenamiento que utiliza la cuenta de almacenamiento. En las cuentas de almacenamiento estándar, es la suma de la
capacidad usada por un blob, una tabla, un archivo y una cola. Tanto en las cuentas de almacenamiento Premium como en las cuentas de
Blob Storage, coincide con BlobCapacity.
Unidad: bytes
Tipo de agregación: promedio
Ejemplo de valor: 1024
Azure Files
En esta tabla se muestran las métricas admitidas para Azure Files.
FileCapacity La cantidad de almacenamiento de archivos que utiliza la cuenta de almacenamiento.
Unidad: bytes
Dimensiones: FileShare, Tier
FileCount El número de archivos que hay en la cuenta de almacenamiento.
Unidad: recuento
Dimensiones: FileShare, Tier
FileShareCapacityQuota Límite superior de la cantidad de almacenamiento que puede usar el servicio Azure Files en bytes.
Unidad: bytes
FileShareCount El número de recursos compartidos de archivo que hay en la cuenta de almacenamiento.
Unidad: recuento
FileShareProvisionedIOPS El número de IOPS aprovisionadas en un recurso compartido de archivos. Esta métrica solo se puede aplicar a un
almacenamiento de archivos Premium.
Unidad: CountPerSecond
Tipo de agregación: Average
FileShareSnapshotCount Número de instantáneas presentes en el recurso compartido en el servicio Azure Files de la cuenta de
almacenamiento.
Unidad: recuento
FileShareSnapshotSize Cantidad de almacenamiento que usan las instantáneas del servicio Azure Files de la cuenta de almacenamiento.
Unidad: bytes
FileShareMaxUsedIOPS Número máximo de IOPS usadas en la granularidad de tiempo más baja de 1 minuto para el recurso compartido de
archivos Premium en la cuenta de almacenamiento de archivos Premium.
Tipo de agregación: Max
FileShareMaxUsedBandwidthMiBps El número máximo de ancho de banda usado en MiB/s en la granularidad de tiempo más baja de 1 minuto para el
recurso compartido de archivos Premium en la cuenta de almacenamiento de archivos Premium.
Tipo de agregación: Max
Métricas de transacciones
Se emiten en todas las solicitudes enviadas a una cuenta de almacenamiento de Azure Storage a Azure Monitor. En caso de que no haya
actividad en la cuenta de almacenamiento, no habrá ningún dato en las métricas de transacciones del período. Todas las métricas de
transacción están disponibles en el nivel de cuenta y de servicio de Azure Files. El intervalo de agregación define el intervalo de tiempo en
el que se presentan los valores de las métricas. Los intervalos de agregación compatible para todas las métricas de transacciones son PT1H
y PT1M.
Azure Storage proporciona las siguientes métricas de transacciones en Azure Monitor.
Transacciones El número de solicitudes realizadas a un servicio de almacenamiento o la operación de API especificada. Este número incluye
solicitudes correctas y con errores, así como las solicitudes que generaron errores.
Unidad: Count
Tipo de agregación: total
Dimensiones aplicables: ResponseType, GeoType, ApiName y Authentication (Definición)
Entrada La cantidad de datos de entrada. Este número incluye la entradas desde un cliente externo en Azure Storage, así como la entrada
dentro de Azure.
Unidad: bytes
Dimensiones aplicables: GeoType, ApiName y Authentication (Definición)
Salida La cantidad de datos de salida. Este número incluye la salida de un cliente externo en Azure Storage, así como la salida dentro de
Azure. En consecuencia, este número no refleja las salidas facturables.
Unidad: bytes
SuccessServerLatency El tiempo medio que se usa para que Azure Storage procese una solicitud correcta . Este valor no incluye la latencia de red
especificada en SuccessE2ELatency.
Unidad: milisegundos
SuccessE2ELatency La latencia media de un extremo a otro de las solicitudes correctas realizadas a un servicio de almacenamiento o a la operación de
API especificada. Este valor incluye el tiempo de procesamiento requerido dentro de Azure Storage para leer la solicitud, enviar la
respuesta y recibir la confirmación de la respuesta. La diferencia entre los valores de SuccessE2ELatency y SuccessServerLatency es la
latencia que probablemente causan la red y el cliente.
Unidad: milisegundos
Disponibilidad El porcentaje de disponibilidad para el servicio de almacenamiento o la operación de API especificada. Para calcular la disponibilidad
hay que tomar el número total de solicitudes facturables y dividirlo por el número de solicitudes aplicables, incluidas las solicitudes
que generaron errores inesperados. Todos los errores inesperados reducen la disponibilidad del servicio de almacenamiento o de la
operación de API especificada.
Unidad: porcentaje
Ejemplo de valor: 99,99
Dimensiones de métricas
Azure Files admite las siguientes dimensiones para las métricas en Azure Monitor.
７ Nota
La dimensión de recurso compartido de archivos no está disponible para recursos compartidos de archivos estándar (solo para
recursos compartidos de archivos prémium). Al usar recursos compartidos de archivos estándar, las métricas proporcionadas son para
todos los recursos compartidos de archivos de la cuenta de almacenamiento. Para obtener métricas por recurso compartido para
recursos compartidos de archivos estándar, cree un recurso compartido de archivos por cuenta de almacenamiento.
Nombre de Descripción
dimensión
GeoType Transacción de clúster principal o secundario. Los valores disponibles incluyen Principal y Secundario. Se aplica al Almacenamiento con
redundancia geográfica con acceso de lectura (RA-GRS) al leer objetos de un inquilino secundario.
ResponseType Tipo de respuesta de la transacción. Los valores disponibles son:
ServerOtherError: todos los errores del servidor, excepto los descritos.

ServerBusyError: solicitud autenticada que devolvió un código de estado HTTP 503.
ServerTimeoutError: solicitud autenticada que ha superado el tiempo de espera y que devolvió un código de estado HTTP 500. El
tiempo de espera se superó debido a un error del servidor.
AuthenticationError: el servidor no ha podido autenticar la solicitud.
AuthorizationError: solicitud autenticada errónea debido a un acceso no autorizado de los datos o a un error de autorización.
NetworkError: solicitud autenticada errónea debido a errores de red. Normalmente se produce cuando un cliente cierra
prematuramente una conexión antes de que se haya superado el tiempo de expiración.
ClientAccountBandwidthThrottlingError: la solicitud está limitada por el ancho de banda para superar los límites de escalabilidad
de la cuenta de almacenamiento .
ClientAccountRequestThrottlingError: la solicitud está limitada por la tasa de solicitud para superar los límites de escalabilidad de la
cuenta de almacenamiento .
ClientThrottlingError: Otro error de limitación del lado del cliente. ClientAccountBandwidthThrottlingError y
ClientAccountRequestThrottlingError se excluyen.
ClientShareEgressThrottlingError: aplicable solo a los recursos compartidos de archivos Premium. Otro error de limitación del lado
del cliente. Error en la solicitud debido a que el límite de ancho de banda de salida supera los límites de recurso compartido. Se excluye
ClientAccountBandwidthThrottlingError.
ClientShareIngressThrottlingError: aplicable solo a los recursos compartidos de archivos Premium. Otro error de limitación del lado
del cliente. Error en la solicitud debido a que el límite de ancho de banda de entrada supera los límites de recurso compartido. Se
excluye ClientAccountBandwidthThrottlingError.
ClientShareIopsThrottlingError: Otro error de limitación del lado del cliente. Error en la solicitud debido a la limitación de IOPS. Se
excluye ClientAccountRequestThrottlingError.
Nombre de Descripción
dimensión
ClientTimeoutError: solicitud autenticada que ha superado el tiempo de espera y que devolvió un código de estado HTTP 500. Si el
tiempo de expiración de la red del cliente o el tiempo de expiración de la solicitud se establece en un valor menor de lo que espera el
servicio de almacenamiento, es un tiempo de expiración esperado. De lo contrario, se notifica como un error ServerTimeoutError.
ClientOtherError: todos los errores del lado cliente, excepto los descritos.
Correcto: solicitud correcta.
SuccessWithThrottling: solicitud correcta cuando un cliente SMB obtiene una limitación en el primer intento, pero se ejecuta
correctamente después de varios reintentos.
SuccessWithShareEgressThrottling: aplicable solo a los recursos compartidos de archivos Premium. Solicitud correcta cuando un
cliente SMB obtiene una limitación en el primer intento debido al límite de ancho de banda de salida, pero se ejecuta correctamente
después de varios reintentos.
SuccessWithShareIngressThrottling: aplicable solo a los recursos compartidos de archivos Premium. Solicitud correcta cuando un
cliente SMB obtiene una limitación en el primer intento debido al límite de ancho de banda de entrada, pero se ejecuta correctamente
después de varios reintentos.
SuccessWithShareIopsThrottling: solicitud correcta cuando un cliente SMB obtiene una limitación en los primeros intentos debido
a la limitación de IOPS, pero se ejecuta correctamente después de varios reintentos.
ApiName El nombre de la operación. Si se produce un error antes de que se identifique el nombre de la operación, este aparece como
"Unknown" (Desconocido). Para más información sobre el error, puede usar el valor de la dimensión ResponseType.
Autenticación Tipos de autenticación que se usan en las transacciones. Los valores disponibles son:
AccountKey: la transacción se autentica con la clave de la cuenta de almacenamiento.
SAS: la transacción se autentica con firmas de acceso compartido.
OAuth: la transacción se autentica con tokens de acceso de OAuth.
Anonymous: la transacción se solicita de forma anónima. No incluye las solicitudes preparatorias.
AnonymousPreflight: la transacción es una solicitud preparatoria.
TransactionType Tipo de transacción. Los valores disponibles son:

Usuario: el cliente realizó la transacción.
Sistema: el proceso del sistema realizó la transacción.
Registros del recurso

En la tabla siguiente se indican las propiedades de los registros de recursos de Azure Storage cuando se recopilan en registros de Azure
Monitor o Azure Storage. Las propiedades describen la operación, el servicio y el tipo de autorización que se ha usado para realizar la
operación.
Campos que describen la operación
Propiedad Descripción
time Hora universal coordinada (UTC) a la que el almacenamiento ha recibido la solicitud. Por ejemplo: 2018/11/08 21:09:36.6900118 .
resourceId Identificador de recurso de la cuenta de almacenamiento. Por ejemplo: /subscriptions/208841be-a4v3-4234-9450-

08b90c09f4/resourceGroups/
myresourcegroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount/storageAccounts/blobServices/default
category Categoría de la operación solicitada. Por ejemplo: StorageRead , StorageWrite o StorageDelete .
operationName Tipo de operación REST realizada.

Puede encontrar una lista completa de operaciones en el tema Operaciones y mensajes de estado registrados de Storage Analytics.
operationVersion Versión del servicio de almacenamiento especificada al realizar la solicitud. Es equivalente al valor del encabezado x-ms-version. Por
ejemplo: 2017-04-17 .
schemaVersion Versión del esquema del registro. Por ejemplo: 1.0 .
statusCode Código de estado HTTP o SMB de la solicitud. Si se interrumpe la solicitud HTTP, este valor se podría establecer en Unknown .
Por ejemplo: 206
statusText Estado de la operación solicitada. Puede encontrar una lista completa de mensajes de estado en Operaciones y mensajes de estado
registrados por Storage Analytics. En la versión 2017-04-17 y posteriores, el mensaje de estado ClientOtherError no se usa. En su lugar,
este campo contiene un código de error. Por ejemplo: SASSuccess
durationMs Tiempo total, expresado en milisegundos, necesario para realizar la operación solicitada. Incluye el tiempo necesario para leer la
solicitud entrante y para enviar la respuesta al solicitante. Por ejemplo: 12 .
callerIpAddress Dirección IP del solicitante, incluido el número de puerto. Por ejemplo: 192.100.0.102:4362 .
correlationId Identificador que se usa para poner en correlación registros entre recursos. Por ejemplo: b99ba45e-a01e-0042-4ea6-772bbb000000 .
ubicación Ubicación de la cuenta de almacenamiento. Por ejemplo: North Europe .

protocolo Protocolo que se usa en la operación. Por ejemplo: HTTP , HTTPS , SMB o NFS
uri Identificador uniforme de recursos que se solicita.
Campos que describen cómo se ha autenticado la operación
identity/type Tipo de autenticación que se ha usado para realizar la solicitud.

Por ejemplo: OAuth , Kerberos , SAS Key , Account Key o Anonymous
identity/tokenHash El hash SHA-256 del token de autenticación utilizado en la solicitud.

Cuando el tipo de autenticación es Account Key , el formato es "clave1 | clave2 (hash SHA 256 de la clave)".
Por ejemplo: key1(5RTE343A6FEB12342672AFD40072B70D4A91BGH5CDF797EC56BF82B2C3635CE) .
Cuando el tipo de autenticación es SAS Key , el formato es "clave1 | clave2 (hash SHA 256 de la clave),SasSignature(hash SHA 256 d
Por ejemplo:
key1(0A0XE8AADA354H19722ED12342443F0DC8FAF3E6GF8C8AD805DE6D563E0E5F8A),SasSignature(04D64C2B3A704145C9F1664F201123467A74D7
Cuando el tipo de autenticación es OAuth , el formato es "hash SHA 256 del token de OAuth".
Por ejemplo: B3CC9D5C64B3351573D806751312317FE4E910877E7CBAFA9D95E0BE923DD25C
No hay campo tokenHash para otros tipos de autenticación.
authorization/action Acción asignada a la solicitud.
authorization/denyAssignmentId La fecha en formato GUID cuando una asignación de denegación deniega el acceso.
La asignación de denegación puede ser de Azure Blueprints o de una aplicación administrada.
Para más información sobre las asignaciones de denegación, consulte Descripción de las asignaciones de denegación de Azure
authorization/reason Motivo de la autorización del resultado de la solicitud.

Por ejemplo: Policy , NoApplicablePolicy o MissingAttributes
authorization/result Autorización del resultado de la solicitud.

Por ejemplo, Granted o Denied .
authorization/roleAssignmentId Identificador de la asignación de roles.

Por ejemplo: 4e2521b7-13be-4363-aeda-111111111111 .
authorization/roleDefinitionId Identificador de la definición de roles.

Por ejemplo: ba92f5b4-2d11-453d-a403-111111111111 .
authorization/type Origen del resultado de la autorización para la solicitud.

Por ejemplo, RBAC o ABAC .
principals/id Identificador de la entidad de seguridad.

Por ejemplo: a4711f3a-254f-4cfb-8a2d-111111111111 .
principals/type Tipo de la entidad de seguridad.

Por ejemplo: ServicePrincipal .
properties/metricResponseType Respuesta de la transacción de métricas.

Para obtener ejemplos, consulte la dimensión de métricas ResponseType para el servicio de almacenamiento:
blobs
files
queues
tablas
properties/objectKey Ruta de acceso al objeto al que se accede.

Por ejemplo: samplestorageaccount/container1/blob.png .
requester/appID Identificador de la aplicación de Open Authorization (OAuth) que se usa como solicitante.
Por ejemplo: d3f7d5fe-e64a-4e4e-871d-333333333333 .
requester/audience Audiencia de OAuth de la solicitud.

Por ejemplo: https://storage.azure.com .
requester/objectId Identificador de objeto de OAuth de la solicitud. En el caso de la autenticación Kerberos, representa al identificador de objeto del
Kerberos.
Por ejemplo: 0e0bf547-55e5-465c-91b7-2873712b249c .
requester/tenantId Identificador de inquilino de OAuth de la identidad.

Por ejemplo: 72f988bf-86f1-41af-91ab-222222222222 .
requester/tokenIssuer Emisor de token de OAuth.

Por ejemplo: https://sts.windows.net/72f988bf-86f1-41af-91ab-222222222222/ .
requester/upn Nombre principal de usuario (UPN) del solicitante.

Por ejemplo: someone@contoso.com .
requester/userName Este campo está reservado para uso interno exclusivamente.
Campos que describen el servicio
accountName El nombre de la cuenta de almacenamiento. Por ejemplo: mystorageaccount .
requestUrl Dirección URL que se solicita.
userAgentHeader Valor del encabezado User-Agent, entre comillas. Por ejemplo: WA-Storage/6.2.0 (.NET CLR 4.0.30319.42000; Win32NT
6.2.9200.0) .
referrerHeader Valor del encabezado Referrer. Por ejemplo: http://contoso.com/about.html .
clientRequestId Valor de encabezado x-ms-client-request-id de la solicitud. Por ejemplo: 360b66a6-ad4f-4c4a-84a4-0ad7cb44f7a6 .
etag Identificador de la ETag del objeto devuelto, entre comillas. Por ejemplo: 0x8D101F7E4B662C4 .
serverLatencyMs Tiempo total, expresado en milisegundos, necesario para realizar la operación solicitada. Este valor no incluye la latencia de red
(el tiempo necesario para leer la solicitud entrante y enviar la respuesta al solicitante). Por ejemplo: 22 .
serviceType Servicio asociado a esta solicitud. Por ejemplo: blob , table , files o queue .
operationCount Número de cada operación registrada implicada en la solicitud. Este recuento comienza con un índice de 0 . Algunas solicitudes
requieren más de una operación. La mayoría de las solicitudes solo realizan una operación. Por ejemplo: 1 .
requestHeaderSize Tamaño del encabezado de la solicitud expresado en bytes. Por ejemplo: 578 .
Si una solicitud no se realiza correctamente, este valor puede estar vacío.
requestBodySize Tamaño expresado en bytes de los paquetes de la solicitud leídos por el servicio de almacenamiento.
Por ejemplo: 0 .
responseHeaderSize Tamaño del encabezado de la respuesta expresado en bytes. Por ejemplo: 216 .
responseBodySize Tamaño de los paquetes de respuesta escritos por el servicio de almacenamiento, en bytes. Si una solicitud no se realiza
correctamente, este valor puede estar vacío. Por ejemplo: 216 .
requestMd5 Valor del encabezado Content-MD5 o x-ms-content-md5 de la solicitud. El valor del hash MD5 especificado en este campo
representa el contenido de la solicitud. Por ejemplo: 788815fd0198be0d275ad329cafd1830 .
Este campo puede estar vacío.
serverMd5 Valor del hash MD5 calculado por el servicio de almacenamiento. Por ejemplo: 3228b3cf1069a5489b298446321f8521 .
Este campo puede estar vacío.
lastModifiedTime Hora de la última modificación del objeto devuelto. Por ejemplo: Tuesday, 09-Aug-11 21:13:26 GMT .
Este campo está vacío en el caso de operaciones que pueden devolver varios objetos.
conditionsUsed Lista separada por punto y coma de pares clave-valor que representan una condición. Las condiciones pueden ser cualquiera de
las siguientes:
If-Modified-Since
If-Unmodified-Since
If-Match
If-None-Match
Por ejemplo: If-Modified-Since=Friday, 05-Aug-11 19:11:54 GMT .
contentLengthHeader Valor del encabezado Content-Length de la solicitud enviada al servicio de almacenamiento. Si la solicitud se ha realizado
correctamente, este valor es igual a requestBodySize. Si la solicitud no se ha realizado correctamente, este valor puede no ser
igual a requestBodySize, o puede estar vacío.
tlsVersion Versión de TLS usada en la conexión de la solicitud. Por ejemplo: TLS 1.2 .
smbTreeConnectID treeConnectId del Bloque de mensajes del servidor (SMB) establecido en el momento de la conexión del árbol. Por ejemplo:
0x3
smbPersistentHandleID Identificador de manipulador persistente de una solicitud CREATE de SMB2 que sobrevive a las reconexiones de red. Con
referencia en MS-SMB2 2.2.14.1 como SMB2_FILEID.Persistent. Por ejemplo: 0x6003f
smbVolatileHandleID Identificador de manipulador volátil de una solicitud CREATE de SMB2 que se recicla en las reconexiones de red. Con referencia
en MS-SMB2 2.2.14.1 como SMB2_FILEID.Volatile. Por ejemplo: 0xFFFFFFFF00000065
smbMessageID Conexión con respecto a MessageId. Por ejemplo: 0x3b165
smbCreditsConsumed Entrada o salida consumida por la solicitud, en unidades de 64 k. Por ejemplo: 0x3
smbCommandDetail Más información sobre esta solicitud específica en lugar del tipo general de solicitud. Por ejemplo: 0x2000 bytes at offset
0xf2000
smbFileId FileId asociado al archivo o directorio. Más o menos análogo a un elemento FileId de NTFS. Por ejemplo: 0x9223442405598953
smbSessionID El elemento SessionId de SMB2 establecido en el momento de la configuración de la sesión. Por ejemplo: 0x8530280128000049
smbCommandMajor Valor de SMB2_HEADER.Command. Actualmente, se trata de un número entre 0 y 18, ambos incluidos. Por ejemplo: 0x6
uint32
smbCommandMinor Subclase de SmbCommandMajor, cuando sea conveniente. Por ejemplo: DirectoryCloseAndDelete
Consulte también
Vea Supervisión de Azure Files para obtener una descripción de la supervisión de Azure Storage.
Para más información sobre la supervisión de recursos de Azure, consulte Supervisión de recursos de Azure con Azure Monitor.
El almacenamiento con redundancia de
zona de Azure Files para recursos
compartidos de archivos premium
Artículo • 22/11/2023
El almacenamiento con redundancia de zona (ZRS) replica la cuenta de almacenamiento

de forma sincrónica en tres zonas de disponibilidad de Azure en la región primaria.
Se aplica a
Cuentas de recursos compartidos de archivos

premium
ZRS es compatible con recursos compartidos de archivos de Azure Premium a través del
tipo de cuenta de almacenamiento FileStorage .
ZRS para recursos compartidos de archivos premium está disponible para un

subconjunto de regiones de Azure:
(África) Norte de Sudáfrica

(Asia Pacífico) Este de Australia
(Asia Pacífico) Este de Japón
(Asia Pacífico) Norte de China 3
(Asia Pacífico) Sudeste de Asia
(Asia Pacífico) Centro de Corea del Sur
(Asia Pacífico) Este de Asia
(Asia Pacífico) Centro de la India
(Europa) Centro de Francia
(Europa) Norte de Europa
(Europa) Oeste de Europa
(Europa) Sur de Reino Unido
(Europa) Centro de Polonia
(Europa) Este de Noruega
(Europa) Centro de Suecia
(Europa) Norte de Suiza
(Oriente Medio) Centro de Catar
(Oriente Medio) Norte de Emiratos Árabes Unidos
(Norteamérica) Este de EE. UU.
(Norteamérica) Este de EE. UU. 2
(Norteamérica) Oeste de EE. UU. 2
(Norteamérica) Oeste de EE. UU. 3
(Norteamérica) Centro-sur de EE. UU.
(Sudamérica) Sur de Brasil
Consulte también
Tipos de recursos Microsoft.Storage
Artículo • 20/07/2023
En este artículo se enumeran las versiones disponibles para cada tipo de recurso.
Para obtener una lista de los cambios en cada versión de api, consulte registro de
cambios.
Tipos de recursos y versiones

Tipos Versiones
locations/deletedAccounts 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
storageAccounts 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
storageAccounts/blobServices 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
storageAccounts/blobServices/containers 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
Tipos Versiones
2021-02-01
01-01-2021
storageAccounts/blobServices/containers/immutabilityPolicies 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
storageAccounts/encryptionScopes 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
storageAccounts/fileServices 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
storageAccounts/fileServices/shares 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
storageAccounts/inventoryPolicies 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
Tipos Versiones
storageAccounts/localUsers 2022-09-01
2022-05-01
01-09-2021
2021-08-01
storageAccounts/managementPolicies 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
storageAccounts/objectReplicationPolicies 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
storageAccounts/privateEndpointConnections 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
storageAccounts/queueServices 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
storageAccounts/queueServices/queues 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
Tipos Versiones
2021-02-01
01-01-2021
storageAccounts/tableServices 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
storageAccounts/tableServices/tables 2022-09-01
2022-05-01
01-09-2021
2021-08-01
2021-06-01
2021-04-01
2021-02-01
01-01-2021
Videos de Azure Files y Azure File Sync
Artículo • 02/08/2023
Si no está familiarizado con Azure Files y File Sync o desea profundizar su comprensión,
este artículo proporciona una lista completa del contenido de vídeo publicado a lo largo
del tiempo. Es posible que algunos vídeos no reflejen las actualizaciones más recientes.
Lista de vídeos
How Azure Files can help protect against ransomware and acciden…
acciden…
Cómo Azure Files puede ayudar a proteger contra el ransomware y la pérdida

accidental de datos

Unir un dominio de reemplazar de Azure con Active Directory local y reemplazar el
servidor de archivos por el recurso compartido de archivos de Azure
How to mount an Azure Files share in Windows | Azure Tips and Tri…
Tri…
Montar un recurso compartido de archivos Azure en Windows
NFS 4.1 for Azure file shares
NFS 4.1 para recurso compartido de Azure

Setup Azure File Sync
Cómo configurar Azure File Sync
Integrating HPC Pack with Azure Files
Integración del paquete de HPC con Azure Files

Comparación entre Azure NetApp Files
y Azure Files
Artículo • 23/10/2023
En este artículo se proporciona una comparación entre Azure Files y Azure NetApp Files.
La mayoría de las cargas de trabajo que requieren almacenamiento de archivos en la

nube funcionan bien tanto en Azure Files como en Azure NetApp Files. Para ayudar a
determinar la mejor opción para la carga de trabajo, revise la información
proporcionada en este artículo. Para obtener más información, vea la documentación de
Azure Files y Azure NetApp Files, así como la sesión Almacenamiento compartido para
todas las cargas de trabajo de archivos empresariales , en la que se describe la
elección entre Azure Files y Azure NetApp Files.
Características
Category Azure Files Azure NetApp Files
Descripción Azure Files es un servicio de Azure NetApp Files es un servicio NAS

clase empresarial totalmente (almacenamiento conectado a la red) de
administrado y de alta nivel empresarial, de alta disponibilidad y
disponibilidad que está totalmente administrado, que puede
optimizado para cargas de administrar las cargas de trabajo más
trabajo de acceso aleatorio con exigentes, de alto rendimiento y baja
actualizaciones de datos latencia, que requieren funcionalidades
locales. avanzadas de administración de datos.
Permite la migración de cargas de
Azure Files se basa en la misma trabajo, que se consideran "que no se
plataforma de Azure Storage pueden migrar" sin él.
que otros servicios como Azure
Blobs. Azure NetApp Files se basa en un equipo
sin sistema operativo de NetApp con
sistema operativo de almacenamiento
ONTAP que se ejecuta dentro del centro
de datos de Azure para proporcionar una
experiencia coherente de Azure y un
rendimiento parecido al de un entorno
local.
Protocolos Premium Todos los niveles
SMB 2.1, 3.0, 3.1.1 SMB 2.1, 3.x (incluida la

NFSv4.1 disponibilidad continua de SMB
REST opcionalmente)
NFSv3, NFSv4.1
Estándar Acceso de protocolo dual
(NFSv3/SMB y NFSv4.1/SMB)
SMB 2.1, 3.0, 3.1.1
REST
Para más información, consulte cómo
crear volúmenes NFS, SMB o de
Para más información, consulte protocolo doble.
los protocolos de recursos
compartidos de archivos
disponibles.
Disponibilidad Premium Todos los niveles

regional
Más de 30 regiones Más de 40 regiones
Estándar Para obtener más información, vea

Productos disponibles por región .
Todas las regiones
Para obtener más información,

vea Productos disponibles por
región .
Redundancia Premium Todos los niveles
LRS Alta disponibilidad local integrada

ZRS Replicación entre regiones
Replicación entre zonas
Zonas de disponibilidad para alta
Estándar disponibilidad
LRS
ZRS
GRS
GZRS

la sección sobre redundancia.
Acuerdo de Nivel Acuerdo de Nivel de Servicio Acuerdo de Nivel de Servicio para Azure
de Servicio (SLA) para Azure Files NetApp Files
Tenga en cuenta
que los Acuerdos
de Nivel de Servicio
para Azure Files y
Azure NetApp Files

se calculan de
forma diferente.
Autenticación y SMB SMB

autorización
basadas en Active Directory Domain Active Directory Domain Services
identidad Services (AD DS) (AD DS)
Servicios de dominio de Servicios de dominio de
Microsoft Entra Microsoft Entra
Microsoft Entra Kerberos
( solo identidades
híbridas) Protocolo doble NFS/SMB
Integración de ADDS/LDAP
Tenga en cuenta que la ADD/LDAP sobre TLS
autenticación basada en
identidad solo se admite
NFSv3/NFSv4.1
cuando se utiliza el protocolo
SMB. Para más información, Integración de ADDS/LDAP con
consulte Preguntas frecuentes. grupos extendidos de NFS
Para obtener más información, consulte

Preguntas frecuentes de NFS en Azure
NetApp Files y Preguntas frecuentes de
SMB en Azure NetApp Files.
Cifrado Todos los protocolos Todos los protocolos
Cifrado en reposo (AES- Cifrado en reposo (AES-256) con

256) con claves claves administradas por Microsoft
administradas por el Cifrado en reposo (AES-256) con
cliente o por Microsoft claves administradas por el cliente
SMB SMB
Cifrado de Kerberos con Cifrado en tránsito mediante AES-

AES-256 (recomendado) CCM (SMB 3.0) y AES-GCM
o RC4-HMAC (SMB 3.1.1)
Cifrado en tránsito
NFS 4.1
REST
Cifrado en tránsito mediante
Cifrado en tránsito Kerberos con AES-256
Para más información, consulte Para más información, consulte la sección

Seguridad y redes. sobre preguntas frecuentes sobre

seguridad.
Opciones de Internet Acceso seguro a redes virtuales

acceso Acceso seguro a redes VPN Gateway
virtuales ExpressRoute
VPN Gateway Virtual WAN
ExpressRoute Caché de archivos globales
Azure File Sync HPC Cache
Características de red estándar

la sección acerca de las Para más información, consulte la sección
consideraciones sobre la red. acerca de las consideraciones sobre la
red.
Protección de Instantáneas Copia de seguridad de archivos de

datos incrementales Azure NetApp Files
Restauración automática Instantáneas (255/volumen)
de usuarios de archivos y Restauración automática de
directorios usuarios de archivos o directorios
Restauración en una Restauración en el nuevo volumen
nueva ubicación Reversión local
Reversión local Replicación entre regiones
Eliminación temporal del Replicación entre zonas
nivel de recurso
compartido
Integración de Azure Para más información, consulte
Backup Funcionamiento de las instantáneas de
Azure NetApp Files.

Azure Files mejora las
funcionalidades de protección
de datos .
Herramientas de Azure Data Box Caché de archivos globales

migración Azure File Sync CloudSync , XCP
Servicio de migración de Servicio de migración de
AzCopy AzCopy
Robocopy Robocopy
Basado en la aplicación (por
ejemplo, HSR, Data Guard, AOAG)
Migración a recursos
compartidos de archivos de
Azure.
Niveles Premium Ultra

Optimizado para Premium
transacciones Estándar
Acceso frecuente
Acceso esporádico
Todos los niveles proporcionan una
latencia mínima en submilisegundos.
la sección sobre capas de Para más información, consulte Niveles
almacenamiento. de servicio y Consideraciones sobre el
rendimiento.
Precios Precios de Azure Files Precios de Azure NetApp Files
Escalabilidad y rendimiento
Tamaño mínimo del Premium Todos los niveles

volumen o recurso
compartido 100 GiB 100 GiB (tamaño mínimo
del grupo de capacidad:
4 TiB)
Estándar
Sin mínimo (solo SMB: NFS

requiere recursos
compartidos Premium).
Tamaño máximo del 100 TiB Todos los niveles

volumen o recurso
compartido Hasta 100 TiB (volumen
normal)
100-500 TiB (volumen
grande)
Límite de tamaño del
grupo de capacidad de
500 TiB
Hasta 12,5 PiB por cuenta de

Azure NetApp.
Número máximo de Premium Ultra y Premium

IOPS de volumen o de
recurso compartido Hasta 100 000 Hasta 450 000
Estándar Estándar
Hasta 20 000 Hasta 320 000
Rendimiento máximo Premium Ultra

de volumen o recurso
compartido Hasta 10 GiB/s 4,5 GiB/s (volumen
normal)
10 GiB/s (volumen
Estándar grande)
Hasta el límite de la cuenta

de almacenamiento. Premium
Hasta 4,5 GiB/s (volumen

normal)
grande)
Estándar

normal y grande)
Tamaño de archivo 4 TiB 16 TiB

máximo
Número máximo de Premium Todos los niveles

IOPS por archivo
Hasta 8 000 Hasta el límite de
volumen
Estándar
1,000
Rendimiento máximo Premium Todos los niveles

por archivo
300 MiB/s (hasta 1 GiB/s con Hasta el límite de
SMB multicanal) volumen
Estándar
60 MiB/s
SMB multicanal Sí Sí
Latencia Latencia mínima de un solo Latencia mínima en

milisegundo (entre 2 ms y 3 ms submilisegundos (<1 ms para
para E/S pequeñas) E/S aleatorias)

la sección sobre puntos de
referencia de rendimiento.
Para más información sobre los objetivos de escalabilidad y rendimiento, consulte Azure
Files y Azure NetApp Files.
Pasos siguientes
Documentación de Azure Files
Documentación sobre Azure NetApp Files
Almacenamiento compartido para todas las sesiones de cargas de trabajo de
archivos empresariales
Comparación del acceso a Azure Files,
Blob Storage y Azure NetApp Files con
NFS
Artículo • 20/03/2023
En este artículo se proporciona una comparación entre cada una de estas ofertas si se
accede a ellas mediante el protocolo Network File System (NFS) . Esta comparación no
se aplica si se accede a ellas por cualquier otro método.
Si busca comparaciones más generales, consulte: este artículo para comparar Azure Blob
Storage y Azure Files o este otro para comparar Azure Files y Azure NetApp Files.
De comparación
Category Azure Blob Azure Files Azure NetApp Files
Storage
Storage
Casos de uso Blob Storage es Azure Files es un servicio de Servicio de archivos

más adecuado alta disponibilidad que está totalmente administrado en
para cargas de optimizado para cargas de la nube, con tecnología de
trabajo de acceso trabajo de acceso aleatorio. NetApp, con
secuencial con funcionalidades de
numerosas lecturas En el caso de los recursos administración avanzadas.
a gran escala en compartidos de NFS, Azure
las que los datos Files proporciona Azure NetApp Files es
se ingieren una vez compatibilidad completa adecuado para cargas de
y se modifican con el sistema de archivos trabajo que requieren
mínimamente POSIX y se puede usar acceso aleatorio y
después. fácilmente desde proporciona una amplia
plataformas de contenedor, compatibilidad con
Blob Storage como Azure Container protocolos y
ofrece el costo Instance (ACI) y Azure funcionalidades de
total de propiedad Kubernetes Service (AKS) protección de datos.
más bajo, si hay con el controlador CSI
poco o ningún integrado, además de Algunos escenarios de
mantenimiento. plataformas basadas en ejemplo son: migración
máquinas virtuales. NAS empresarial local que
Algunos escenarios requiere numerosas
de ejemplo son: Algunos escenarios de funcionalidades de
datos analíticos a ejemplo son: archivos administración, cargas de
gran escala, compartidos, bases de trabajo sensibles a la
computación de datos, directorios latencia, como SAP HANA,
alto rendimiento principales, aplicaciones proceso de alto
sensible a la tradicionales, ERP, CMS, rendimiento con uso
capacidad de migraciones NAS que no intensivo de IOPS o
proceso, copia de requieren administración sensible a la latencia o
seguridad y avanzada y aplicaciones cargas de trabajo que
archivo, personalizadas que requieren acceso
conducción requieren almacenamiento simultáneo a varios
autónoma, de archivos de escalabilidad protocolos.
representación horizontal.
multimedia o
secuenciación
genómica.
Protocolos NFSv3 SMB NFSv3 y NFSv4.1

disponibles
REST NFSv4.1 SMB
Data Lake Storage (No hay interoperabilidad Protocolo dual (SMB y

Gen2 entre ninguno de los NFSv3, SMB y NFSv4.1)
protocolos).
Storage
Características Se integra con la Redundancia zonal para alta Latencia extremadamente

principales caché HPC en el disponibilidad. baja (menos de un
caso de cargas de milisegundo).
trabajo de baja Baja latencia constante
latencia. (menos de 10 ms). Funcionalidades valiosas de
administración de ONTAP,
Administración Rendimiento y costo como instantáneas, copia
integrada, lo que predecibles que se escalan de seguridad, replicación
incluye el ciclo de con la capacidad. entre regiones y replicación
vida, los blobs entre zonas.
inmutables, la
conmutación por Experiencia coherente de
error de datos y el nube híbrida.
índice de
metadatos.
Rendimiento Hasta 20 000 IOPS, Hasta 100 000 IOPS, con un Hasta 460 000 IOPS, un
(por con un rendimiento de 10 Gib/s. rendimiento de 4,5 GiB/s
volumen). rendimiento de por volumen normal y un
15 Gib/s. rendimiento de 10 GiB/s
por volumen grande.
Escala Hasta 5 PiB para Hasta 100 TiB para un único Hasta 100 TiB para un
un solo volumen. recurso compartido de único volumen normal y
archivos. 500 TiB para un volumen
Hasta 190,7 TiB grande.
para un único Hasta 4 TiB para un solo
blob. archivo. Hasta 16 TiB para un solo
archivo.
No hay requisitos 100 GiB de capacidad
mínimos de mínima. Experiencia coherente de
capacidad. nube híbrida.
Precios Precios de Azure Precios de Azure Files Precios de Azure NetApp

Blob Storage Files
Pasos siguientes
Para acceder a Blob Storage con NFS, consulte Compatibilidad del protocolo
Network File System (NFS) 3.0 en Azure Blob Storage.
Para acceder Azure Files con NFS, consulte Recursos compartidos de archivos NFS
en Azure Files.
Para acceder a Azure NetApp Files con NFS, consulte Inicio rápido: Configuración
de Azure NetApp Files y creación de un volumen NFS.
Casos prácticos de clientes de
Azure Files y Azure File Sync
Artículo • 28/07/2023
Los clientes de diversos sectores usan Azure Files y Azure File Sync para hospedar sus
recursos compartidos de archivos y sincronizar los servidores de archivos locales en la
nube. Obtenga información directamente de los casos de uso de clientes que se
enumeran aquí.
Caso de uso del entrenamiento del modelo de

IA de Azure Files
Para interpretar y contextualizar la salud de los fondos marinos, un equipo de científicos
y analistas marinos almacenaba una amplia colección de imágenes en Azure Files usar
para crear y entrenar un modelo de inteligencia artificial crucial. Ahora, el equipo
actualiza sin problemas los datos del suelo marino y hace que sea accesible para los
clientes casi en tiempo real. Consulte la historia completa aquí .
Caso de uso de Azure Files NFS para SAP

Una compañía de seguros global ejecuta una de las mayores implementaciones de SAP
en Europa, que históricamente se administra en su propia nube privada. A medida que
la empresa continuó creciendo, sus recursos de hardware locales se volvieron cada vez
más escasos. Para mejorar la escalabilidad y el rendimiento, la empresa trasladó su
entorno de SAP a Azure mediante Azure Virtual Machines y Azure Disk Storage. Se usó
Azure Files para proporcionar almacenamiento de archivos NFS para sus servidores SAP
basados en Linux, lo que elimina la carga y los costos de administrar servidores de
archivos NFS locales. Con Azure Files, la empresa también puede operar fácilmente
directorios de transporte SAP críticos para la empresa. Consulte la historia completa
aquí .
Caso de uso de continuidad empresarial de

Azure File Sync
Una empresa de ingeniería ambiental con 2500 empleados distribuidos en 80 oficinas se
enfrenta a dos problemas importantes:
1. Se agota constantemente el espacio en disco local en sus servidores de archivos
locales
2. La amenaza de desastres naturales, incendios e interrupciones de energía
Cualquiera de estas situaciones podría provocar interrupciones repentinas del servidor,

lo que da lugar a una menor productividad y un costo empresarial en sus resultados
finales. Al adoptar Azure Files junto con Azure File Sync, pudieron mejorar los tiempos
de recuperación del servidor hasta ser casi instantáneos y dar a sus empleados la
capacidad de trabajar sin interrupciones. Consulte la historia completa aquí .
Caso de uso de colaboración de Azure File Sync

Una marca de ropa deportiva buscaba formas de elevar la velocidad y facilidad de
colaboración entre las diferentes ubicaciones. La empresa usó Azure File Sync junto con
Azure Virtual WAN para obtener lo mejor de ambos mundos: una caché de rendimiento
local para los usuarios locales, además de la escala en la nube y la sincronización
mundial. Esto redujo la latencia y mejoró la seguridad y el trabajo en equipo. También
ha simplificado la administración de TI y ha reducido el costo total de propiedad para
ejecutar los servicios de archivos. Consulte el caso práctico completo aquí .
Caso de uso de archivos grande de Azure Files

Los estudios de juegos tratan con archivos de gran tamaño diariamente para almacenar
sus valiosos recursos digitales, compartir compilaciones y revisar volcados de memoria.
Cuando la pandemia de COVID-19 impulsó a los desarrolladores de juegos a pasar de
tener personal en la oficina a un equipo remoto distribuido globalmente, trabajar con
archivos de gran tamaño no se escalaba bien. La mayor demanda de acceso remoto dio
lugar a una alta latencia al trabajar con archivos grandes, así como un aumento de los
costos de salida de Internet. Azure Files ofrece una solución escalable para que el
equipo trabaje fácilmente con archivos grandes.
Ejemplos de código de Azure Blob
Storage mediante bibliotecas cliente de
.NET versión 11.x
Artículo • 07/05/2023
En este artículo, se muestran ejemplos de código que usan la versión 11.x de la

biblioteca cliente de Azure Blob Storage para .NET.
El 31 de marzo de 2023, se retiró el soporte técnico para las bibliotecas del SDK de
Azure que no cumplen las directrices actuales del SDK de Azure . Las nuevas
bibliotecas del SDK de Azure se actualizan periódicamente para impulsar experiencias
coherentes y reforzar la posición de seguridad. Se recomienda realizar la transición a las
nuevas bibliotecas del SDK de Azure para aprovechar las nuevas funcionalidades y las
actualizaciones de seguridad críticas.
Aunque las bibliotecas anteriores todavía se pueden usar más allá del 31 de marzo de
2023, ya no recibirán soporte técnico oficial ni actualizaciones de Microsoft. Para
obtener más información, consulte el anuncio de retirada de soporte técnico .
Requisitos previos
Instale estos paquetes en el directorio del proyecto:
Microsoft.Azure.Storage.Common
Microsoft.Azure.Storage.File
Microsoft.Azure.ConfigurationManager
Agregue las siguientes directivas using :
C#
using Microsoft.Azure; // Namespace for Azure Configuration

Manager
using Microsoft.Azure.Storage; // Namespace for Storage Client Library
using Microsoft.Azure.Storage.Blob; // Namespace for Azure Blobs
using Microsoft.Azure.Storage.File; // Namespace for Azure Files
Acceso al recurso compartido de archivos

Artículo relacionado: Desarrollo para Azure Files con .NET
Agregue el código siguiente para acceder al recurso compartido de archivos:
C#
// Create a CloudFileClient object for credentialed access to Azure Files.

CloudFileClient fileClient = storageAccount.CreateCloudFileClient();
// Get a reference to the file share we created previously.

CloudFileShare share = fileClient.GetShareReference("logs");
// Ensure that the share exists.

if (share.Exists())
{
// Get a reference to the root directory for the share.
CloudFileDirectory rootDir = share.GetRootDirectoryReference();
// Get a reference to the directory we created previously.

CloudFileDirectory sampleDir =
rootDir.GetDirectoryReference("CustomLogs");
// Ensure that the directory exists.

if (sampleDir.Exists())
{
// Get a reference to the file we created previously.
CloudFile file = sampleDir.GetFileReference("Log1.txt");
// Ensure that the file exists.

if (file.Exists())
{
// Write the contents of the file to the console window.
Console.WriteLine(file.DownloadTextAsync().Result);
}
}
}
Establecer el tamaño máximo para un recurso

A partir de la versión 5.x de la biblioteca cliente de Azure Files, se puede establecer la

cuota (tamaño máximo) de un recurso compartido de archivos. También puede
comprobar cuántos datos se almacenan actualmente en el recurso compartido.
Al establecer la cuota para un recurso compartido, se limita el tamaño total de los

archivos almacenados en el recurso compartido. Si el tamaño total de los archivos del
recurso compartido supera la cuota, los clientes no pueden aumentar el tamaño de los
archivos existentes. Los clientes tampoco pueden crear archivos nuevos, a menos que
estén vacíos.
En el ejemplo siguiente se muestra cómo comprobar el uso actual de un recurso

compartido y cómo establecer la cuota para el recurso compartido.
C#
// Parse the connection string for the storage account.

CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
Microsoft.Azure.CloudConfigurationManager.GetSetting("StorageConnectionStrin
g"));



if (share.Exists())
{
// Check current usage stats for the share.
// Note that the ShareStats object is part of the protocol layer for the
File service.
Microsoft.Azure.Storage.File.Protocol.ShareStats stats =
share.GetStats();
Console.WriteLine("Current share usage: {0} GiB",
stats.Usage.ToString());
// Specify the maximum size of the share, in GiB.

// This line sets the quota to be 10 GiB greater than the current usage
of the share.
share.Properties.Quota = 10 + stats.Usage;
share.SetProperties();
// Now check the quota for the share. Call FetchAttributes() to populate
the share's properties.
share.FetchAttributes();
Console.WriteLine("Current share quota: {0} GiB",
share.Properties.Quota);
}
Generar una firma de acceso compartido para un archivo

o recurso compartido de archivos
A partir de la versión 5.x de la biblioteca cliente de Azure Files, puede generar una firma
de acceso compartido (SAS) para un recurso compartido de archivos o para un archivo
individual.
También puede crear una directiva de acceso almacenada en un recurso compartido de

archivos para administrar firmas de acceso compartido. Le recomendamos que cree una
directiva de acceso almacenada, ya que le permite revocar la clave SAS si se encuentra
en peligro. En el ejemplo siguiente se crea una directiva de acceso almacenada en un
recurso compartido. En el ejemplo se usa esa directiva para proporcionar las
restricciones para una clave SAS en un archivo del recurso compartido.
C#

g"));



if (share.Exists())
{
string policyName = "sampleSharePolicy" + DateTime.UtcNow.Ticks;
// Create a new stored access policy and define its constraints.

SharedAccessFilePolicy sharedPolicy = new SharedAccessFilePolicy()
{
SharedAccessExpiryTime = DateTime.UtcNow.AddHours(24),
Permissions = SharedAccessFilePermissions.Read |
SharedAccessFilePermissions.Write
};
// Get existing permissions for the share.

FileSharePermissions permissions = share.GetPermissions();
// Add the stored access policy to the share's policies. Note that each
policy must have a unique name.
permissions.SharedAccessPolicies.Add(policyName, sharedPolicy);
share.SetPermissions(permissions);
// Generate a SAS for a file in the share and associate this access
policy with it.
CloudFile file = sampleDir.GetFileReference("Log1.txt");
string sasToken = file.GetSharedAccessSignature(null, policyName);
Uri fileSasUri = new Uri(file.StorageUri.PrimaryUri.ToString() +
sasToken);
// Create a new CloudFile object from the SAS, and write some text to
the file.
CloudFile fileSas = new CloudFile(fileSasUri);
fileSas.UploadText("This write operation is authorized via SAS.");
Console.WriteLine(fileSas.DownloadText());
}
Copiar archivos
A partir de la versión 5.x de la biblioteca cliente de Azure Files, puede copiar un archivo
en otro, un archivo en un blob o un blob en un archivo.
También puede usar AzCopy para copiar un archivo en otro o para copiar un blob en un
archivo o viceversa. Consulte Introducción a AzCopy.
７ Nota
Si va a copiar un blob en un archivo o un archivo en un blob, debe usar una firma

de acceso compartido (SAS) para autorizar el acceso al objeto de origen, incluso si
está copiando en la misma cuenta de almacenamiento.
Copiar un archivo en otro

En el ejemplo siguiente se copia un archivo en otro en el mismo recurso compartido.
Puede usar la autenticación de clave compartida para realizar la copia porque en esta
operación se copian archivos de la misma cuenta de almacenamiento.
C#

g"));


if (share.Exists())
{
// Get a reference to the directory we created previously.

// Ensure that the directory exists.

if (sampleDir.Exists())
{
// Get a reference to the file we created previously.
CloudFile sourceFile = sampleDir.GetFileReference("Log1.txt");
// Ensure that the source file exists.

if (sourceFile.Exists())
{
// Get a reference to the destination file.
CloudFile destFile = sampleDir.GetFileReference("Log1Copy.txt");
// Start the copy operation.

destFile.StartCopy(sourceFile);
// Write the contents of the destination file to the console

window.
Console.WriteLine(destFile.DownloadText());
}
}
}
Copiar un archivo en un blob

En el ejemplo siguiente se crea un archivo y se copia en un blob de la misma cuenta de
almacenamiento. El ejemplo crea una SAS para el archivo de origen, que el servicio usa
para autorizar el acceso al archivo de origen durante la operación de copia.
C#

g"));

// Create a new file share, if it does not already exist.

CloudFileShare share = fileClient.GetShareReference("sample-share");
share.CreateIfNotExists();
// Create a new file in the root directory.

CloudFile sourceFile =
share.GetRootDirectoryReference().GetFileReference("sample-file.txt");
sourceFile.UploadText("A sample file in the root directory.");
// Get a reference to the blob to which the file will be copied.

CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
CloudBlobContainer container = blobClient.GetContainerReference("sample-
container");
container.CreateIfNotExists();
CloudBlockBlob destBlob = container.GetBlockBlobReference("sample-
blob.txt");
// Create a SAS for the file that's valid for 24 hours.

// Note that when you are copying a file to a blob, or a blob to a file, you
must use a SAS
// to authorize access to the source object, even if you are copying within
the same
// storage account.
string fileSas = sourceFile.GetSharedAccessSignature(new
SharedAccessFilePolicy()
{
// Only read permissions are required for the source file.
Permissions = SharedAccessFilePermissions.Read,
SharedAccessExpiryTime = DateTime.UtcNow.AddHours(24)
});
// Construct the URI to the source file, including the SAS token.
Uri fileSasUri = new Uri(sourceFile.StorageUri.PrimaryUri.ToString() +
fileSas);
// Copy the file to the blob.

destBlob.StartCopy(fileSasUri);
// Write the contents of the file to the console window.

Console.WriteLine("Source file contents: {0}", sourceFile.DownloadText());
Console.WriteLine("Destination blob contents: {0}",
destBlob.DownloadText());
Puede copiar un blob en un archivo de la misma manera. Si el objeto de origen es un

blob, cree una SAS para autorizar el acceso a dicho blob durante la operación de copia.

A partir de la versión 8.5 de la biblioteca cliente de Azure Files, se puede crear una
instantánea de recurso compartido. Las instantáneas de recursos compartidos también
se pueden enumerar, explorar y eliminar. Una vez creadas, las instantáneas de recursos
compartidos son de solo lectura.

En el siguiente ejemplo, se crea una instantánea de recurso compartido de archivos:
C#
storageAccount = CloudStorageAccount.Parse(ConnectionString);
fClient = storageAccount.CreateCloudFileClient();
string baseShareName = "myazurefileshare";
CloudFileShare myShare = fClient.GetShareReference(baseShareName);
var snapshotShare = myShare.Snapshot();
Enumerar instantáneas del recurso compartido

En el siguiente ejemplo, se enumeran las instantáneas de un recurso compartido:
C#
var shares = fClient.ListShares(baseShareName, ShareListingDetails.All);
Enumeración de archivos y directorios en instantáneas de

recursos compartidos
En el siguiente ejemplo, se examinan los archivos y directorios de instantáneas de
recursos compartidos:
C#
CloudFileShare mySnapshot = fClient.GetShareReference(baseShareName,

snapshotTime);
var rootDirectory = mySnapshot.GetRootDirectoryReference();
var items = rootDirectory.ListFilesAndDirectories();
Restauración de recursos compartidos de archivos o

archivos desde instantáneas de recursos compartidos
La toma de una instantánea de un recurso compartido de archivos permite recuperar
archivos individuales o todo el recurso compartido de archivos.
Para restaurar un archivo de una instantánea del recurso compartido de archivos,
consulte las instantáneas de recursos compartidos de un recurso compartido de
archivos. Después, puede recuperar un archivo que pertenezca a una instantánea de
recurso compartido determinada. Use esa versión para leer directamente el archivo o
restaurarlo.
C#
CloudFileShare liveShare = fClient.GetShareReference(baseShareName);

var rootDirOfliveShare = liveShare.GetRootDirectoryReference();
var dirInliveShare = rootDirOfliveShare.GetDirectoryReference(dirName);
var fileInliveShare = dirInliveShare.GetFileReference(fileName);
CloudFileShare snapshot = fClient.GetShareReference(baseShareName,

snapshotTime);
var rootDirOfSnapshot = snapshot.GetRootDirectoryReference();
var dirInSnapshot = rootDirOfSnapshot.GetDirectoryReference(dirName);
var fileInSnapshot = dir1InSnapshot.GetFileReference(fileName);
string sasContainerToken = string.Empty;

SharedAccessFilePolicy sasConstraints = new SharedAccessFilePolicy();
sasConstraints.SharedAccessExpiryTime = DateTime.UtcNow.AddHours(24);
sasConstraints.Permissions = SharedAccessFilePermissions.Read;
//Generate the shared access signature on the container, setting the

constraints directly on the signature.
sasContainerToken = fileInSnapshot.GetSharedAccessSignature(sasConstraints);
string sourceUri = (fileInSnapshot.Uri.ToString() + sasContainerToken + "&"

+ fileInSnapshot.SnapshotTime.ToString()); ;
fileInliveShare.StartCopyAsync(new Uri(sourceUri));
Eliminación de instantáneas de recursos compartidos

En el siguiente ejemplo, se elimina una instantánea de recurso compartido de archivos:
C#
CloudFileShare mySnapshot = fClient.GetShareReference(baseShareName,

snapshotTime); mySnapshot.Delete(null, null, null);
Solución de problemas de Azure Files mediante

métricas
Azure Storage Analytics admite métricas para Azure Files. Con los datos de las métricas,
es posible seguir paso a paso las solicitudes y diagnosticar problemas.
Puede habilitar las métricas para Azure Files mediante Azure Portal . La métrica
también se puede habilitar mediante programación. Para ello, hay que llamar a la
operación Set File Service Properties con la API de REST o una de sus análogas de la
biblioteca cliente de Azure Files.
En el siguiente ejemplo de código se muestra cómo usar la biblioteca cliente de .NET a

fin de habilitar las métricas para Azure Files.
En primer lugar, agregue las siguientes directivas using a su archivo Program.cs, además
de las que ya ha agregado:
C#
using Microsoft.Azure.Storage.File.Protocol;
using Microsoft.Azure.Storage.Shared.Protocol;
Aunque Azure Blobs, Azure Tables y Azure Queues utilizan el tipo compartido
ServiceProperties en el espacio de nombres Microsoft.Azure.Storage.Shared.Protocol ,
Azure Files utiliza el suyo propio, el tipo FileServiceProperties en el espacio de
nombres Microsoft.Azure.Storage.File.Protocol . No obstante, debe hacer referencia a
ambos espacios de nombres en el código para que se pueda compilar.
C#
// Parse your storage connection string from your application's

configuration file.
g"));
// Create the File service client.
// Set metrics properties for File service.

// Note that the File service currently uses its own service properties
type,
// available in the Microsoft.Azure.Storage.File.Protocol namespace.
fileClient.SetServiceProperties(new FileServiceProperties()
{
// Set hour metrics
HourMetrics = new MetricsProperties()
{
MetricsLevel = MetricsLevel.ServiceAndApi,
RetentionDays = 14,
Version = "1.0"
},
// Set minute metrics
MinuteMetrics = new MetricsProperties()
{
MetricsLevel = MetricsLevel.ServiceAndApi,
RetentionDays = 7,
Version = "1.0"
}
});
// Read the metrics properties we just set.

FileServiceProperties serviceProperties = fileClient.GetServiceProperties();
Console.WriteLine("Hour metrics:");
Console.WriteLine(serviceProperties.HourMetrics.MetricsLevel);
Console.WriteLine(serviceProperties.HourMetrics.RetentionDays);
Console.WriteLine(serviceProperties.HourMetrics.Version);
Console.WriteLine("Minute metrics:");
Console.WriteLine(serviceProperties.MinuteMetrics.MetricsLevel);
Console.WriteLine(serviceProperties.MinuteMetrics.RetentionDays);
Console.WriteLine(serviceProperties.MinuteMetrics.Version);
Uso de redundancia geográfica para
diseñar aplicaciones de alta
disponibilidad (SDK de .NET v11)
Artículo • 13/04/2023
７ Nota
Los ejemplos de este artículo usan la biblioteca en desuso de Azure Storage .NET
v11. Para obtener el código y las instrucciones más recientes de la versión 12,
consulte Uso de redundancia geográfica para diseñar aplicaciones de alta
disponibilidad.
Una característica común de las infraestructuras basadas en la nube como Azure Storage
es que proporcionan una plataforma de alta disponibilidad y duración para hospedar
datos y aplicaciones. Los desarrolladores de aplicaciones basadas en la nube deben
considerar atentamente cómo aprovechar esta plataforma para maximizar estas ventajas
para sus usuarios. Azure Storage ofrece almacenamiento con redundancia geográfica
para garantizar la alta disponibilidad incluso en caso de interrupción regional. Las
cuentas de almacenamiento configuradas para la replicación con redundancia
geográfica se replican de forma sincrónica en la región primaria y luego se replican de
forma asincrónica en una región secundaria que se encuentra a cientos de kilómetros de
distancia.
Azure Storage ofrece dos tipos de replicación con redundancia geográfica. La única
diferencia entre estas dos opciones es la forma en que los datos se replican en la región
principal:
Almacenamiento con redundancia de zona geográfica (GZRS): Los datos se

replican de forma sincrónica en tres zonas de disponibilidad de Azure en la región
principal mediante el almacenamiento con redundancia de zona (ZRS) y, luego, se
replican de forma asincrónica en la región secundaria. Para obtener acceso de
lectura a los datos de la región secundaria, habilite el almacenamiento con
redundancia de zona geográfica con acceso de lectura (RA-GZRS).
Microsoft recomienda el uso de GZRS/RA-GZRS para escenarios que requieren la

máxima disponibilidad y durabilidad.
Almacenamiento con redundancia geográfica (GRS): Los datos se replican de

forma sincrónica tres veces en la región principal mediante el almacenamiento con
redundancia local (LRS) y, luego, se replican de forma asincrónica en la región
secundaria. Para obtener acceso de lectura a los datos de la región secundaria,
habilite el almacenamiento con redundancia geográfica con acceso de lectura (RA-
GRS).
En este artículo se muestra cómo diseñar la aplicación para controlar una interrupción
en la región primaria. Si la región primaria deja de estar disponible, la aplicación se
puede adaptar para realizar operaciones de lectura en la región secundaria en su lugar.
Antes de comenzar, asegúrese de que la cuenta de almacenamiento está configurada
para RA-GRS o RA-GZRS.
Consideraciones sobre el diseño de

aplicaciones al leer desde la región secundaria
El propósito de este artículo es mostrar cómo diseñar una aplicación que siga
funcionando (aunque con limitaciones) incluso si se produce un desastre importante en
el centro de datos principal. Puede diseñar la aplicación para que se enfrente a
problemas transitorios o prolongados pasando a leer desde la región secundaria
cuando se produzca un problema que interfiera con la lectura desde la región primaria.
Cuando la región primaria vuelva a estar disponible, la aplicación podrá volver a leer
desde ella.
Cuando diseñe su aplicación para RA-GRS o RA-GZRS debe tener en cuenta estos
puntos clave:
Azure Storage mantiene una copia de solo lectura de los datos que almacena en la
región primaria en una región secundaria. Como se mencionó anteriormente, el
servicio de almacenamiento determina la ubicación de la región secundaria.
La copia de solo lectura es de coherencia final con los datos en la región

primaria.
Para blobs, tablas y colas, puede consultar en la región secundaria un valor Hora de
última sincronización que indica cuándo se produjo la última replicación desde la
región primaria a la secundaria (Esto no se admite para Azure Files, que no tiene
redundancia RA-GRS en este momento).
Puede usar la biblioteca cliente de Storage para leer y escribir los datos en la
región primaria o la secundaria. También puede redirigir solicitudes de lectura
automáticamente a la región secundaria si se agota el tiempo de espera de una
solicitud de lectura a la región principal.
Si la región primaria deja de estar disponible, puede iniciar una conmutación por
error de la cuenta. Si la conmutación por error tiene como destino la región
secundaria, las entradas DNS que apunten a la región primaria se modificarán para
que apunten a la región secundaria. Una vez completada la conmutación por error,
se restaurará el acceso de escritura en las cuentas GRS y RA-GRS. Para obtener más
información, consulte Recuperación ante desastres y conmutación por error de la
Uso de datos con coherencia final

En la solución propuesta se da por supuesto que es aceptable devolver datos
potencialmente obsoletos a la aplicación que realiza la llamada. Debido a que, en última
instancia, los datos de la región secundaria son coherentes, puede que no sea posible
acceder a la región primaria antes de que una actualización en la región secundaria haya
terminado de replicarse.
Por ejemplo, imagine que el cliente envía correctamente una actualización, pero se
produce un error en la región primaria antes de que la actualización se propague a la
región secundaria. Cuando el cliente pide leer de nuevo los datos, se reciben los datos
obsoletos de la región secundaria en lugar de los datos actualizados. Cuando diseña la
aplicación, debe decidir si esto es aceptable y, en tal caso, cómo enviará mensajes al
cliente.
Más adelante en este artículo, le mostraremos cómo comprobar la hora de la última

sincronización de los datos secundarios para ver si la región secundaria está actualizada.
Control de servicios por separado o conjuntamente

Aunque no es probable, es posible que un servicio deje de estar disponible mientras
que los demás sigan siendo totalmente funcionales. Puede controlar los reintentos y el
modo de solo lectura para cada servicio por separado (blobs, colas, tablas) o puede
controlar los reintentos de forma genérica para todos los servicios de almacenamiento
en conjunto.
Por ejemplo, si usa colas y blobs en la aplicación, puede decidir colocarlos de forma
independiente en el código para poder controlar los errores con posibilidad de
reintento para cada uno de ellos. Entonces, si obtiene un reintento desde Blob service,
pero Queue service sigue funcionando, solo se verá afectada la parte de la aplicación
que controla blobs. Si decide controlar todos los reintentos de servicios de
almacenamiento de forma genérica y una llamada a Blob service devuelve un error con
posibilidad de reintento, se verán afectadas las solicitudes tanto a Blob service como a
Queue service.
En última instancia, esto depende de la complejidad de la aplicación. Es posible que

decida no controlar los errores para cada servicio, sino redirigir las solicitudes de lectura
para todos los servicios de almacenamiento a la región secundaria y ejecutar la
aplicación en modo de solo lectura cuando se detecte un problema con cualquier
servicio de almacenamiento en la región primaria.
Otras consideraciones
En el resto del artículo, también se tratarán estas consideraciones.
Control de los reintentos de solicitudes de lectura mediante el patrón de disyuntor
Datos de coherencia final y la hora de la última sincronización
Prueba
Ejecución de la aplicación en modo de solo

lectura
Para prepararse de forma eficaz para una interrupción en la región primaria, debe ser
capaz de controlar tanto solicitudes de lectura con errores como solicitudes de
actualización con errores (aquí actualización se refiere a inserciones, actualizaciones y
eliminaciones). Si se produce un error en la región primaria, se pueden redirigir las
solicitudes de lectura a la región secundaria. Sin embargo, las solicitudes de
actualización no se puede redirigir a la región secundaria porque es de solo lectura. Por
este motivo, debe diseñar la aplicación para que se ejecute en modo de solo lectura.
Por ejemplo, puede establecer una marca que se comprueba antes de que se envíe
cualquier solicitud de actualización a Azure Storage. Cuando llegue una de las
solicitudes de actualización, puede pasarla por alto y devolver una respuesta adecuada
al cliente. Incluso es posible que desee deshabilitar totalmente determinadas
características hasta que se resuelva el problema y notificar a los usuarios que esas
características no están disponibles temporalmente.
Si decide controlar errores para cada servicio por separado, también necesitará controlar
la capacidad de ejecutar la aplicación en modo de solo lectura para cada servicio. Por
ejemplo, es posible que tenga marcas de solo lectura en cada servicio que se puede
habilitar o deshabilitar. Luego puede manipular la marca en los lugares
correspondientes del código.
Poder ejecutar la aplicación en modo de solo lectura ofrece otra ventaja: la capacidad de
garantizar una funcionalidad limitada durante una actualización importante de la
aplicación. Puede desencadenar la aplicación para que se ejecute en modo de solo
lectura y apunte al centro de datos secundario, de forma que nadie acceda a los datos
de la región primaria mientras se estén llevando a cabo actualizaciones.
Control de las actualizaciones durante la

ejecución en modo de solo lectura
Existen muchas formas de controlar solicitudes de actualización durante la ejecución en
modo de solo lectura. No se va a tratar esto de forma exhaustiva, pero, por lo general,
hay un par de patrones que tener en cuenta.
Puede responder al usuario y indicarle que actualmente no se aceptan

actualizaciones. Por ejemplo, un sistema de administración de contactos podría
permitir que los clientes accedan a información de contacto, pero no que la
actualicen.
Puede poner las actualizaciones en cola en otra región. En este caso, podría
escribir las solicitudes de actualización pendientes en una cola de una región
distinta y, después, contar con una forma de procesar esas solicitudes una vez que
el centro de datos principal vuelva a estar en línea. En este escenario, debería hacer
saber al cliente que la actualización solicitada está en cola para procesarse más
adelante.
Puede escribir las actualizaciones en una cuenta de almacenamiento de otra

región. Después, cuando el centro de datos principal vuelva a estar en línea, puede
disponer de una forma de combinar esas actualizaciones con los datos principales,
en función de la estructura de estos. Por ejemplo, si va a crear archivos distintos
con una marca de fecha y hora en el nombre, puede copiar esos archivos de nuevo
a la región primaria. Esto funciona para algunas cargas de trabajo como los datos
de registro e IoT.
Control de los reintentos

La biblioteca cliente de Azure Storage le ayuda a determinar qué errores se pueden
reintentar. Por ejemplo, un error 404 (recurso no encontrado) no se intentaría de nuevo
porque no es probable que el nuevo intento se complete de forma correcta. Por otro
lado, un error 500 se puede intentar de nuevo porque es un error del servidor y puede
tratarse simplemente de un problema transitorio. Para más detalles, visite el código
fuente abierto de la clase ExponentialRetry en la biblioteca del cliente de
almacenamiento de .NET. (Busque el método ShouldRetry).
Solicitudes de lectura
Las solicitudes de lectura se pueden redirigir a almacenamiento secundario si hay un
problema con el principal. Como se indicó antes en Uso de datos con coherencia final,
debe ser aceptable que su aplicación lea datos potencialmente obsoletos. Si usa la
biblioteca del cliente de almacenamiento para acceder a datos desde la región
secundaria, puede especificar el comportamiento de reintento de una solicitud de
lectura estableciendo un valor para la propiedad LocationMode en una de las siguientes
opciones:
PrimaryOnly (valor predeterminado)
PrimaryThenSecondary
SecondaryOnly
SecondaryThenPrimary
Cuando se establece LocationMode en PrimaryThenSecondary, si la solicitud de lectura

inicial para el punto de conexión principal genera un error que se puede reintentar, el
cliente presenta automáticamente otra solicitud de lectura al punto de conexión
secundario. Si el error es por agotamiento del tiempo de espera del servidor, el cliente
tendrá que esperar a que el tiempo de espera expire antes de recibir un error con
posibilidad de reintento del servicio.
Básicamente, se deben tener en cuenta dos escenarios al decidir cómo responder a un

error con posibilidad de reintento:
Se trata de un problema aislado y las solicitudes posteriores al punto de conexión

principal no devolverán un error con posibilidad de reintento. Un ejemplo de
cuándo puede ocurrir esto es un error de red transitorio.
En este escenario, no hay ninguna reducción notable del rendimiento por tener
LocationMode establecido en PrimaryThenSecondary, ya que esto solo sucede en
raras ocasiones.
Se trata de un problema con al menos uno de los servicios de almacenamiento en

la región principal y es probable que todas las solicitudes posteriores a ese servicio
en la región principal devuelvan errores con posibilidad de reintento durante un
tiempo. Un ejemplo se da si la región principal es totalmente inaccesible.
En este escenario, el rendimiento se ve afectado porque todas las solicitudes de
lectura intentarán en primer lugar el punto de conexión principal, esperarán a que
el tiempo de espera expire y después cambiarán al punto de conexión secundario.
Para estos escenarios, debe reconocer que existe un problema continuado con el punto
de conexión principal y enviar todas las solicitudes de lectura directamente al punto de
conexión secundario; para ello, establezca la propiedad LocationMode en
SecondaryOnly. En este momento, también debería cambiar la aplicación para que se
ejecute en modo de solo lectura. Este enfoque se conoce como el patrón de disyuntor.
Solicitudes de actualización
El patrón de disyuntor también se puede aplicar a las solicitudes de actualización. Sin
embargo, estas no se pueden redirigir al almacenamiento secundario, que es de solo
lectura. Para estas solicitudes, debe dejar la propiedad LocationMode establecida en
PrimaryOnly (valor predeterminado). Para controlar estos errores, puede aplicar una
métrica a estas solicitudes (por ejemplo, 10 errores consecutivos) y, cuando se alcance el
umbral, cambiar la aplicación al modo de solo lectura. Puede usar los mismos métodos
para volver al modo de actualización que los descritos en la siguiente sección sobre el
patrón de disyuntor.
Patrón de disyuntor
Si usa el patrón de disyuntor en la aplicación, puede impedir que reintente una
operación que es probable que produzca errores una y otra vez. Permite que la
aplicación siga ejecutándose en lugar de ocupar tiempo mientras se reintenta la
operación de forma exponencial. Además, detecta cuándo se ha corregido el error,
momento en el que la aplicación puede intentar la operación de nuevo.
Cómo implementar el patrón de disyuntor

Para identificar la existencia de un problema continuado con un punto de conexión
principal, puede supervisar la frecuencia con que el cliente encuentra errores con
posibilidad de reintento. Como cada caso es diferente, tendrá que decidir el umbral que
desea usar para la decisión de cambiar al punto de conexión secundario y ejecutar la
aplicación en modo de solo lectura. Por ejemplo, podría decidir cambiar si hay diez
errores consecutivos sin ninguna ejecución correcta. Otro ejemplo consiste en cambiar
si se produce un error en el 90 % de las solicitudes en un periodo de dos minutos.
Para el primer escenario, basta con que cuente los errores y, si se produce un resultado
correcto antes de alcanzar el máximo, restablezca el recuento a cero. Para el segundo
escenario, una posibilidad de implementación es usar el objeto MemoryCache (en. NET).
Para cada solicitud, agregue un elemento CacheItem a la memoria caché, establezca el
valor en correcto (1) o error (0), y establezca la hora de expiración en 2 minutos a partir
del momento actual (o la restricción temporal que sea). Cuando se alcanza la hora de
expiración de una entrada, esta se quita automáticamente. Esto le dará un intervalo
gradual de 2 minutos. Cada vez que se envíe una solicitud al servicio de
almacenamiento, use primero una consulta Linq en el objeto MemoryCache para
calcular el porcentaje de corrección, para lo cual se suman los valores y se dividen por el
recuento. Cuando el porcentaje de corrección sea inferior a un umbral (por ejemplo, 10
%), establezca la propiedad LocationMode para solicitudes de lectura en
SecondaryOnly y cambie la aplicación al modo de solo lectura antes de continuar.
El umbral de errores que se usa para determinar cuándo se debe realizar el cambio
puede variar para cada servicio en la aplicación, por lo que debería considerar convertir
los umbrales en parámetros configurables. Aquí también se decide controlar los errores
con posibilidad de reintento de cada servicio por separado o en conjunto, según lo
descrito antes.
Otra consideración es cómo controlar varias instancias de una aplicación y qué hacer
cuando se detecten errores con posibilidad de reintento en cada instancia. Por ejemplo,
puede que tenga 20 máquinas virtuales que se ejecutan con la misma aplicación
cargada. ¿Va a controlar cada instancia por separado? Si una instancia empieza a tener
problemas, ¿desea limitar la respuesta solo a esa instancia o intentar que todas las
instancias respondan de la misma manera cuando una de ellas tenga un problema?
Controlar las instancias por separado es mucho más sencillo que intentar coordinar la
respuesta en todas ellas, pero la forma de hacerlo depende de la arquitectura de la
aplicación.
Opciones para supervisar la frecuencia de los errores

Dispone de tres opciones principales para supervisar la frecuencia de reintentos en la
región primaria y determinar cuándo se debe cambiar a la región secundaria y hacer
que la aplicación se ejecute en modo de solo lectura.
Agregue un controlador para el evento Retrying en el objeto OperationContext

que se pasa a las solicitudes de almacenamiento: este método se muestra en este
artículo y se usa en el ejemplo que lo acompaña. Estos eventos se activan cada vez
que el cliente reintenta una solicitud, lo que le permite realizar un seguimiento de
la frecuencia con que el cliente encuentra errores con posibilidad de reintento en
un punto de conexión principal.
C#
operationContext.Retrying += (sender, arguments) =>
{
// Retrying in the primary region
if (arguments.Request.Host == primaryhostname)
...
};
En el método Evaluate de una directiva de reintentos personalizada, puede

ejecutar código personalizado siempre que se lleve a cabo un reintento. Además
de registrar cuándo sucede un reintento, esto también ofrece la oportunidad de
modificar el comportamiento de reintento.
C#
public RetryInfo Evaluate(RetryContext retryContext,

OperationContext operationContext)
{
var statusCode = retryContext.LastRequestResult.HttpStatusCode;
if (retryContext.CurrentRetryCount >= this.maximumAttempts
|| ((statusCode >= 300 && statusCode < 500 && statusCode !=
408)
|| statusCode == 501 // Not Implemented
|| statusCode == 505 // Version Not Supported
))
{
// Do not retry
return null;
}
// Monitor retries in the primary location

...
// Determine RetryInterval and TargetLocation

RetryInfo info =
CreateRetryInfo(retryContext.CurrentRetryCount);
return info;
}
El tercer enfoque consiste en implementar un componente de supervisión

personalizado en la aplicación que haga ping continuamente al punto de conexión
de almacenamiento principal con solicitudes de lectura ficticias (por ejemplo, la
lectura de un blob pequeño) para determinar su estado. Esto consumiría recursos,
pero no en cantidades notables. Cuando se detecte un problema que alcance el
umbral, se llevar a cabo el cambio a SecondaryOnly y al modo de solo lectura.
En algún momento, querrá que se vuelva a usar el punto de conexión principal y se

permitan las actualizaciones. Si usa uno de los dos primeros métodos mencionados
antes, podría simplemente cambiar al punto de conexión principal y habilitar el modo
de actualización después de un intervalo de tiempo arbitrario o de que se haya llevado a
cabo un número de operaciones. A continuación, puede dejar que se repita la lógica de
reintento. Si se ha corregido el problema, procederá a usar el punto de conexión
principal y a permitir las actualizaciones. Si el problema persiste, volverá una vez más a
cambiar al punto de conexión secundario y al modo de solo lectura después de que se
incumplan los criterios que haya establecido.
Para el tercer escenario, cuando vuelva a hacer ping correctamente al punto de

conexión de almacenamiento principal, puede desencadenar el cambio a PrimaryOnly y
continuar permitiendo las actualizaciones.
Control de datos con coherencia final

El almacenamiento con redundancia geográfica funciona mediante la replicación de
transacciones de la región primaria en la región secundaria. Este proceso de replicación
garantiza que los datos de la región secundaria tengan coherencia final. Esto significa
que todas las transacciones en la región primaria terminarán por aparecer en la región
secundaria, aunque puede darse un retraso antes de que aparezcan y no hay ninguna
garantía de que las transacciones lleguen a la región secundaria en el mismo orden en
que se aplicaron originalmente en la región primaria. Si las transacciones llegan
desordenadas a la región secundaria, podría considerar que los datos en la región
secundaria se encuentran en un estado incoherente hasta que el servicio se ponga al
día.
En la tabla siguiente, se muestra un ejemplo de lo que podría suceder al actualizar los

detalles de un empleado para convertirlo en miembro del rol de administrador. Para
este ejemplo, esto requiere actualizar la entidad empleado y actualizar una entidad rol
de administrador con un recuento del número total de administradores. Observe cómo
se aplican las actualizaciones desordenadas en la región secundaria.
Time Transacción Replicación Hora de última Resultado

sincronización
T0 Transacción A: Transacción A insertada en región

Insertar entidad primaria,
empleado en aún sin replicar.
región primaria
sincronización
T1 Transacción T1 Transacción A replicada en región

A secundaria.
replicada Hora de última sincronización
en actualizada.
región
secundaria
T2 Transacción B: T1 Transacción B escrita en región

Actualizar primaria,
entidad empleado aún sin replicar.
en región primaria
T3 Transacción C: T1 Transacción C escrita en región

Actualizar primaria,
administrator aún sin replicar.
entidad rol
administrador en
región
primary
T4 Transacción T1 Transacción C replicada en región

C secundaria.
replicada LastSyncTime no actualizado
en porque
región la transacción B está aún sin
secundaria replicar.
T5 Leer entidades T1 Obtiene el valor obsoleto de la

desde región entidad
secundaria empleado porque la transacción B
aún
no se ha replicado. Obtiene el
valor nuevo para la
entidad rol de administrador
porque C
se ha replicado. La hora de la
última sincronización aún no se ha
actualizado porque la transacción
B
no se ha replicado. Puede ver que
la
entidad rol de administrador es
incoherente
porque la fecha y hora de la
entidad son posteriores a
Hora de última sincronización.
sincronización
T6 Transacción T6 T6: todas las transacciones hasta la

B C
replicada se han replicado, Hora de última
en sincronización
región se ha actualizado.
secundaria
En este ejemplo, suponga que el cliente pasa a leer desde la región secundaria en T5.
Puede leer correctamente la entidad rol administrador en este momento, pero la
entidad contiene un valor para el recuento de administradores que no es coherente con
el número de entidades empleado que están marcadas como administradores en la
región secundaria en este momento. El cliente podría mostrar simplemente este valor y
correr el riesgo de que sea información incoherente. O bien, el cliente podría intentar
determinar que el rol administrador se encuentra en un estado potencialmente
incoherente porque las actualizaciones se han producido desordenadas y después
informar al usuario sobre este hecho.
Para reconocer que tiene datos potencialmente incoherentes, el cliente puede usar el
valor de Hora de última sincronización, que puede obtener en cualquier momento al
consultar un servicio de almacenamiento. Esto indica la hora en que los datos de la
región secundaria fueron coherentes por última vez y cuándo aplicó el servicio todas las
transacciones hasta ese momento. En el ejemplo mostrado antes, una vez que el servicio
inserta la entidad empleado en la región secundaria, la hora de la última sincronización
se establece en T1. Permanece en T1 hasta que el servicio actualiza la entidad empleado
en la región secundaria cuando se establece en T6. Si el cliente recupera la última hora
de sincronización cuando lee la entidad en T5, puede compararla con la marca de
tiempo en la entidad. Si la marca de tiempo en la entidad es posterior a la hora de la
última sincronización, la entidad se encuentra en un estado potencialmente incoherente,
por lo que podrá llevar a cabo la acción adecuada para su aplicación. Para usar este
campo, es necesario saber cuándo se completó la última actualización en la región
primaria.
Para aprender a consultar la hora de la última sincronización, vea Comprobación de la

propiedad Hora de la última sincronización de una cuenta de almacenamiento.
Prueba
Es importante comprobar que la aplicación se comporte según lo esperado cuando
encuentre errores con posibilidad de reintento. Por ejemplo, debe probar que la
aplicación cambie a la región secundaria y al modo de solo lectura cuando se detecte un
problema y que cambie de vuelta a la región primaria cuando vuelva a estar disponible.
Para ello, necesita una manera de simular errores con posibilidad de reintento y
controlar la frecuencia con que se producen.
Puede usar Fiddler para interceptar y modificar respuestas HTTP en un script. Este
script puede identificar las respuestas que proceden de su punto de conexión principal y
cambiar el código de estado HTTP para que la biblioteca del cliente de almacenamiento
lo reconozca como error con posibilidad de reintento. Este fragmento de código
muestra un ejemplo sencillo de un script de Fiddler que intercepta respuestas a
solicitudes de lectura para la tabla employeedata y devuelve un estado 502:
static function OnBeforeResponse(oSession: Session) {

...
if ((oSession.hostname == "\
[yourstorageaccount\].table.core.windows.net")
&& (oSession.PathAndQuery.StartsWith("/employeedata?$filter"))) {
oSession.responseCode = 502;
}
}
Puede ampliar este ejemplo para interceptar una gama más amplia de solicitudes y
solamente cambiar el elemento responseCode en algunas de ellas para simular mejor
un escenario real. Para más información sobre cómo personalizar scripts de Fiddler,
consulte Modifying a Request or Response (Modificación de una solicitud o respuesta)
en la documentación de Fiddler.
Si ha hecho configurables los umbrales para cambiar la aplicación al modo de solo

lectura, será más fácil probar el comportamiento con volúmenes de transacciones que
no sean de producción.
Pasos siguientes
Para ver un ejemplo completo de cómo cambiar entre el punto de conexión principal y
el secundario, consulte Ejemplos de Azure: uso del patrón de interruptor con
almacenamiento de RA-GRS .
Ejemplos de código del recurso
compartido de archivos de Azure que
usan bibliotecas cliente de Java
versión 8
Artículo • 07/05/2023
En este artículo, se muestran ejemplos de código que usan la versión 8 de la biblioteca

cliente del recurso compartido de archivos de Azure para Java.
Requisitos previos
Para usar la biblioteca cliente del recurso compartido de archivos de Azure, agregue las
siguientes directivas import :
Java
// Include the following imports to use Azure Files APIs v11

import com.microsoft.azure.storage.*;
import com.microsoft.azure.storage.file.*;
Acceso a un recurso compartido de archivos de

Azure
Artículo relacionado: Desarrollo con Java para Azure Files
Para acceder a su cuenta de almacenamiento, use el objeto CloudStorageAccount,

pasando la cadena de conexión a su método de análisis.
Java
// Use the CloudStorageAccount object to connect to your storage account

try {
CloudStorageAccount storageAccount =
CloudStorageAccount.parse(storageConnectionString);
} catch (InvalidKeyException invalidKey) {
// Handle the exception
}
CloudStorageAccount.parse produce una InvalidKeyException, por lo que deberá

colocarla dentro de un bloque try/catch.

Todos los archivos y directorios de Azure Files se almacenan en un contenedor

denominado recurso compartido.
Para acceder a un recurso compartido y su contenido, cree un cliente de Azure Files. En

el ejemplo de código siguiente, se muestra cómo crear un recurso compartido de
archivos:
Java
// Create the Azure Files client.

CloudFileClient fileClient = storageAccount.createCloudFileClient();
Se usa el cliente de Azure Files para obtener una referencia a un recurso compartido.
Java
// Get a reference to the file share

CloudFileShare share = fileClient.getShareReference("sampleshare");
Para crear el recurso compartido, utilice el método createIfNotExists del objeto

CloudFileShare.
Java
if (share.createIfNotExists()) {
System.out.println("New share created");
}
En este punto, share contiene una referencia a un recurso compartido denominado
sample share.

archivos
En el siguiente código de ejemplo se elimina un recurso compartido de archivos.
Para eliminar un recurso compartido, llame al método deleteIfExists en un objeto

CloudFileShare.
Java
try
{
// Retrieve storage account from connection-string.
CloudStorageAccount storageAccount =
CloudStorageAccount.parse(storageConnectionString);
// Create the file client.

CloudFileClient fileClient = storageAccount.createCloudFileClient();
// Get a reference to the file share

CloudFileShare share = fileClient.getShareReference("sampleshare");
if (share.deleteIfExists()) {
System.out.println("sampleshare deleted");
}
} catch (Exception e) {
e.printStackTrace();
}

En el código siguiente, se crea un subdirectorio denominado sampledir en el directorio

raíz:
Java
//Get a reference to the root directory for the share.
CloudFileDirectory rootDir = share.getRootDirectoryReference();
//Get a reference to the sampledir directory

CloudFileDirectory sampleDir = rootDir.getDirectoryReference("sampledir");
if (sampleDir.createIfNotExists()) {
System.out.println("sampledir created");
} else {
System.out.println("sampledir already exists");
}
Eliminación de un directorio
En el código de ejemplo siguiente, se muestra cómo eliminar un directorio. No se puede

eliminar un directorio que todavía contenga archivos o subdirectorios.
Java

// Get a reference to the directory you want to delete

CloudFileDirectory containerDir =
rootDir.getDirectoryReference("sampledir");
// Delete the directory

if ( containerDir.deleteIfExists() ) {
System.out.println("Directory deleted");
}

Obtenga una lista de archivos y directorios mediante una llamada a

listFilesAndDirectories en una referencia de CloudFileDirectory. El método devuelve
una lista de objetos ListFileItem en los que puede efectuar la iteración.
El siguiente código enumera archivos y directorios dentro del directorio raíz:
Java
for ( ListFileItem fileItem : rootDir.listFilesAndDirectories() ) {

System.out.println(fileItem.getUri());
}
Cargar un archivo
Obtenga una referencia al directorio en el que se cargará el archivo mediante una

llamada al método getRootDirectoryReference en el objeto del recurso compartido.
Java

Ahora que tiene una referencia al directorio raíz del recurso compartido, puede cargar
un archivo en él utilizando el código siguiente:
Java
// Define the path to a local file.

final String filePath = "C:\\temp\\Readme.txt";
CloudFile cloudFile = rootDir.getFileReference("Readme.txt");

cloudFile.uploadFromFile(filePath);
En el ejemplo siguiente, se descarga el archivo SampleFile.txt y se muestra su contenido:
Java

//Get a reference to the directory that contains the file

CloudFileDirectory sampleDir = rootDir.getDirectoryReference("sampledir");
//Get a reference to the file you want to download

CloudFile file = sampleDir.getFileReference("SampleFile.txt");
//Write the contents of the file to the console.

System.out.println(file.downloadText());
El código siguiente elimina un archivo denominado SampleFile.txt que se almacena en

un directorio denominado sampledir:
Java

// Get a reference to the directory where the file to be deleted is in

CloudFileDirectory containerDir =
rootDir.getDirectoryReference("sampledir");
String filename = "SampleFile.txt"

CloudFile file;
file = containerDir.getFileReference(filename)
if ( file.deleteIfExists() ) {
System.out.println(filename + " was deleted");
}
Ejemplos de código del recurso
compartido de archivos de Azure que
usan bibliotecas cliente de Python
versión 2
Artículo • 12/05/2023
En este artículo, se muestran ejemplos de código que usan la versión 2 de la biblioteca

cliente del recurso compartido de archivos de Azure para Python.
Requisitos previos
Instale el siguiente paquete con pip install :
Consola
pip install azure-storage-file
Agregue la siguiente instrucción import :
Python
from azure.storage.file import FileService

de Azure
Artículo relacionado: Desarrollo con Python para Azure Files
En el siguiente ejemplo de código, puede usar un objeto FileService para crear el

recurso compartido si no existe.
Python
file_service.create_share('myshare')

El código siguiente creará un subdirectorio denominado sampledir en el directorio raíz.
Python
file_service.create_directory('myshare', 'sampledir')
Carga de un archivo
En esta sección, aprenderá a cargar un archivo desde el almacenamiento local en Azure

Files.
Un recurso compartido de archivos de Azure contiene como mínimo un directorio raíz

donde pueden residir los archivos. Para crear un archivo y cargar datos, use cualquiera
de los métodos siguientes:
create_file_from_path
create_file_from_stream
create_file_from_bytes
create_file_from_text
Estos métodos que realizan la fragmentación necesaria cuando el tamaño de los datos
supera los 64 MiB.
create_file_from_path carga el contenido de un archivo de la ruta de acceso
especificada y create_file_from_stream carga el contenido de un archivo o secuencia ya

abiertos. create_file_from_bytes carga una matriz de bytes y
create_file_from_text carga el valor de texto especificado con la codificación
especificada (el valor predeterminado es UTF-8).
En el siguiente ejemplo se carga el contenido del archivo sunset.png en el archivo

myfile.
Python
from azure.storage.file import ContentSettings

file_service.create_file_from_path(
'myshare',
None, # We want to create this file in the root directory, so we
specify None for the directory_name
'myfile',
'sunset.png',
content_settings=ContentSettings(content_type='image/png'))

Para mostrar los archivos y los directorios de un recurso compartido, use el método
list_directories_and_files. Este método devuelve un generador. El código siguiente ofrece
el nombre de todos los archivos y el directorio de un recurso compartido de la consola.
Python
generator = file_service.list_directories_and_files('myshare')
for file_or_dir in generator:
print(file_or_dir.name)
Para descargar datos de un archivo, use cualquiera de los métodos siguientes:
get_file_to_path
get_file_to_stream
get_file_to_bytes
get_file_to_text
Estos métodos que realizan la fragmentación necesaria cuando el tamaño de los datos
supera los 64 MiB.
En el ejemplo siguiente se muestra cómo usar get_file_to_path para descargar el

contenido en el archivo myfile y almacenarlo en el archivo out-sunset.png.
Python
file_service.get_file_to_path('myshare', None, 'myfile', 'out-sunset.png')

compartido
Puede crear una copia a un punto dado de todo el recurso compartido de archivos.
Python
snapshot = file_service.snapshot_share(share_name)
snapshot_id = snapshot.snapshot
Creación de una instantánea de recurso compartido con metadatos
Python
metadata = {"foo": "bar"}

snapshot = file_service.snapshot_share(share_name, metadata=metadata)
Enumeración de recursos compartidos e

instantáneas
Puede enumerar todas las instantáneas para un recurso compartido determinado.
Python
shares = list(file_service.list_shares(include_snapshots=True))
Examinación de instantáneas de recurso
compartido
Puede examinar cada instantánea de recurso compartido para recuperar archivos y

directorios desde ese punto dado.
Python
directories_and_files = list(
file_service.list_directories_and_files(share_name,
snapshot=snapshot_id))
Obtención del archivo desde una instantánea

de recurso compartido
Puede descargar un archivo desde una instantánea de recurso compartido. Esto le

permite restaurar una versión anterior de un archivo.
Python
with open(FILE_PATH, 'wb') as stream:

file = file_service.get_file_to_stream(
share_name, directory_name, file_name, stream, snapshot=snapshot_id)

compartido única
Puede eliminar una instantánea de recurso compartido única.
Python
file_service.delete_share(share_name, snapshot=snapshot_id)
Para eliminar un archivo, llame a delete_file.
En el código de ejemplo siguiente, se muestra cómo eliminar un directorio:
Python
file_service.delete_file('myshare', None, 'myfile')
Eliminación de un recurso compartido cuando

existen instantáneas de recurso compartido
No se puede eliminar un recurso compartido que contenga instantáneas a no ser que

todas las instantáneas se eliminen primero.
En el código de ejemplo siguiente, se muestra cómo eliminar un recurso compartido:
Python
file_service.delete_share(share_name,
delete_snapshots=DeleteSnapshot.Include)

Azure Storage Files

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Azure Storage Files

Cargado por

Copyright:

Formatos disponibles

Díganos qué opina sobre la experiencia de descarga del PDF.

Documentación de Azure Files

Acerca de Azure Files

Guía de plan de Azure Files

¿Qué es Azure Files?

Habilitación basada en identidad

Creación y uso de un recurso compartido de archivos de Azure

Creación de un recurso compartido de archivos SMB de Azure: Windows

Creación de un recurso compartido de archivos NFS de Azure: Linux

Solucionar problemas de Azure Files

Solución de problemas de rendimiento de Azure Files

GUÍA PASO A PASO

Introducción a Azure Files

Configuración de Azure Files y Azure File Sync

Recurso compartido de archivos de la nube empresarial de Azure

Servicios de archivo híbridos

Uso de recursos compartidos de archivos de Azure en un entorno híbrido

Archivos de Azure a los que se accede de forma local y que protege AD DS

Azure Files le ofrece recursos compartidos de archivos en la nube totalmente

Reemplazo del servidor de archivos por un recurso compartido de archivos de

¿Por qué es útil Azure Files?

Reemplazar o complementar servidores de archivos locales:

Simplificar el desarrollo en la nube:

Configuración de aplicaciones compartidas

Recurso compartido de diagnóstico:

Desarrollo, pruebas y depuración:

Introducción a Azure Files

Recurso compartido de archivos de la nube empresarial de Azure

Azure Files es el sencillo sistema de archivos en la nube de Microsoft. Puede montar

Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Crear una cuenta de almacenamiento

1. En Servicios de Azure, seleccione Cuentas de almacenamiento.

2. Seleccione Crear para crear una cuenta de almacenamiento.

3. En la sección Detalles del proyecto, seleccione la suscripción de Azure en la

4. Si desea crear un nuevo grupo de recursos, seleccione Crear nuevo y escriba

5. En Detalles de la instancia, proporcione un nombre para la cuenta de

6. En Región, seleccione la región en la que desea crear la cuenta de

7. En Rendimiento, conserve el valor predeterminado de Estándar.

8. En Redundancia, seleccione Almacenamiento con redundancia local (LRS).

9. Seleccione Revisar para revisar la configuración. Azure ejecutará una

Creación de un recurso compartido de archivos

Para crear un recurso compartido de archivos de Azure:

1. Seleccione la cuenta de almacenamiento desde el panel.

2. En la página de la cuenta de almacenamiento, en la sección Almacenamiento

4. En Nombre, escriba myshare. Los nombres de recursos compartidos de

5. Deje la opción Transacción optimizada seleccionada para el Nivel.

6. Seleccione la pestaña Copia de seguridad. De forma predeterminada, la copia

Para crear un nuevo directorio denominado myDirectory en la raíz del recurso

1. En la página Configuración del recurso compartido de archivos, seleccione el

1. Seleccione el directorio myDirectory. Se abre el panel myDirectory.

2. En el menú en la parte superior, seleccione Cargar. Se abre el panel Upload

4. Seleccione un archivo y, después, elija Abrir.

5. En la página Cargar archivos, compruebe el nombre de archivo y, luego, haga

6. Cuando termine, el archivo debe aparecer en la lista en la página myDirectory.

Cuando haya terminado, elimine el grupo de recursos. Al eliminar el grupo de

1. Seleccione Inicio y, a continuación, seleccione Grupos de recursos.

Azure Files ofrece recursos compartidos de archivos totalmente administrados en la

＂ Crear una cuenta de almacenamiento

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS