05 — Set up storage, accounts, and backups

TL;DR: Work out what data you need to protect, choose a disk layout, and set up access for each person and application. Test a backup and restore before switching to the new storage, and keep the original files until you have checked the result.

What you'll set up#

This chapter walks you through preparing the data drives, sharing files, and recovering a copy from backup. Your storage can live on the same server as your applications or on a separate machine. If you are using a storage appliance, ask your AI operator to adapt the steps to its supported interface.

Start with the installed server from Server setup. If you have not installed its operating system or set up your own login yet, do that chapter first. Here, you will create the storage and file-sharing accounts; you do not need them in advance.

Tell your AI operator who will use the files and which applications will need them. It can collect equipment details and prepare the configuration. You decide which existing files matter, which drives may be erased, and who should have access. Save those decisions and the configuration in your private GitHub repository.

Look at every drive before changing it#

Connect and inspect data drives only after the OS installation is finished. A drive that does not appear in a file browser may still contain data. Do not initialize or format an unfamiliar drive just to find out what is on it.

Have your AI operator list each drive's model, serial number, capacity, health, existing partitions, and any recognized filesystems. Match that list to the physical drives. Label bays and cables so you can find the right drive later. Linux names such as /dev/sdb can change; the serial number and a physical label are better identifiers.

If a drive contains files you want, copy them elsewhere and check the copy before authorizing any erasure. Open representative files and have your AI operator check copy errors, counts, sizes, and appropriate checksums. A checksum compares file contents; it does not tell you whether you copied everything you meant to keep.

Keep full hardware reports outside the repository if they contain information you have chosen not to share. Commit the useful equipment record and a reference to those reports. You can use labels such as disk-a in provider requests while keeping the serial-number mapping in your private archive. In that case, you must match the physical drive yourself before an erasing operation.

Prompt to paste:

Inspect the connected drives without changing them. Report durable IDs,
model/capacity, partitions, signatures, mounts, health, sector sizes, controller
connections, and any uncertainty. Match each drive to a bay/cable label with
my help. Classify it as containing data to keep, needing investigation,
backup/spare use, or a candidate I may authorize for new storage.
Do not initialize, repair, format, or erase during inspection.

Prepare a useful equipment record for Git and separate any sensitive raw
reports. Before a later destructive action, recheck the live devices,
show me what will be erased, and require my decision for those named drives.
Do not equate an unmounted drive with an empty one.

Check the drive connections#

For the basic setup, connect drives to motherboard SATA ports or NVMe slots. Use no RAID card and leave BIOS-provided RAID disabled. ZFS needs to work with the individual drives. If you need more ports, an appropriate HBA adds disk connections without combining the drives into a hardware RAID volume. Have your AI operator verify the card and its operating mode. OpenZFS hardware guidance

Do not use USB-attached primary storage for this guide. USB enclosures add a controller and connection that can disconnect or obscure drive information. A USB disk can still serve as a separate backup that you unplug after a checked copy.

If you need more bays, compare a larger case, a separate storage server, or a purpose-built enclosure with suitable SAS connections. Include cables, cooling, power, noise, and the physical space you need to service it. Do not improvise an external drive box with loose internal power and SATA cables.

New and reused drives both need testing. Ask your AI operator to investigate health warnings and run tests suited to the hardware. Copy valuable files first before stressing a questionable drive. Save health results so later checks can show what changed; a clean report cannot promise that a disk will never fail.

Decide what a loss would mean#

Your photo collection, a database, and a temporary download need different treatment. For each, tell your AI operator how much recent work you could afford to lose and how long you could manage without access.

A daily backup can lose up to the work done since its last successful run. A large remote backup may take days to download. Have your AI operator estimate those consequences using your actual data size and connection speed, then adjust the schedule or destination if that does not meet your needs.

Keep encryption keys and backup passwords in your password manager, plus a protected offline recovery copy. Do not put the only key inside the backup it unlocks.

Allow space for more than today's files#

Ask your AI operator to calculate usable capacity after disk redundancy, then allow for growth, old file versions, and room to test restores. Two mirrored 8 TB drives hold roughly one drive's capacity before filesystem overhead, not 16 TB of unique data.

As a planning starting point, leave at least 20% free after expected growth. Set an early warning around 70% used and plan expansion by 80%; investigate promptly near 90%. These are this guide's operating targets, not failure boundaries. Put space limits on large temporary workloads so a runaway cache does not consume the room you reserved.

Choose the data filesystem and disk layout#

The OS disk uses ext4 in the basic Ubuntu setup. This chapter uses ZFS for the separate data drives because it combines checks for damaged data, snapshots of earlier versions, and repair when an intact redundant copy exists. A two-drive mirror is a useful starting arrangement: each drive holds a copy, so either drive can fail without immediately losing access. OpenZFS checksums

ZFS groups disks into a pool and lets you divide its space into datasets. Think of a dataset as a separately managed area for files: one can have different permissions, backup schedules, or size limits from another while sharing the pool's available space.

For more drives, have your AI operator compare additional mirror pairs with RAIDZ2. RAIDZ2 uses space equivalent to two drives for redundancy and can withstand two drive failures within that group. The useful choice depends on drive count, capacity, workloads, and how you expect to expand. Ask for the usable capacity and the effect of specific failures in each proposed layout.

Do not add a lone drive to a mirrored pool to gain easy space. Losing an unprotected part of the pool can lose the whole pool. Plan expansion as carefully as the initial layout. With mirrors, you can add another mirror pair or replace both members with larger drives, one at a time and waiting for each rebuild. For other arrangements, have the AI operator check expansion support in the installed ZFS release. OpenZFS pool structure

If you have only one data drive, ZFS can still provide checksums and snapshots, but there is no second copy to repair a damaged block from. An independent backup becomes especially important. ext4 can suit simple single-drive storage; Btrfs or a storage appliance may suit other setups. Ask your AI operator to compare the installation, maintenance, and recovery work you would take on, instead of choosing solely because it can produce a command.

Understand what each copy protects#

Use local snapshots for convenient recovery and a separate backup destination for loss of the server. A snapshot on the same pool disappears if that pool is destroyed. File synchronization alone can spread an accidental deletion to every device.

Prepare the creation procedure#

Do not copy a generic pool-creation command from an example. It could erase the wrong drives. Ask your AI operator to prepare the procedure for the disks you approved, show a short erasure summary, and explain the resulting layout before you run it.

Prompt to paste:

Prepare the ZFS layout from our agreed disk and capacity plan. Bind every
destructive argument to verified serial/WWN and by-id paths. Recheck existing
signatures and contents immediately before execution. Stop on any mismatch.
Show me the drives to erase, resulting redundancy, usable capacity,
and expansion procedure. Have an independent review check the proposal;
state clearly if private device mappings were not visible to that reviewer.

Verify logical/physical sector sizes and choose ashift before creation,
accounting for replacement drives. Normally use 12 for 4 KiB/512e media;
justify another value from the actual hardware. Keep compression enabled,
dedup off, sync protection enabled, and avoid speculative cache/special vdevs.

Validate the complete script with harmless fixtures and a supported dry run.
Prepare a reviewed, root-owned copy that your account cannot alter, verify
its hashes, and install only those reviewed bytes. After execution, verify
pool identity, individual drives, topology, ashift, properties, and boot import.
Save the resulting configuration and test records, then commit and push.

Decide how encrypted data will unlock#

Encryption can protect removed or stolen data drives. If you store the unlock key on the same server and load it automatically, it does not protect against theft of the complete server in the same way as keeping the key elsewhere.

Decide which data needs encryption and whether someone may need to unlock it after a reboot. Have your AI operator explain and configure that choice before creating the datasets. Save each recovery key outside the server and test that you can retrieve it without the server running. If an independent device supplies keys automatically, include that device in the recovery and power plan.

Set up consistent accounts before sharing files#

Linux stores file ownership as numbers, even when it displays names. If the same number belongs to different people on two servers, sharing or restoring files can give access to the wrong person.

Have your AI operator create a versioned account record for people, groups, applications, and its own login. It should inspect existing accounts first and assign unused numbers consistently across the Linux machines that will share files. Keep retired numbers in the record rather than reassigning them to somebody else.

Start with local accounts managed from this record. Give each person an individual file-sharing login, and use groups such as household adults or household children where those groups match your actual access choices. An application should have its own account for its own data. The AI operator's login remains separate from those application accounts.

Prompt to paste:

Prepare consistent people, group, application, and AI operator accounts for
our storage and application hosts. Inspect existing UID/GID assignments and
container subordinate-ID ranges; reject collisions. Save the identity registry
in private GitHub and provision the same intended numeric ownership wherever
shared files require it. Preserve retired assignments.

If a directory service is a credible later choice, plan compatible ID ranges
and a migration that preserves current ownership. Do not deploy it just to
complete this chapter. Verify allowed and denied access with test files, and
include account reconstruction in the restore procedure.

If account maintenance across many machines later becomes repetitive, a directory service such as FreeIPA can centralize it. That also makes logins depend on more services, including working DNS and time synchronization. Ask your AI operator to demonstrate the benefit and recovery plan before adding it. A shared web login is a different feature; it does not automatically make file ownership consistent.

Separate files that need different access#

Create separate datasets when the files need different permissions, backup schedules, encryption, or size limits. You might start with household shared files, private files, a media library, and a separate area for each application's data.

Tell your AI operator who should read and change each area. Have it turn those answers into a small access table before creating permissions. For example, a media application may need to read the library but only write its own database. Household members need access to their files, not the server's credentials or backup administration.

Test with disposable files. Try the normal actions—create, read, rename, and delete—as an allowed user, then try access as someone who should be denied. Check the space limits too. Do this before putting your only copy of anything on the new storage.

Share files with household computers#

Use SMB, the file-sharing protocol supported by Finder and Windows Explorer. On the Linux server, Samba provides that service. Your AI operator should walk you through installing it, creating each person's file-sharing login, and defining the shares from your access table.

On the Mac, choose Go → Connect to Server in Finder and enter a name such as smb://files.home.arpa/shared. Sign in with your own file-sharing account and save the password in Keychain if appropriate for that Mac. Use the actual name and share your AI operator configured. Start with a test share, then confirm you can reconnect after restarting the server.

Prompt to paste:

Walk me through setting up Samba and individual file-sharing logins. Use our
recorded identities and access table. Prepare the full configuration, validate
it with testparm, and show the shares and users it permits. Use modern SMB
without guest fallback. Limit network exposure to the intended LAN/VPN clients.

Keep the previous configuration and prepare a reviewed installation procedure.
Test allowed and denied operations from the household's actual computers,
then repeat after a server reboot. Back up the original Samba local SID,
passdb, group mappings, and required persistent state using supported methods.
Keep passwords/hashes outside Git and your normal account. Commit protected
backup references and recovery instructions. Restore those identities and
representative ACLs in a disposable test and recheck actual client access.

Samba has its own account and permission metadata in addition to Linux usernames. Include it in protected backups so rebuilding the server does not change who can open existing files. Your AI operator should explain the restore test's result, not merely report that the configuration file parses. Samba configuration reference

Connect applications to separate storage when needed#

If an application and its data share one server, you may not need network file sharing between them. With separate Linux application and storage servers, NFS is one option when the application supports it. Let the application's storage requirements decide; some databases need local storage or specific network-storage guarantees.

With common NFS setups, the storage server trusts identity numbers supplied by the client. Restrict it to trusted servers, use the matching application accounts, and keep the default protection that prevents remote administrator requests from automatically becoming storage-administrator requests. That protection is called root squashing. It does not prevent a compromised client administrator from impersonating another allowed account.

Prompt to paste when an application needs NFS:

Check that this application supports the proposed NFS storage. Map its actual
process UID/GID, including container mappings, to our registry. Export only
its required dataset to the intended client and keep root_squash enabled.
Test application writes and ownership, denied users, and missing storage.
Explain AUTH_SYS client trust, including nonzero-UID impersonation by client
root. If that trust is unacceptable, propose authenticated NFS or another
supported storage arrangement before deployment. Do not broaden permissions
to hide a startup-order or identity problem.

On Linux, if a network filesystem is absent, the directory underneath it can still exist. An application may accidentally write there, filling the OS disk. This concerns Linux mount paths, not how Finder presents a disconnected share. Test that the application checks its intended storage before starting and refuses to write elsewhere.

Avoid letting people and applications edit the same files through different sharing protocols unless the application supports that workflow. Their locking and permissions can differ. A separate import folder is often easier to understand and test.

Set up backup before moving your files#

This guide uses restic for encrypted file backups. It can restore files to a different machine without requiring the original ZFS pool. Have your AI operator prepare a scheduled backup service on the server; backups must continue when its interactive session is closed.

Choose an independent destination, preferably off-site for data you cannot replace. A daily backup and at least a month of history are useful starting points, but use the loss and recovery targets you chose earlier. Local snapshots can run more frequently for quick recovery from an editing mistake.

The backup job needs both a password to open the encrypted repository and a credential to reach the destination. Enter them directly into the protected service credential store prepared for that job. Save recovery copies in your password manager and protected offline archive. Keep the actual values out of chat, Git, and the AI operator's ordinary account.

Give the routine backup job permission to add backups while keeping deletion of old backups under a different credential and maintenance process. Otherwise an attacker who controls that job may erase your history. Have your AI operator verify what the selected destination actually enforces; calling a credential “backup-only” does not restrict it.

Prompt to paste:

Set up scheduled restic backups for every path in our protection plan, using
a dedicated protected service and credential store. Include supported database
exports and required ownership, ACL, xattr, and Samba identity metadata.
Fail the run if any selected source or required metadata is unreadable.
Keep routine remote credentials append-only where the backend supports it;
put delete/prune authority in a separate protected maintenance process.

Complete the recurring-protection record with installed schedules, owners,
source references, limits, history policy, last-run results, alerts, and the
procedure to disable a job. Test a scheduled run with your session disconnected
and a harmless synthetic failure that reaches the intended alert recipient.
Restore representative files and application exports to a new limited-size
location, verify ownership/access, and open the files or restored application.
Commit configuration and results references; never commit credentials.

Use the recurring protection record to track the installed jobs. Ask your AI operator to fill in details it can inspect. You supply the decisions about what needs protection and how much history to keep.

A repository integrity check is useful, but you still need an actual restore. Start with a few representative files and their permissions, then a disposable instance of an application. Time the work so you know whether a larger recovery would fit your needs. Restic backup and restore workflow

Other backup destinations#

A friend or another household can hold an encrypted backup without having its decryption key. Agree on storage limits, bandwidth, and how either party ends the arrangement. Their administrator can still delete the encrypted files unless another mechanism prevents it. Encryption protects contents, not availability.

Commercial storage can provide version history or deletion protection. Check who can change that protection, what happens if billing fails, and what downloading a full recovery would cost. Test the actual backend with restic rather than assuming its “immutable” label guarantees compatibility or recovery.

ZFS replication can provide an additional copy that restores quickly to another ZFS system. Keep independent historical backups too. A second system that automatically repeats deletions and lets the source erase its history does not solve the same problem.

Decide how you'll use files away from home#

You can open your home shares through the VPN, but performance depends on your home's upload speed and connection reliability. For documents needed offline on phones or laptops, a file-sync service may be more convenient. Keep separate backups because synchronization can copy damage and deletions too.

Do not put a live database in a consumer sync folder. Keep the database where the application expects it and back it up using the application's supported method. If several places may edit the same files, decide which copy is authoritative and how conflicts will be handled. Test a disconnection and reconnection with disposable data before relying on that arrangement.

Copy files and switch over gradually#

Once a backup restore works, copy the existing files to the new storage. Keep the original unchanged. Ask your AI operator to compare the copies and preserve the ownership, permissions, timestamps, and other metadata those files need.

For an application, schedule a pause in writes before the final copy or export. Switch one client or application first, check its normal functions, then switch the others. Update the backup job to cover the new paths and test a restore from them.

Agree on how long you will keep the old copy and what checks must pass before you erase it. If people have made new changes on the new system, returning to the original requires a plan for those changes; simply switching back could lose them. Treat erasing the original as a separate decision tied to its drive.

Check recovery and save the instructions#

Restart the storage server with the AI operator's session closed. Confirm that shares return, expected encryption unlocks work, and allowed and denied logins behave correctly. Recover one disposable file from a snapshot and another from the independent backup. Check that scheduled jobs and their failure alerts work without an active AI session.

Have your AI operator commit and push the disk and account records, configuration, access table, backup schedule, and tested recovery instructions to private GitHub. Keep secrets and sensitive raw exports in the protected archive, with references in the records, and refresh your offline recovery copy. Continue to household services with storage you have actually restored from.