NFS Archives Through S3: Prove the Restore Semantics

Evaluate an NFS-to-S3-to-NFS DataSync archive by restored content, ownership, links and reader access. Includes a failed group-mapping scenario and a...

Primary sources checked 2026-10-09

Decide what a restored archive must let people do

An NFS archive can pass its file-content checks and still fail restoration. A reader might lose access because the restored group number means something different on the recovery host. A link might resolve outside the restored tree. An empty directory needed by the application might disappear from a custom object-copy process.

Before moving the archive through Amazon S3, define the properties and access outcomes the restored NFS tree must satisfy. Then evaluate the exact forward and return path against that contract. Retain the original recovery path while a mandatory property or observation remains unknown.

This guide helps a storage engineer choose among retaining a filesystem-native archive, using an AWS DataSync round trip, or deliberately adopting an object-based archive with different semantics. The deliverable is a property contract and an accepted, rejected or held restoration decision. It does not authorize source deletion.

The worked project tree, identities, groups and transfer attempts are fictional. Its local assertions inspect synthetic manifests and a small permission model. No DataSync task, NFS mount, S3 request, recovery test or customer migration was executed. The two figures separate proposed transfer paths from stipulated acceptance evidence; neither establishes an executed recovery.

Bound the location pair before discussing preservation

The reference path is one NFS export, a DataSync agent, an Amazon S3 general purpose bucket prefix, and a separate NFS recovery export. Choose Basic mode for this proposed exercise and identify both task directions explicitly. The forward task's destination becomes the return task's source; the destination export and its administrative authority are different resources.

AWS supports an NFS location as a source or destination and requires an agent to access it. Its NFS guidance also excludes NFSv4 ACL copying and requires an export accessible without Kerberos. A workload dependent on those features needs another supported design or separately accepted treatment. Do not remove a production authentication boundary to make this example fit. AWS NFS location requirements.

Use a frozen synthetic tree first. The reader needs ordinary files, directories, a zero-byte file and the link types the real archive uses. List excluded properties, including filesystem snapshots, quotas, locks, open-file state, extended attributes and application references outside the tree. Their absence from this guide is not a claim that DataSync preserves or discards each one. An exact requirement in that list remains a support-and-test question.

The platform migration playbook owns broader dependency assessment and cutover governance. Here the narrower question is whether this file/object/file path preserves the agreed restore behavior. For paired application and database state, use a separate reconciliation contract; a file tree cannot establish a common checkpoint with an independently changing database.

Compare the three archive designs against the same contract

Keeping a filesystem-native recovery method can be the least disruptive choice when exact filesystem semantics dominate. It still needs evidence of supported recovery, identity configuration and access. “Keep NFS” does not identify a backup mechanism or prove that a failed storage system can be recovered.

A DataSync round trip is a candidate when the required location-pair properties are supported, the stored representation remains intact, and the return path has the necessary authority. This adds an object representation and another restore dependency. The task is to validate that representation, not to assume that successful upload makes the source redundant.

An application-level object archive changes the contract deliberately. The application might retrieve immutable documents by identifier without restoring Unix ownership or hard-link relationships. That can be a valid design if the owner accepts it and the application protects readers through its own authorization path. It is unsuitable when an existing program expects to traverse the original NFS tree unchanged.

Filesystem-native recovery

Suitable requirement: Required file semantics are supported by the chosen recovery method

Evidence that blocks acceptance: Untested restore, unavailable identities or unsupported required property

DataSync NFS/S3/NFS

Suitable requirement: Required properties survive the selected pair and retained representation

Evidence that blocks acceptance: Missing metadata, changed link relationships or failing reader tests

Application object archive

Suitable requirement: Owner accepts new access and retrieval behavior

Evidence that blocks acceptance: An unchanged NFS application remains a mandatory consumer

Choose a design using the hardest mandatory property, not the largest ordinary file. A thousand matching documents cannot compensate for one unsupported permission rule on the only restricted directory.

Separate stored metadata from effective access

For NFS-to-S3 transfers, AWS documents user metadata for modification times, numeric UID/GID and POSIX permissions. Access-time preservation is best effort. A DataSync return to NFS can restore that metadata with elevated destination permissions. Missing DataSync-applied metadata can instead produce documented default ownership and modes. Treat missing required metadata as a failed contract, not an invitation to accept defaults. AWS metadata behavior.

Those numbers do not identify your business readers by themselves. The recovery host's identity mapping, supplementary groups, export configuration and directory traversal rules help determine what a client can do. Compare the numeric properties and test the intended identities separately. The local model later in this guide assumes simple mode-bit access only; it cannot reproduce a real NFS server's entire authorization path.

File content

Independent restore question: Does this path contain the expected bytes from the accepted revision?

UID/GID and mode

Independent restore question: Are the recorded numbers and mode bits correct for this entry?

Directory access

Independent restore question: Can the intended reader traverse the full restored path?

Reader meaning

Independent restore question: Do the recovery identities represent the same permitted and excluded people?

Modification time

Independent restore question: Does the observed value meet the declared precision and comparison rule?

Access time

Independent restore question: Is best-effort preservation acceptable, or does this requirement disqualify the path?

Do not equate S3 access with these NFS checks. DataSync uses an IAM role for its S3 location, while a restored NFS client has a different access path. Bucket restrictions and encryption-key access must be reviewed for the actual transfer direction. The AWS S3 location page describes these dependencies; a mode field on an object is not an S3 authorization policy. AWS S3 location permissions.

Inspect link relationships and directories explicitly

AWS documents directory representation in S3 as empty objects ending in /, symbolic-link target paths stored in objects, and conditional hard-link restoration. Its hard-link guidance distinguishes initial and incremental transfers and conditions restoration on an unchanged link in S3. Preserve the representation and test the actual repeated-transfer path. Do not generalize this to an arbitrary downloader or rewritten archive. AWS links and directories.

The restore manifest should distinguish an ordinary empty file from an empty directory and a symbolic link. A generic “zero bytes” check cannot identify their types. Record a symbolic link's literal target without following it when inspecting the link itself. Then separately check where the application resolves it under the intended recovery mount.

For hard links, compare relationships within the restored filesystem, rather than comparing source inode numbers with destination inode numbers. Two names that should refer to one underlying file must remain associated. Equal content hashes alone cannot establish that relationship. Avoid changing a supposedly shared file to test this on production; inspect supported metadata and use a separately authorized synthetic copy for any mutation test.

Relative link latest → report.txt in the example stays within its parent directory. An absolute link to an old mount can retain its literal text and still fail the application path. A link resolving into a live source mount might even make a restore appear successful by reading the wrong copy. Record and deny that dependency before acceptance.

Establish the evidence before a transfer attempt

The file owner creates an independent manifest from a stable source boundary. Include entry type, relative path, file bytes and digest where appropriate, numeric ownership, mode, required timestamp and link relationships. Record the export root, namespace mapping, exclusions and the extraction procedure. Keep the manifest outside the tree being transferred so the recovery copy cannot supply its own expected answer.

Stop or account for writers using the archive's supported procedure. A transfer task is not assumed to create an application-consistent snapshot of an actively changing tree. If files continue changing, describe a supported snapshot or another defensible capture method and bind the manifest to it. Do not patch mismatches by continually refreshing the expected digest from whichever copy looks newest.

The platform operator records the source export, bucket/prefix, return export, agent, task mode and effective options for each execution. Task-level settings can be overridden at execution, so retaining only a screenshot of the originally intended task is inadequate. Use the DataSync Options reference to inspect the actual configuration rather than relying on names such as “archive-safe.”

For the proposed Basic-mode fixture, review these choices on both tasks. They are deliberate exercise settings, not a universal configuration to paste into production:

Uid and Gid

Proposed value and boundary: INT_VALUE; preserve numbers, then verify reader meaning separately

PosixPermissions

Proposed value and boundary: PRESERVE; validate required mode bits on recovery

Mtime and Atime

Proposed value and boundary: PRESERVE and BEST_EFFORT; this pair respects Basic-mode coupling, without guaranteeing access time

PreserveDeletedFiles

Proposed value and boundary: PRESERVE; retain extras for investigation rather than authorizing deletion

OverwriteMode

Proposed value and boundary: ALWAYS only within the isolated attempt; different source metadata or data can replace destination state

TransferMode

Proposed value and boundary: CHANGED; bind a repeat to the accepted revision and review the same-size S3 return caveat below before reusing a task

Changing an option changes what the reviewer must prove. Record a mismatch as a held or rejected candidate instead of silently accepting a different return behavior.

The security owner separates source read/traverse authority, S3 transfer authority, recovery metadata-setting authority and ordinary reader access. AWS requires root access for an NFS destination to set ownership and other metadata. Limit any elevated recovery export to the approved agent and exercise boundary under the administrator's reviewed configuration. This guide supplies no production export change or broad IAM policy. A successful privileged read cannot substitute for an ordinary-reader test. AWS destination-export requirements.

Worked archive: matching numbers, wrong readers

Assume archive revision R1 contains the following six entries. All are owned by UID 1200 and GID 2400. Directories use mode 0750; ordinary file paths use 0640. The link's literal target and type are recorded separately, without treating symbolic-link mode bits as a portable access control.

project

Expected type and content: Directory

project/report.txt

Expected type and content: File containing approved followed by one newline

project/report-copy.txt

Expected type and content: Another hard-link name for the same underlying report

project/empty.txt

Expected type and content: Ordinary zero-byte file

project/latest

Expected type and content: Symbolic link whose target text is report.txt

project/empty

Expected type and content: Empty directory

The report payload is nine UTF-8 bytes. The two report names each expose those nine bytes, giving 18 logical file-path bytes plus the zero-byte file. They represent one nonempty underlying payload. This arithmetic describes the fixture, not S3 object counts, billed storage, deduplication savings or DataSync's internal representation.

The file owner independently accepts R1. On the source, reader UID 1300 belongs to group 2400 and can traverse project and read the report. An excluded reader UID 1400 belongs to group 3400 and must be denied. Neither reader is root or the file owner. Bind each reader label to exactly one observed numeric UID and its group evidence. A different UID rejects this contract; missing identity evidence or duplicate reader records hold the decision until resolved.

Now stipulate a completed return copy with matching bytes, entry types, UID/GID, modes and link relationships. On the recovery host, the intended reader belongs to group 3400, while the excluded reader has acquired group 2400. The preserved numbers have not moved, but their business meaning has.

File hashes and sizes

Fictional result: Match R1

Decision: Content passes only

Recorded UID/GID/modes

Fictional result: Match R1

Decision: Numeric metadata passes only

Link relationships and empty entries

Fictional result: Match the independent manifest

Decision: Structure passes only

Intended reader traverses and reads

Fictional result: Denied by the modeled directory permissions

Decision: Restore acceptance fails

Excluded reader traverses and reads

Fictional result: Allowed by the modeled group membership

Decision: Confidentiality expectation fails

These are stipulated local inputs, not results of an AWS transfer. The fixture reproduces the decision error: a bytes-and-metadata-only comparator reports agreement while both required reader outcomes fail. Changing every file to a broad readable mode would hide the access defect and violate the excluded-reader requirement.

Reject this R1 recovery candidate and hold restoration acceptance. The fixture's REJECT describes the known failing candidate; the figure's “HOLD acceptance” describes the operating decision while the failure remains unresolved. Missing or ambiguous mandatory observations instead return the fixture's HOLD. The identity owner must resolve the recovery group mapping through an approved process, then repeat both permitted and denied reader tests. An authorized metadata translation is a different candidate contract and needs its own mapping version and evidence. It cannot be described as an unchanged faithful restore merely because the application starts afterward.

*Solid blue arrows show the proposed forward and return data path; dashed gray arrows carry separate property and reader-context evidence. Matching UID/GID and mode bits do not establish intended reader access. The fictional R1 candidate returns REJECT; “HOLD acceptance” is the operating action, not the fixture enum for that known failure. No S3 IAM equivalence, complete filesystem image or executed transfer is shown.*

Missing metadata and interrupted retries need new decisions

Consider a second synthetic observation where the two report payloads match but required numeric ownership is absent from the archive evidence. Do not fill in the manifest from the recovered file or assume the object's presence proves metadata retention. The contract remains unsatisfied until the owner establishes how the required properties survive the stored representation and return path.

Now suppose a new source revision R2 changes the report to amended followed by a newline, eight bytes. The independent R2 contract updates both hard-link names and the required modification time. A fictional interrupted attempt leaves one name with R2 content and the other with R1 content. Even if every path exists, neither a path count nor a successful later request proves a coherent restored revision.

DataSync's changed-data, overwrite and destination-deletion options answer different questions. Preventing overwrite can retain a differing destination entry; preserving destination-only files can retain stale extras. Deleting destination-only data is a distinct, potentially destructive choice, and cannot be combined with transferring all data. Review both directions and execution overrides before any rerun. AWS transfer and handling options.

The S3-to-NFS return has another boundary. AWS documents that later runs of the same S3-to-filesystem task omit modified objects whose size matches the first transfer. ALWAYS permits overwriting a selected entry; it does not establish that every changed object was selected. AWS S3 object considerations.

The local R3 case therefore changes approved plus a newline to rejected plus a newline, still nine bytes. Its independent contract pins the new digest. Observed old bytes fail even when names, sizes, ownership, modes and recorded timestamps match. This is a synthetic stale-content check, not a reproduction of DataSync's selection behavior.

*The upper path is return context, not evidence that an object was selected or copied. Dashed evidence inputs compare the independently accepted R3 digest with stipulated stale R1 observations. R1 and R3 are archive revisions, not S3 version IDs; recording a version when used does not select an older version for transfer. The same-size warning applies to subsequent executions of the same S3-to-filesystem task after its initial transfer. ALWAYS permits replacement of selected entries, not their selection. This fixture does not validate a workaround or an AWS execution.*

For this proposed first rehearsal, retain destination-only data and use isolated, attempt-specific recovery exports. Explain every extra path rather than deleting it to make counts agree. If the accepted archive is R1, keep its evidence distinct from R2. A retry may continue an attempt only when its scope and inputs still match; otherwise give it a new revision and acceptance decision. Do not rename an interrupted attempt “passed” after inspecting only the final file transferred.

For a changed archive, record the return task and execution IDs, whether the task was reused, its initial transfer boundary and the destination attempt. Hold acceptance until the owner reviews the return plan and an independent comparison covers every contracted path. A fresh isolated return can be proposed for rehearsal, but this guide has not validated it or an option change as a workaround. A new revision label, ALL or ALWAYS alone cannot close the evidence gap.

Verify the transferred scope, then test the restored use

DataSync checks integrity during transfer and offers additional end-of-transfer verification. ONLY_FILES_TRANSFERRED checks that execution's transferred data and metadata. Basic-mode POINT_IN_TIME_CONSISTENT checks source and destination synchronization, subject to documented scope; a DataSync manifest limits verification to its listed population. NONE omits the additional final check. None of these options establishes that your recovery identities have the intended business access. AWS verification choices.

For the proposed tiny Basic-mode rehearsal, evaluate POINT_IN_TIME_CONSISTENT with an isolated S3 Standard prefix and a frozen fixture. Retain the actual chosen option and execution result. This is not a universal recommendation for a large production archive. If storage class or task mode requires another verification choice, document the resulting population and complement it with independent checks. Do not label untransferred or excluded entries verified by a transferred-only result.

Validate the return export by its exact identity and mount path. First compare against the independent manifest. Then use ordinary exercise identities for one permitted read, one denied read and required directory traversal. If write prohibition is part of the contract, design a separately authorized synthetic write probe whose surprising success can be contained. A local read-only mount alone does not prove server-side write denial.

Link resolution belongs in application verification: latest must resolve to the restored report without reaching the old mount. The empty directory must exist as a directory. Hard-linked names must have the accepted relationship on the recovery filesystem. Keep content, structure, numeric metadata and effective access as separate evidence columns; a single green transfer status obscures which obligation remains untested.

Keep archive retrieval and source retirement outside the shortcut

The first exercise uses S3 Standard to isolate restore semantics from archive retrieval. If a later design selects S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive, AWS requires objects to be restored before DataSync can read them and restricts the available whole-destination verification choice. Include retrieval readiness, temporary availability and reattempt planning in that design. Do not promise a recovery time from this small local example. AWS storage-class considerations.

Budget the authorized exercise for transfer, object requests, retained data and the recovery environment using current rates for the actual Region and configuration. This guide does not model prices or claim that an object archive is cheaper than keeping the source recovery method. A valid restore contract can still fail the owner's time or economic requirement.

Keep the old recovery method until its separately reviewed replacement criteria are met. Source retirement requires consumer, retention, recovery-custody and financial decisions beyond this guide. The cross-account EFS restore playbook addresses a different recovery-point and permission exercise; its passing result would not certify an NFS/S3/NFS DataSync path.

Fill the property contract and record the held evidence

The filled record below belongs to the fictional group-mapping failure. Replace role labels with accountable people only in a real change record. Keep private identifiers and file contents in the approved evidence store, not a public enquiry.

Scope

Filled R1 observation and decision: Six-entry project fixture; frozen R1; NFS/S3/NFS; Basic mode proposed, not executed

Mandatory behavior

Filled R1 observation and decision: Identical content and declared structure; reader 1300 allowed; reader 1400 denied

Numeric representation

Filled R1 observation and decision: UID 1200, GID 2400, directory 0750 and ordinary file 0640 stipulated preserved

Failure

Filled R1 observation and decision: Recovery memberships reverse the intended group access; both reader expectations fail

Owner and next evidence

Filled R1 observation and decision: Identity owner reviews mapping; file owner repeats allowed/denied paths after an approved correction

Decision

Filled R1 observation and decision: Reject the R1 candidate; hold restoration acceptance and retain the source recovery method; no source retirement or production access change authorized

Use separate rows for every mandatory property instead of a blanket “metadata preserved” field:

Scope and checkpoint

Record for your bounded archive: Export identity, accepted revision, stable-capture method, included paths and exclusions

Required meaning

Record for your bounded archive: What content, type, ownership, link or reader behavior must survive?

Stored representation

Record for your bounded archive: What does the exact forward path retain, and how is that independently observed?

Return interpretation

Record for your bounded archive: Destination filesystem, identity map, namespace and required administrative authority

Expected check

Record for your bounded archive: Independent expected digest, type, relationship or allowed/denied operation

Actual evidence

Record for your bounded archive: Attempt identity, effective settings, completion, observation and evidence reference

Exceptions

Record for your bounded archive: Supported deviation, owner acceptance, consequence and expiry; UNKNOWN stays unresolved

Decision

Record for your bounded archive: Accept the bounded property, reject the candidate or hold for named missing evidence

Have another operator use the record to identify what failed without reading the source system. If they cannot distinguish missing ownership from wrong group meaning, refine those fields before scheduling a real transfer.

Rehearse failures before choosing the archive path

The companion offline fixture checks the fictional cases only. It does not serialize DataSync's S3 metadata, implement an NFS server, simulate AWS retries or certify a filesystem. A separately authorized disposable rehearsal would still need actual forward/return executions, metadata inspection and client probes.

Correct bytes, wrong recovery groups

Expected acceptance result: Fail effective access even when numeric metadata matches

Content preserved but required ownership missing

Expected acceptance result: Fail property contract; defaults are not evidence

Link replaced by an ordinary file

Expected acceptance result: Fail type or relationship despite matching content

Empty directory omitted

Expected acceptance result: Fail expected path population

R2 attempt contains an R1 hard-link name

Expected acceptance result: Fail the accepted revision and relationship contract

Extra destination-only file remains

Expected acceptance result: Fail exact population until an owned exception is accepted

Mandatory observation is UNKNOWN

Expected acceptance result: HOLD rather than accepting the other passing dimensions

The next useful step is to write the contract for one representative archive tree and identify its hardest mandatory property. If that property cannot survive the selected path, choose another design before moving the archive. If it can, ask the storage and identity owners to review a bounded round-trip rehearsal with explicit cost, isolation and cleanup authority. An AWS migration review can start from that contract and its unresolved evidence, without treating this educational fixture as completed recovery.