The complete recovery mode requires restoring a memory snapshot, which creates unnecessary recovery overhead when an application does not depend on the memory state. By setting fileSystemOnly=true when you call ResumeSession, you can skip memory and process state restoration and restore only the file system data. This allows you to obtain the same development environment at a faster speed and with lower recovery costs.
Overview
What is file system only recovery
Standard Deep Hibernation recovery (ResumeSession) fully restores an instance's memory, process state, and file system. The file system only recovery is a lightweight mode that restores only the file system changes made before the instance was paused, such as installed dependencies, downloaded model files, or generated intermediate data. It does not restore the in-memory state. After recovery, the instance starts with a fresh process, which is equivalent to creating a new instance based on the pre-pause file system.
Regardless of whether you use full recovery or file system only recovery, network connections established before the session was paused, such as WebSocket or long-lived gRPC connections, are not restored. The client must re-establish these connections.
Choose a recovery mode
If your application relies on its in-memory runtime state, such as in-process caches or global variables, choose full recovery. If you only need data on disk, such as installed dependencies, configuration files, or data files, choose file system only recovery.
Comparison item | Full recovery (default) | File system only recovery |
Memory state | Restored | Not restored (the instance starts with a fresh process) |
Process state | Restored to the pre-pause running state | Not restored (user processes must be restarted) |
Network connection | Not restored (the client must re-establish connections) | Not restored (the client must re-establish connections) |
File system | Restored | Restored |
API parameter |
|
|
Recovery speed | Slower (requires restoring a memory snapshot, whose size depends on the instance's memory specification) | Faster (only restores disk data and restarts the container processes) |
Use cases
Environment preservation: After installing numerous dependencies and configuring development tools and environment variable files in the Sandbox, you can use file system only recovery to quickly restore an identical development environment without needing to restore the memory and process states.
Fallback for failed full recovery: If a full recovery (memory + file system) fails, you can retry with
fileSystemOnly=trueto fall back to a file system only recovery. This preserves the changes made to the file system.Scenarios requiring only file data: Use this mode when you only need to restore data on disk, such as intermediate computation results or downloaded datasets, and do not depend on the in-memory runtime state.
Prerequisites
File system only recovery is an extension of Sandbox Deep Hibernation. Before you use this feature, meet the following prerequisites:
Meet all Deep Hibernation prerequisites: This includes applying for the allowlist, configuring session affinity and session isolation, using a custom image, and running on a CPU instance. For details, see Sandbox Deep Hibernation (Pause and Resume Session).
Additional allowlist application: This feature requires separate enablement. submit a ticket to request access to the "Sandbox Deep Hibernation - file system only recovery" capability.
This feature is managed on a separate allowlist from the full recovery feature. Even if you have already enabled Sandbox Deep Hibernation, you must apply separately to use the fileSystemOnly=true parameter.
Limitations and constraints
In addition to the general limitations described in Sandbox Deep Hibernation (Pause and Resume Session), file system only recovery has the following additional constraints:
With file system only recovery, in-memory data is not restored. Any data cached in memory before the pause, such as variables, objects, or connection pools, will be lost.
After recovery, the instance starts with a fresh process. Your application must be able to initialize itself, for example, by starting a service through the container's ENTRYPOINT.
We recommend designing your application to be restartable. This means the process can be fully initialized through the container image's ENTRYPOINT, and the data in the file system can be used directly after the process starts.
Procedure
Restore only the file system
When you call ResumeSession, set the fileSystemOnly=true parameter to restore only the file system.
API request syntax
PUT /2023-03-30/functions/{functionName}/sessions/{sessionId}/resume?fileSystemOnly=trueRequest parameters
Parameter | Type | Location | Required | Default | Description |
functionName | string | path | Yes | - | The name of the function associated with the session. |
sessionId | string | path | Yes | - | The ID of the session to resume. |
qualifier | string | query | No | - | The alias or version of the function associated with the session. |
fileSystemOnly | boolean | query | No | false | Set to |
Go SDK example
func resumeSessionFileSystemOnly(client *fc.Client, functionName, sessionId *string) (*fc.ResumeSessionResponse, error) {
return client.ResumeSessionWithOptions(
functionName,
sessionId,
&fc.ResumeSessionRequest{
FileSystemOnly: tea.Bool(true),
},
nil,
&dara.RuntimeOptions{},
)
}
// Example usage
func main() {
client, err := createClient()
if err != nil {
panic(err)
}
functionName := tea.String("my-sandbox-function")
sessionId := tea.String("my-session-id")
resp, err := resumeSessionFileSystemOnly(client, functionName, sessionId)
if err != nil {
fmt.Printf("ResumeSession (file system only recovery) failed: %v\n", err)
return
}
fmt.Printf("ResumeSession succeeded. Session status: %s\n", tea.StringValue(resp.Body.SessionStatus))
}For the implementation of the createClient() function, see Sandbox Deep Hibernation (Pause and Resume Sessions).
The session transitions from Resuming to Active. Call GetSession to check the status. After you confirm that the status is Active, you can continue to use the Sandbox by calling InvokeFunction.
Full recovery (default mode)
By default, ResumeSession performs a full recovery (memory, process, and file system):
func resumeSession(client *fc.Client, functionName, sessionId *string) (*fc.ResumeSessionResponse, error) {
return client.ResumeSessionWithOptions(
functionName,
sessionId,
&fc.ResumeSessionRequest{},
nil,
&dara.RuntimeOptions{},
)
}End-to-end workflow
The following example shows the complete workflow for using file system only recovery:
Create a function: Enable session affinity and session isolation, and select a custom image.
Create a session: Call
CreateSessionorInvokeFunctionto create a session.Use the Sandbox: Install dependencies, download models, or generate intermediate files.
Pause the session: Call
PauseSessionto save a snapshot and destroy the instance. You do not incur charges for CPU and memory while the session is paused.Restore only the file system: Call
ResumeSessionand setfileSystemOnly=true.Verify the recovery: Call
GetSessionto confirm that the session status is Active. Then, callInvokeFunctionto verify that the file system data is intact.Continue use: The file system is identical to its pre-pause state, but the process is newly started. To pause again, repeat steps 4 through 6.
Delete the session: When finished, call
DeleteSessionto release resources.
Complete Go SDK example
package main
import (
"fmt"
"os"
openapi "github.com/alibabacloud-go/darabonba-openapi/v2/client"
fc "github.com/alibabacloud-go/fc-20230330/client"
"github.com/alibabacloud-go/tea/dara"
"github.com/alibabacloud-go/tea/tea"
)
func main() {
// 1. Initialize the client.
client, err := fc.NewClient(&openapi.Config{
RegionId: tea.String("cn-shanghai"),
AccessKeyId: tea.String(os.Getenv("ALIBABA_CLOUD_ACCESS_KEY_ID")),
AccessKeySecret: tea.String(os.Getenv("ALIBABA_CLOUD_ACCESS_KEY_SECRET")),
Endpoint: tea.String("<Account ID>.cn-shanghai.fc.aliyuncs.com"),
})
if err != nil {
panic(err)
}
functionName := tea.String("my-sandbox-function")
headerKey := "x-session-id"
// 2. Invoke the function for the first time to automatically create a session.
invokeResp, err := client.InvokeFunctionWithOptions(
functionName,
&fc.InvokeFunctionRequest{},
&fc.InvokeFunctionHeaders{},
&dara.RuntimeOptions{},
)
if err != nil {
panic(err)
}
sessionId := invokeResp.Headers[headerKey]
fmt.Printf("Session created. Session ID: %s\n", tea.StringValue(sessionId))
// 3. Perform operations in the Sandbox (install dependencies, generate files, etc.).
_, err = client.InvokeFunctionWithOptions(
functionName,
&fc.InvokeFunctionRequest{},
&fc.InvokeFunctionHeaders{
CommonHeaders: map[string]*string{
headerKey: sessionId,
},
},
&dara.RuntimeOptions{},
)
if err != nil {
panic(err)
}
fmt.Println("Sandbox operations completed (dependencies installed, files generated, etc.).")
// 4. Pause the session (save a snapshot and destroy the instance).
pauseResp, err := client.PauseSessionWithOptions(
functionName,
sessionId,
&fc.PauseSessionRequest{},
nil,
&dara.RuntimeOptions{},
)
if err != nil {
panic(err)
}
fmt.Printf("PauseSession succeeded. Status: %s\n", tea.StringValue(pauseResp.Body.SessionStatus))
// 5. Restore only the file system.
resumeResp, err := client.ResumeSessionWithOptions(
functionName,
sessionId,
&fc.ResumeSessionRequest{
FileSystemOnly: tea.Bool(true),
},
nil,
&dara.RuntimeOptions{},
)
if err != nil {
panic(err)
}
fmt.Printf("ResumeSession (file system only recovery) succeeded. Status: %s\n", tea.StringValue(resumeResp.Body.SessionStatus))
// 6. Continue using the Sandbox (the file system is restored, and the process is newly started).
_, err = client.InvokeFunctionWithOptions(
functionName,
&fc.InvokeFunctionRequest{},
&fc.InvokeFunctionHeaders{
CommonHeaders: map[string]*string{
headerKey: sessionId,
},
},
&dara.RuntimeOptions{},
)
if err != nil {
panic(err)
}
fmt.Println("Function invocation after recovery succeeded. The file system data matches the pre-pause state.")
// 7. Delete the session when finished.
_, err = client.DeleteSessionWithOptions(
functionName,
sessionId,
&fc.DeleteSessionRequest{},
nil,
&dara.RuntimeOptions{},
)
if err != nil {
panic(err)
}
fmt.Println("Session deleted.")
}FAQ
What happens to in-memory data?
No. The file system only recovery mode restores only data on disk. All in-memory data, including variables, caches, and connection pools, is not restored. If your application depends on its in-memory runtime state, use full recovery.
Do user processes restart automatically?
Yes. After recovery, the instance starts with a fresh process, which is equivalent to creating a new container instance from the pre-pause file system. The system starts the user process based on the container image's ENTRYPOINT or CMD.
Which recovery mode is faster?
File system only recovery is usually faster because it does not need to restore a memory snapshot. The memory snapshot can be large, depending on the instance's memory. File system only recovery only needs to restore disk data and restart the container processes.
Is there an automatic fallback on recovery failure?
No, it does not fall back automatically. You must explicitly set the fileSystemOnly=true parameter when calling ResumeSession. You can implement this fallback in your application: first, attempt a default ResumeSession call for a full recovery. If it fails, retry the call with fileSystemOnly=true.
Does file system only recovery affect session TTL?
Yes. File system only recovery and full recovery follow the same session lifecycle management rules. The recovery mode does not affect the session time-to-live (TTL). The TTL continues to accumulate from the session's original creation time.