Back Up a Local MCP Environment

Back Up a Local MCP Environment

A local MCP environment may depend on more than the Feluda application.

It can include:

• Feluda user data;
• Studio workflows;
• RunFlows history;
• Journal entries;
• local model settings;
• downloaded AI models;
• MCP server configuration;
• local files and databases;
• approved permissions;
• scheduled workflows;
• recovery notes; and
• protected credentials.

A useful backup preserves what is needed to restore the environment without exposing private values.

What a backup should achieve

A backup should help you recover after:

• device failure;
• accidental deletion;
• operating-system problems;
• storage corruption;
• failed software updates;
• damaged workflow files;
• local database failure;
• lost configuration;
• server replacement; or
• migration to another approved computer.

A backup is not complete until you know how to restore it.

Start with the complete environment

Map the local workflow before choosing what to preserve.

For example:

Feluda
→ Local AI Model
→ Local MCP Server
→ Local Source Files
→ Studio Workflow
→ Local Output

Each part may store information in a different location.

Backing up only one folder may not restore the complete task.

Create a backup inventory

Record every item the environment depends on.

Include:

• Feluda user data;
• workflows;
• Journal entries;
• Genes and related resources;
• settings;
• local provider configuration;
• MCP connection details;
• source folders;
• output folders;
• local databases;
• model names and versions;
• model-runner settings;
• schedules;
• permission rules;
• server installers or setup notes;
• recovery instructions; and
• ownership information.

Do not include raw credentials in ordinary documentation.

Understand Feluda user data

Feluda stores user content separately from the application files.

This can include:

• flows;
• Journal entries;
• Genes;
• settings;
• saved configuration; and
• other user-created application data.

The exact user-data location depends on the operating system.

Feluda data on Windows

Feluda's public installation guidance identifies the user-data location as:

%APPDATA%\Feluda\

This location may contain:

• flows;
• journals;
• Genes;
• settings; and
• related user data.

Back up the complete Feluda user-data folder when it is safe and appropriate.

Feluda data on Linux

Feluda's public installation guidance identifies the user-data location as:

~/.config/Feluda/

Or:

$XDG_CONFIG_HOME/Feluda/

The actual location depends on the user's Linux configuration.

Confirm the path before creating the backup.

Feluda data on macOS

The exact local user-data location may depend on the installed Feluda build and macOS application settings.

Use the current Feluda installation guidance and your operating system's application-data tools to identify the active user-data location.

Confirm the folder by checking that it contains current Feluda content before backing it up.

Do not rely on the application folder

The installed Feluda application is not the same as your personal data.

Application files can usually be reinstalled.

User-created flows, journals, settings, and related content may be much harder to recreate.

Prioritise user data and recovery information.

Back up Studio workflows

Studio workflows may contain:

• block layout;
• prompts;
• model selection;
• tool selection;
• input mappings;
• output mappings;
• branch logic;
• error paths;
• no-result paths;
• permission settings; and
• write-action controls.

These workflows are often the most valuable part of the environment.

Record workflow dependencies

For every important workflow, record:

• workflow name;
• purpose;
• selected provider;
• selected model;
• MCP server;
• MCP tools;
• source locations;
• destination locations;
• required permissions;
• scheduled use;
• reviewer; and
• known-good test.

A workflow file alone may not explain what external services it needs.

Back up Journal content

Journal entries may contain:

• generated reports;
• workflow output;
• research notes;
• local records;
• user-written notes; or
• recurring summaries.

Decide which entries must be preserved.

Sensitive Journal content should follow the same privacy rules as the source data.

Back up local source files

MCP tools may depend on local:

• documents;
• spreadsheets;
• reports;
• images;
• datasets;
• configuration files;
• reference material;
• project folders; or
• exported records.

Preserve the folder structure when paths matter.

A workflow may fail after restoration if the source appears in a different location.

Back up local output files

Review whether generated output must be preserved.

This may include:

• reports;
• exported records;
• generated documents;
• analysis results;
• temporary review files;
• approved final files; or
• workflow logs.

Do not back up temporary or disposable content without a clear reason.

Separate source and output backups

Keep source and generated output clearly separated.

For example:

Source:
/projects/atlas/source

Output:
/projects/atlas/results

Backup:
/backups/atlas/source
/backups/atlas/results

This makes restoration and verification easier.

Back up local databases

A local database may require a dedicated backup method.

Copying an active database file may not create a reliable backup.

Follow the database's approved export or backup process.

Record:

• database name;
• version;
• host;
• port;
• backup command or method;
• backup date;
• restoration method; and
• verification result.

Do not record raw database passwords.

Back up MCP server configuration

Preserve the information needed to reconnect the local MCP server.

Record:

• server name;
• owner;
• installer or package source;
• version;
• endpoint;
• port;
• startup method;
• available tools;
• required local services;
• source paths;
• destination paths;
• permission rules;
• update process; and
• known-good test.

Store this record with the backup documentation.

Back up tool mappings

Record which workflows use which tools.

Use a table such as:

Workflow	MCP server	Tool	Purpose
Local Document Search	Local Documents MCP	Search Documents	Retrieve local references
Project Summary	Local Project MCP	Read Project Files	Collect source material
Save Report	Local Files MCP	Write File	Save approved output

This helps rebuild connections after restoration.

Back up permission records

Record the intended permission boundaries.

Include:

• read or write access;
• approved accounts;
• approved URLs;
• approved IP addresses;
• approved paths;
• approved ports;
• source scope;
• destination scope; and
• review requirements.

Do not use the backup to expand permissions beyond the original approved scope.

Back up schedule information

Record important schedules.

Include:

• schedule name;
• workflow;
• frequency;
• time;
• timezone;
• expected input;
• expected destination;
• normal runtime;
• conflict considerations;
• reviewer; and
• pause conditions.

Restored schedules should be tested before they are resumed.

Back up model information

Local model files can be large.

You may choose to preserve:

• the model files themselves;
• the exact model name;
• the exact version;
• the model-runner version;
• download source;
• local endpoint;
• context settings;
• hardware settings; and
• known-good prompt tests.

The right choice depends on storage, recovery time, and internet availability.

Decide whether to back up model files

Backing up model files may be useful when:

• internet access is limited;
• the model version may disappear;
• exact reproducibility matters;
• download time is long;
• the environment must recover quickly; or
• the model is required for offline operation.

It may be unnecessary when the model can be downloaded again easily and the exact version is recorded.

Record model checksums when needed

For high-assurance environments, record a file checksum or another approved integrity value.

This can help confirm that the restored model file matches the original.

Use a method supported by your organisation.

Back up model-runner configuration

Record:

• runner name;
• runner version;
• local endpoint;
• port;
• startup behaviour;
• installed models;
• model settings;
• storage location;
• hardware options; and
• update process.

Do not assume that a reinstalled runner will use the same defaults.

Handle credentials separately

Feluda stores supported secrets in the operating system's protected credential store.

Private values may include:

• passwords;
• API keys;
• access tokens;
• database credentials;
• protected headers; and
• other connection secrets.

Do not copy these into ordinary backup documents or unencrypted archives.

Do not export secrets into plain text

Never place raw credentials in:

• text files;
• spreadsheets;
• workflow prompts;
• Journal entries;
• screenshots;
• support notes;
• shared folders; or
• unencrypted backup archives.

Record how credentials should be recreated or restored through an approved secure process.

Record credential ownership

For each protected credential, record only:

• purpose;
• service;
• account owner;
• permission scope;
• expiry process;
• rotation owner; and
• approved recovery method.

Do not record the secret value.

Plan credential recovery

After device loss or migration, credentials may need to be:

• entered again;
• restored through the operating system;
• issued again;
• rotated;
• approved again; or
• replaced with a new account.

Include this process in the recovery plan.

Choose a backup location

A backup location may be:

• another internal drive;
• an external drive;
• an encrypted removable device;
• an approved network location;
• an organisational backup system; or
• an approved remote storage service.

Choose a location that matches the environment's privacy requirements.

Avoid storing backup beside the original

A backup on the same failing drive may be lost with the original data.

Keep at least one protected copy on a separate storage system.

For important environments, follow your organisation's backup policy.

Understand local and remote backup paths

A local backup remains on local or approved internal storage.

A remote backup sends data to another service.

Before using remote storage, review:

• provider;
• account;
• encryption;
• region;
• access control;
• retention;
• recovery process; and
• organisational approval.

A local workflow can still have a remote backup.

Encrypt sensitive backups

When a backup contains private or confidential data, use an approved encryption method.

Protect:

• backup files;
• external drives;
• network shares;
• archives;
• database exports; and
• recovery documentation.

Keep encryption keys separate from the protected backup.

Control backup access

Limit backup access to people who need it.

Review:

• user accounts;
• folder permissions;
• network permissions;
• removable-drive access;
• administrator access;
• recovery roles; and
• audit requirements.

A backup can expose the same information as the live environment.

Use clear backup names

Use names that identify:

• environment;
• date;
• content;
• version; and
• backup type.

For example:

feluda-local-mcp-atlas-2026-06-08-full

Or:

feluda-local-mcp-atlas-2026-06-08-workflows-only

Avoid names such as backup-final-new.

Use versioned backups

Keep more than one recovery point when the environment is important.

Versioned backups help when:

• corruption is discovered late;
• a workflow changed incorrectly;
• a server update caused hidden problems;
• a file was deleted before the latest backup; or
• the newest backup contains the same error as the live environment.

Define retention according to your needs and policy.

Decide what not to back up

Exclude content that is:

• temporary;
• easily recreated;
• unnecessary;
• unsafe to preserve;
• outside the approved retention period; or
• already protected elsewhere.

Review:

• caches;
• temporary model files;
• old test output;
• duplicate datasets;
• outdated installers;
• disposable logs; and
• unneeded sample records.

Smaller backups are easier to verify and restore.

Back up before major changes

Create or confirm a current backup before:

• updating Feluda;
• updating the model runner;
• changing the AI model;
• updating the MCP server;
• replacing an MCP server;
• changing source paths;
• changing database structure;
• changing permissions;
• migrating devices; or
• removing old workflows.

Record the backup date before proceeding.

Pause active writes during backup

Files or databases may change while the backup is being created.

Pause important write workflows when consistency matters.

Confirm that:

• no write tool is running;
• no scheduled write will begin;
• the database backup method supports active use;
• output files are complete; and
• temporary files are not mistaken for final output.

Resume only after the backup completes successfully.

Create a full backup

A full backup may include:

• Feluda user data;
• workflow records;
• Journal content;
• local source files;
• required output files;
• database exports;
• MCP server setup records;
• model and runner records;
• schedule records;
• permission records;
• recovery instructions; and
• selected model files when required.

Use this before major migration or recovery work.

Create smaller frequent backups

Between full backups, you may preserve frequently changing content such as:

• workflows;
• Journal entries;
• local databases;
• project files;
• reports; and
• configuration records.

Choose a frequency based on how much work you can afford to recreate.

Verify the backup completed

Confirm that:

• the backup exists;
• expected folders are present;
• expected files are present;
• archive creation completed;
• database export completed;
• file sizes are reasonable;
• encryption completed;
• no obvious error occurred; and
• the backup can be opened by an authorised person.

Do not trust only a success notification.

Review backup logs

When the backup system provides logs, review:

• start time;
• finish time;
• files copied;
• files skipped;
• errors;
• warnings;
• available storage; and
• verification state.

Investigate repeated skipped files.

Test restoration

A backup is not proven until a restore test succeeds.

Restore into:

• a separate test folder;
• a test database;
• a spare approved device;
• a temporary local environment; or
• another isolated location.

Do not overwrite the only working environment during the test.

Restore Feluda user data safely

Before restoring:

• close Feluda;
• record the current user-data state;
• create a backup of the current environment;
• confirm the correct operating-system user;
• confirm the target path; and
• confirm the backup version.

Follow the approved recovery process for your operating system.

Verify restored workflows

Open Feluda after restoration.

Confirm that:

• Studio workflows appear;
• workflow names are correct;
• blocks load;
• prompts remain present;
• model selections are understood;
• MCP tool references are visible;
• permissions are present;
• no-result paths remain connected; and
• error paths remain connected.

Do not run write workflows yet.

Reconnect local providers

Confirm that:

• the model runner is installed;
• the endpoint is correct;
• the service is running;
• the required model is installed;
• Fetch Models returns the model; and
• a simple Workbench prompt succeeds.

Provider settings may need to be recreated on a new device.

Reconnect MCP servers

Open MCP Servers.

Confirm:

• server name;
• endpoint;
• port;
• authentication process;
• expected tools;
• source paths;
• destination paths;
• warnings; and
• errors.

Re-enter protected credentials through the approved secure process.

Restore permission boundaries

Confirm that restored workflows still use the intended:

• read access;
• write access;
• URL rules;
• IP rules;
• path rules;
• port rules;
• account scope; and
• destination scope.

Do not restore broader permissions than the original environment required.

Restore source paths

A restored workflow may fail when files move to another location.

Confirm:

• drive;
• folder;
• filename;
• user home directory;
• mounted volume;
• operating-system path format; and
• file permissions.

Update paths only after confirming the intended source.

Restore local databases

Follow the database's approved restore process.

Confirm:

• database version;
• target database;
• backup date;
• account access;
• schema;
• record count;
• sample records;
• indexes; and
• read-only test result.

Test write operations separately.

Run a known-good read test

After restoration, use a stable sample.

For example:

Use only the enabled Local Documents Search tool.

Search for "local MCP backup test".

Return:
1. document title;
2. local source path;
3. returned summary;
4. last updated date; and
5. any warning.

Do not create or change anything.

Review Workbench Activity.

Review Workbench Activity after restoration

Confirm:

• the expected tool was called;
• the expected server provided it;
• the input was correct;
• the source was restored;
• the raw result was complete;
• warnings were understood;
• errors were absent or resolved; and
• the final answer matched the tool result.

Test RunFlows after restoration

Use a restored read-only workflow first.

Review:

• starting input;
• MCP tool call;
• raw output;
• intermediate output;
• workflow branch;
• final output;
• warnings; and
• errors.

Confirm that the saved workflow works outside Studio.

Test write actions separately

Do not resume regular write workflows immediately.

Use:

• a test record;
• a temporary file;
• a safe folder;
• a reversible action;
• explicit approval; and
• destination verification.

Confirm that restored paths and accounts point to the intended destination.

Restore schedules carefully

Do not resume every schedule automatically.

For each schedule, confirm:

• workflow;
• frequency;
• time;
• timezone;
• source;
• destination;
• model;
• MCP server;
• permissions;
• normal runtime; and
• reviewer.

Use a one-time schedule before restoring recurring execution.

Test a one-time schedule

Confirm that:

• Feluda is open;
• the computer is awake;
• the model runner is active;
• the MCP server is active;
• local sources are available;
• the flow completes;
• the destination is correct;
• no duplicate appears; and
• Schedule Manager records the run.

Resume recurring schedules gradually.

Test offline restoration

When offline use is required:

1. complete a successful connected restoration test;
2. disconnect from the internet;
3. keep local services active;
4. run the known-good Workbench test;
5. run the restored RunFlows test;
6. inspect the local destination; and
7. confirm no hidden remote dependency appears.

Compare with the original baseline

Compare:

• model;
• model version;
• MCP server;
• tool list;
• input;
• raw result;
• final answer;
• runtime;
• warnings;
• errors;
• source paths;
• destination paths; and
• schedule behaviour.

Document accepted differences.

Test recovery time

Record how long restoration takes.

Include time needed to:

• obtain the backup;
• restore Feluda data;
• install software;
• restore or download models;
• reconnect MCP servers;
• restore databases;
• restore credentials;
• test workflows; and
• resume schedules.

This helps set realistic recovery expectations.

Define recovery priorities

Not every item must be restored at once.

A practical order may be:

1. Feluda user data;
2. local model runner;
3. required AI model;
4. local MCP server;
5. critical source data;
6. critical read workflows;
7. required write workflows;
8. schedules;
9. non-critical history; and
10. optional models or tools.

Prioritise business-critical tasks.

Protect backup privacy

Review whether backups contain:

• personal information;
• confidential documents;
• local database records;
• Journal entries;
• internal URLs;
• file paths;
• workflow prompts;
• tool output; or
• logs.

Apply the same or stronger protection used for the live environment.

Review backup retention

Decide how long backups should be kept.

Consider:

• project length;
• organisational policy;
• legal requirements;
• privacy requirements;
• storage capacity;
• recovery needs; and
• whether old backups contain outdated sensitive data.

Remove backups securely when they are no longer needed.

Review access after staff changes

When responsibilities change:

• update the backup owner;
• remove unnecessary access;
• rotate protected credentials when appropriate;
• update recovery contacts;
• update documentation;
• confirm new ownership; and
• test recovery access.

Do not leave backups accessible to former owners.

Review after environment changes

Update the backup plan after:

• new workflows;
• new models;
• new MCP servers;
• server replacement;
• new source folders;
• new databases;
• new schedules;
• permission changes;
• device migration; or
• new backup storage.

The backup inventory should match the live environment.

Use a recurring backup routine

A practical routine is:

1. Review the environment inventory.
2. Confirm the backup destination.
3. Confirm available storage.
4. Pause important write workflows when needed.
5. Back up Feluda user data.
6. Back up local sources and required output.
7. Export local databases safely.
8. preserve MCP and model setup records.
9. protect the backup with approved encryption.
10. review backup logs.
11. confirm expected files exist.
12. test restoration in an isolated location.
13. run a known-good Workbench test.
14. test a restored RunFlows item.
15. verify a safe write action.
16. test one-time scheduled execution.
17. record the backup and restoration result.

Final backup checklist

Before relying on the backup, confirm that:

• Feluda user data is included;
• important workflows are included;
• Journal content is included when required;
• source files are included;
• required output is included;
• databases use a valid backup method;
• MCP configuration records are included;
• model and runner details are included;
• schedule records are included;
• permission records are included;
• raw credentials are not exposed;
• the backup is encrypted when needed;
• access is restricted;
• more than one recovery point exists when required;
• the backup is stored separately from the original;
• restoration has been tested; and
• the restored environment passed Workbench and RunFlows checks.

A backup is trustworthy only when it preserves the right information and has passed a real restoration test.