You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> This project is in the [community support](https://azure.github.io/azure-sdk/policies_support.html#package-lifecycle) stage of it's lifecycle. Eventually, all associated client libraries will be retired permanently. For more details on the retirement and alternatives to using this project, see [Retirement notice: Azure Storage PHP client libraries](https://azure.microsoft.com/updates/retirement-notice-the-azure-storage-php-client-libraries-will-be-retired-on-17-march-2024/).
This article shows you how to create tables, store your data, and perform CRUD operations on the data. Choose either the Azure Table service or the Azure Cosmos DB for Table. The samples are written in PHP and use the [Azure Storage Table PHP Client Library][download]. The scenarios covered include **creating and deleting a table**, and **inserting, deleting, and querying entities in a table**. For more information on the Azure Table service, see the [Next steps](#next-steps) section.
> This project is in the [community support](https://azure.github.io/azure-sdk/policies_support.html#package-lifecycle) stage of it's lifecycle. Eventually, all associated client libraries will be retired permanently. For more details on the retirement and alternatives to using this project, see [Retirement notice: Azure Storage PHP client libraries](https://azure.microsoft.com/updates/retirement-notice-the-azure-storage-ruby-client-libraries-will-be-retired-on-13-september-2024/).
This article shows you how to create tables, store your data, and perform CRUD operations on the data. Choose either the Azure Table service or the Azure Cosmos DB for Table. The samples described in this article are written in Ruby and uses the [Azure Storage Table Client Library for Ruby](https://github.com/azure/azure-storage-ruby/tree/master/table). The scenarios covered include create a table, delete a table, insert entities, and query entities from the table.
Copy file name to clipboardExpand all lines: articles/storage/file-sync/file-sync-server-endpoint-create.md
+12-12Lines changed: 12 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,21 +4,21 @@ description: Understand the options during server endpoint creation and how to b
4
4
author: khdownie
5
5
ms.service: azure-file-storage
6
6
ms.topic: how-to
7
-
ms.date: 06/01/2021
7
+
ms.date: 02/05/2024
8
8
ms.author: kendownie
9
9
---
10
10
11
11
# Create an Azure File Sync server endpoint
12
12
13
13
A server endpoint represents a specific location on a registered server, such as a folder on a server volume. A server endpoint must meet the following conditions:
14
14
15
-
- A server endpoint must be a path on a registered server (rather than a mounted share). Network attached storage (NAS) is not supported.
16
-
- Although the server endpoint can be on the system volume, server endpoints on the system volume may not use cloud tiering.
17
-
- Changing the path or drive letter after you established a server endpoint on a volume is not supported. Make sure you are using a suitable path before creating the server endpoint.
15
+
- A server endpoint must be a path on a registered server (rather than a mounted share). Network attached storage (NAS) isn't supported.
16
+
- Although the server endpoint can be on the system volume, server endpoints on the system volume can't use cloud tiering.
17
+
- Changing the path or drive letter after you established a server endpoint on a volume isn't supported. Make sure you're using a suitable path before creating the server endpoint.
18
18
- A registered server can support multiple server endpoints, however, a sync group can only have one server endpoint per registered server at any given time. Other server endpoints within the sync group must be on different registered servers.
19
-
- Multiple server endpoints can exist on the same volume if their namespaces are not overlapping (for example, F:\sync1 and F:\sync2) and each endpoint is syncing to a unique sync group.
19
+
- Multiple server endpoints can exist on the same volume if their namespaces aren't overlapping (for example, F:\sync1 and F:\sync2) and each endpoint is syncing to a unique sync group.
20
20
21
-
This article helps you understand the options and decisions needed to create a new server endpoint and start sync. For this to work, you need to have finished [planning for your Azure File Sync deployment](file-sync-planning.md) and also have deployed [resources needed in prior steps](file-sync-deployment-guide.md) to creating a server endpoint.
21
+
This article helps you understand the options and decisions needed to create a new server endpoint and start sync. For this to work, you need to have finished [planning for your Azure File Sync deployment](file-sync-planning.md) and also have deployed [resources needed in prior steps](file-sync-deployment-guide.md) to create a server endpoint.
22
22
23
23
## Prerequisites
24
24
@@ -68,7 +68,7 @@ A server endpoint can only succeed provisioning with the authoritative upload op
68
68
* New or updated files and folders will be uploaded from the server.
69
69
* Files and folders that don't exist on the server (anymore) will be deleted from the cloud share.
70
70
* Metadata-only changes to files and folders on the server will be efficiently moved to the cloud share as metadata-only updates.
71
-
* Files and folders might exist on server and the cloud share. But some files or folders may have changed their parent directory on the server since the seeding of the Azure file share. These files and folders will be purged from the cloud share and uploaded again. Because of this, it's best to avoid restructuring your namespace at a larger scale during a migration.
71
+
* Files and folders might exist on server and the cloud share. But some files or folders might have changed their parent directory on the server since the seeding of the Azure file share. These files and folders will be purged from the cloud share and uploaded again. Because of this, it's best to avoid restructuring your namespace at a larger scale during a migration.
72
72
73
73
### Initial download section
74
74
@@ -85,22 +85,22 @@ As part of this section, a choice can be made for how content from the Azure fil
85
85
:::column-end:::
86
86
:::column:::
87
87
***Namespace only** </br> Will bring only the file and folder structure from the Azure file share to the local server. None of the file content is downloaded. This option is the default if you previously enabled cloud tiering for this new server endpoint.
88
-
***Namespace first, then content** </br> For a faster availability of the data, your namespace is brought down first, independent of your cloud tiering setting. Once the namespace is available on the server, the file content is then recalled from the cloud to the server. Recall happens based on the last-modified timestamp on each file. If there is not enough space on the server volume, the remaining files will remain tiered files. This option is the default if you did not turn on cloud tiering for this server endpoint.
89
-
***Avoid tiered files** </br> This option will download each file in its entirety before the file shows up in the folder on server. This option avoids a tiered file to ever exist on the server. A namespace item and file content are always present at the same time. Avoid this option if fast disaster recovery from the cloud is your reason for creating a server endpoint. If you have applications that require full files to be present, and cannot tolerate tiered files in their namespace, this is ideal. This option is not available if you are using cloud tiering for your new server endpoint.
88
+
***Namespace first, then content** </br> For a faster availability of the data, your namespace is brought down first, independent of your cloud tiering setting. Once the namespace is available on the server, the file content is then recalled from the cloud to the server. Recall happens based on the last-modified timestamp on each file. If the free space on server volume is less than 10%, the remaining files will remain tiered files. This option is the default if you didn't turn on cloud tiering for this server endpoint.
89
+
***Avoid tiered files** </br> This option will download each file in its entirety before the file shows up in the folder on server. This option avoids a tiered file to ever exist on the server. A namespace item and file content are always present at the same time. Avoid this option if fast disaster recovery from the cloud is your reason for creating a server endpoint. If you have applications that require full files to be present and can't tolerate tiered files in their namespace, this is ideal. This option isn't available if you're using cloud tiering for your new server endpoint.
90
90
:::column-end:::
91
91
:::row-end:::
92
92
93
-
Once you select an initial download option, you cannot change it after you confirm to create the server endpoint.
93
+
Once you select an initial download option, you can't change it after you confirm to create the server endpoint.
94
94
95
95
> [!NOTE]
96
96
> When adding a server endpoint and files exist in the Azure file share, if you choose to download the namespace first, files will show up as tiered until they're downloaded locally. Files are downloaded using a single thread by default to limit network bandwidth usage. To improve the file download performance, use the [Invoke-StorageSyncFileRecall](file-sync-how-to-manage-tiered-files.md#how-to-recall-a-tiered-file-to-disk) cmdlet with a thread count greater than 1.
97
97
98
98
### File download behavior once initial download completes
99
99
100
-
How files appear on the server after initial download finishes, depends on your use of the cloud tiering feature and whether or not you opted to [proactively recall changes in the cloud](file-sync-cloud-tiering-overview.md#proactive-recalling). The latter is a feature useful for sync groups with multiple server endpoints in different geographic locations.
100
+
How files appear on the server after initial download finishes depends on your use of the cloud tiering feature and whether or not you opted to [proactively recall changes in the cloud](file-sync-cloud-tiering-overview.md#proactive-recalling). The latter is a feature useful for sync groups with multiple server endpoints in different geographic locations.
101
101
102
102
***Cloud tiering is enabled** </br> New and changed files from other server endpoints will appear as tiered files on this server endpoint. These changes will only come down as full files if you opted for [proactive recall](file-sync-cloud-tiering-overview.md#proactive-recalling) of changes in the Azure file share by other server endpoints.
103
-
***Cloud tiering is disabled** </br> New and changed files from other server endpoints will appear as full files on this server endpoint. They will not appear as tiered files first and then recalled. Tiered files with cloud tiering off are a fast disaster recovery feature and appear only during initial provisioning.
103
+
***Cloud tiering is disabled** </br> New and changed files from other server endpoints will appear as full files on this server endpoint. They won't appear as tiered files first and then recalled. Tiered files with cloud tiering off are a fast disaster recovery feature and appear only during initial provisioning.
> The content in this article applies to Azure Table storage and the Azure Cosmos DB for Table. The Azure Cosmos DB for Table is a premium offering for table storage that offers throughput-optimized tables, global distribution, and automatic secondary indexes.
12
+
> The content in this article applies to Azure Table storage and Azure Cosmos DB for Table. The API for Table is a premium offering for table storage that offers throughput-optimized tables, global distribution, and automatic secondary indexes.
0 commit comments