Operations

Everything you do after your secure environment is running. The Helm and kubectl commands below use <namespace>: your secure environment’s namespace. The one-line installer names it after your client and gives the Helm release the same name, so <namespace> is both. tracebloc cluster info shows it. For a manual Helm install, it’s the namespace and release name you chose.

Day-to-day management — inspecting the cluster, ingesting and removing data — is easiest with the tracebloc CLI. The Helm/kubectl commands here cover the lifecycle bits the CLI doesn’t (upgrade, stop/start, uninstall) and deeper debugging.

Which context kubectl and Helm use

Every kubectl and helm command on this page that reaches your secure environment names tracebloc’s context: kubectl --context k3s-tracebloc … and helm --kube-context k3s-tracebloc …. A command that names its context reaches your secure environment whatever else your kubeconfig points at. The installer adds that context to your kubeconfig, the first file KUBECONFIG names, else ~/.kube/config. It is k3s-tracebloc, or k3s-<name> if you installed with TRACEBLOC_CLUSTER_NAME: write that name in place of k3s-tracebloc below. On a machine an older installer set up on k3d, it is k3d-tracebloc (k3d-<name>). To list the contexts in your kubeconfig, run kubectl config get-contexts. On Linux, kubectl is k3s’s own, and with no KUBECONFIG set it reads k3s’s own file, which has no k3s-tracebloc. If your shell had no KUBECONFIG when you installed, the install summary printed an export KUBECONFIG=… line that names the merged file: run it, and add it to your profile to keep it. For a Helm install into a cluster of your own, name that cluster’s context in its place.

kubectl and Helm on Windows

On Windows, kubectl and helm are inside tracebloc’s WSL distro, not on Windows: the installer puts neither on Windows. Run a kubectl command from PowerShell with wsl -d tracebloc -- in front of it. In the distro, k3s’s own kubeconfig, /etc/rancher/k3s/k3s.yaml, holds only your secure environment’s cluster, and its context is named default, not k3s-tracebloc. For a command you run in the distro, write default where this page says k3s-tracebloc:

wsl -d tracebloc -- kubectl --context default get pods -n <namespace>

Helm in the distro needs k3s’s kubeconfig named:

wsl -d tracebloc -- env KUBECONFIG=/etc/rancher/k3s/k3s.yaml helm --kube-context default list -n <namespace>

For a command with a pipe, such as the Secret reads under Move to another machine, open the distro’s shell with wsl -d tracebloc, run export KUBECONFIG=/etc/rancher/k3s/k3s.yaml, then type the command as it is on this page, with default in place of k3s-tracebloc. The installer also adds its context, k3s-tracebloc, to your Windows kubeconfig (%USERPROFILE%\.kube\config) and makes it current, so a kubectl you installed on Windows yourself reaches your secure environment too: name it with --context k3s-tracebloc.

Which version am I on?

tracebloc cluster info        # "chart version" under Client install
helm --kube-context k3s-tracebloc list -n <namespace>      # or: CHART column shows client-<version>

The install summary also prints the version. For support, tracebloc doctor --diagnose writes a redacted support bundle, tracebloc-doctor-<timestamp>.txt, to the current directory; it includes the chart version.

Health & status

tracebloc client status    # online, offline or pending
tracebloc doctor           # connected and ready to train? says what to fix if not

For deeper debugging:

kubectl --context k3s-tracebloc get pods -n <namespace>        # all secure environment pods Running?
kubectl --context k3s-tracebloc get pods -n tracebloc-node-agents   # the resource-monitor DaemonSet

Then check My Secure Environment: your secure environment should read Active now under its name.

Environment status

The Environment status tiles on My Secure Environment show what your secure environment reports. It sends a reading every minute. When several machines run it, each tile shows the busiest one.

Tile	What it measures
CPU	How busy the CPU of the machine is, from its latest reading. On Linux, the whole machine. On Windows, the VM WSL runs tracebloc’s distro in, not Windows itself: other apps on Windows don’t show here. On a Mac, the Linux VM tracebloc runs in, not the whole Mac: a training on the Mac’s GPU runs outside that VM, so its CPU use does not show here.
GPU	How busy the GPU is (not its memory), from the latest reading. On Linux and Windows, it is the NVIDIA GPU as its driver reports it, so other programs that use the GPU count too, on Windows the screen and the browser included. On a Mac, it is the whole Apple GPU, other apps such as the screen and the browser included, and it is the peak since the previous reading (the Mac samples it every 5 seconds). So it can read busy with no experiment running. Ready means the GPU can train and sent no reading yet; Not used gives the reason trainings run on the CPU instead.
Memory	How much of the machine’s memory is used. On Linux, the whole machine’s. On Windows, the memory of WSL’s VM, as for CPU: half of the machine’s by default (see Windows prerequisites). On a Mac, the Linux VM’s memory, as for CPU.
Storage	How much of the storage your secure environment can grow into is used. It is measured on a Mac; on Windows, where the used space is tracebloc’s WSL disk, and the room is that disk’s free space, or the free space of the Windows drive it sits on when that is less and your secure environment can see the drive; and on Linux when your datasets are on a local disk of their own (`TRACEBLOC_HOST_DATASET_DIR`, see Installer options). On a Linux install that keeps its datasets on the machine’s main disk (the default), with datasets on a network share, or when the disk can’t be read, your secure environment sends no storage reading: the tile reads No reading yet and Not measured on this machine.
Runs	The trainings and inferences running on your secure environment right now.

The line under CPU, GPU and Memory covers the last 3 days. Each point is the peak of its period, not the average, so a short burst shows as a spike. Runs counts an experiment only while its training is running on your secure environment. One that is queued, waiting for a free GPU, or between cycles is not counted, so the tile can read None running while the Training tab lists the experiment as training. On an older release, a training on a Mac’s GPU is not counted either: upgrade to count it. A tile reads No reading when your secure environment is offline or sent nothing for 10 minutes.

Logs

kubectl --context k3s-tracebloc logs -n <namespace> -l app=manager --tail=200 -f

Stop & start (local machine)

Free up your machine without losing anything — data persists between stops. On Linux, native k3s runs as the k3s system service:

sudo /usr/local/bin/k3s-killall.sh   # frees CPU/RAM; stopping the service alone leaves the pods running
sudo systemctl start k3s             # resume where you left off

On a Mac, k3s runs in a VM in Apple’s container runtime (see Mac prerequisites). The login item io.tracebloc.node checks every minute and starts the node again, so unload it first. Then stop the node and the container system with the runtime they run on:

launchctl bootout gui/$(id -u)/io.tracebloc.node   # the login item, or it starts the node again within a minute
ROOT="$(launchctl print gui/$(id -u)/com.apple.container.apiserver | awk -F' => ' '$1 ~ /CONTAINER_INSTALL_ROOT$/ {print $2; exit}')"
"$ROOT/bin/container" stop k3s-tracebloc           # the node's VM: frees its memory and CPUs
"$ROOT/bin/container" system stop                  # Apple's container system

If launchctl print finds no com.apple.container.apiserver, the container system and the node are already stopped. The node is named after kubectl’s context, k3s-tracebloc, or k3s-<name> if you installed with TRACEBLOC_CLUSTER_NAME. To start again, load the login item. It starts the container system, then the node:

launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/io.tracebloc.node.plist
tracebloc client status --wait                     # until your secure environment is back Online

The stop lasts until you log in again: the login item loads at every login and brings the node back. On a machine an older installer set up on k3d, k3d cluster stop tracebloc and k3d cluster start tracebloc stop and start it (with your TRACEBLOC_CLUSTER_NAME in place of tracebloc, if you set one). Moving such a machine to k3s is a reinstall: see Linux prerequisites and Mac prerequisites.

Upgrade

The auto-upgrade CronJob keeps your secure environment current by default: every hour it checks for a new release and upgrades the services. To update the CLI now:

tracebloc upgrade

It re-runs the official installer (signature-verified) and brings the CLI to the latest release. On Linux and on a Mac it runs the full install, which also brings the services up to date. On Windows it prints the command to run in a new PowerShell window. Safe to re-run. On a machine an older installer set up on k3d, it does not update the secure environment: the installer stops and changes nothing. Moving that machine to k3s is a reinstall: delete its secure environment with tracebloc delete, then run the installer again (see Linux prerequisites and Mac prerequisites). To upgrade the services right away, use Helm:

Upgrade with Helm (advanced)

helm repo update
helm --kube-context k3s-tracebloc upgrade <namespace> tracebloc/client -n <namespace> --reset-then-reuse-values

--reset-then-reuse-values preserves the values the installer applied. It needs Helm 3.14 or later (Helm 4 works; the installer installs Helm 4). Append --version <x.y.z> to pin a specific release.

Roll back

helm --kube-context k3s-tracebloc history <namespace> -n <namespace>      # find the revision to return to
helm --kube-context k3s-tracebloc rollback <namespace> <revision> -n <namespace>

Move to another machine

Your secure environment’s identity is its Client ID, not the machine. To relocate, reuse the old host’s credentials:

On the old host, read the Client ID and its password from the secure environment’s Secret:

kubectl --context k3s-tracebloc get secret <namespace>-secrets -n <namespace> -o jsonpath='{.data.TRACEBLOC_CLIENT_ID}' | base64 -d; echo
kubectl --context k3s-tracebloc get secret <namespace>-secrets -n <namespace> -o jsonpath='{.data.TRACEBLOC_CLIENT_PASSWORD}' | base64 -d; echo

On the new host, pass them to the installer. Without them, the installer signs you in through the browser and creates a new secure environment instead:
curl -fsSL https://tracebloc.io/i.sh | TRACEBLOC_CLIENT_ID=<client-id> TRACEBLOC_CLIENT_PASSWORD=<password> bash
Re-ingest your datasets on the new host. Ingested data doesn’t move with the credentials, and copying ~/.tracebloc across doesn’t carry it over.
Once the new host shows Online, remove tracebloc from the old one with the steps under Delete it by hand. Don’t revoke it afterwards: the new host uses the same credential.

Don’t run tracebloc delete on the old host. It revokes the machine credential first, and that is now the credential the new host uses, so the new host goes offline too.

Uninstall

To remove tracebloc from this machine, run:

tracebloc delete

It shows what it will remove and keep, then asks you to type the name of your secure environment to confirm. --yes skips the confirmation (for automation). With a secure environment linked to this machine, it needs you signed in, since its first step revokes the machine credential on tracebloc. On a machine with no secure environment linked, see With no secure environment linked.

Removed from this machine: the machine credential is revoked, the Helm release is uninstalled, the local cluster is deleted, the tracebloc container images are reclaimed, ~/.tracebloc is cleared, and the tracebloc CLI removes itself.
Kept on tracebloc: your use cases, the catalog entries of your datasets, and the models trained here.
Left in place: NVIDIA drivers. On a machine an older installer set up on k3d, also Docker, kubectl, k3d and helm. Remove them yourself if nothing else uses them.
On Windows: the logon task tracebloc-keepalive is removed, then tracebloc’s WSL distro with everything inside it and its folder, %LOCALAPPDATA%\tracebloc\wsl. The CLI, and the entry its installer added to your Path, go once the command exits.
On Linux: k3s itself is removed too, through k3s’s own uninstall, so tracebloc delete asks for administrator rights once and lists every command it runs as root before it runs any. A k3s that an administrator prepared for you stays; removing it takes that administrator. --keep-data copies your volumes to ~/.tracebloc/kept-data/<time>/ first.

This can’t be undone. Datasets stored on this machine are erased. tracebloc delete --keep-data keeps ~/.tracebloc (local config and any datasets stored there on the host), but datasets kept inside the cluster go with it. On Linux, --keep-data copies them out first (see above). On a Mac set up with version 1.12 or later, the datasets, logs and resume points training uses are in ~/.tracebloc/job-data, and --keep-data keeps that folder. A Mac set up before version 1.12 has no such folder: its datasets are in the node’s volume, which goes with the node, so --keep-data keeps none of them. The delete preview lists what it keeps.

tracebloc delete refuses while a training runs or waits to run on your secure environment, and names each experiment it belongs to (use case, start time and cycle). Wait for them to finish, or pass --force to stop them. An experiment can stay listed as running after its training on this machine has ended, for example when the training ran out of memory. Such an experiment doesn’t block tracebloc delete: it warns, names the experiment, says nothing is training there, and goes on to the confirmation. Deleting stops nothing for such an experiment. It stays listed on tracebloc until its owner stops it. When neither your secure environment’s report nor the machine it runs on says what is training (for example, it is offline and unreachable), tracebloc delete refuses while tracebloc lists any experiment as running. It targets your secure environment as recorded at install time, not kubectl’s current context, and it refuses if what it reaches is not your secure environment. Pass --context only if the install record is missing.

After tracebloc delete, check kubectl config current-context before you run another kubectl or helm command: when the deleted cluster’s context was the current one, kubectl has no current context. On a machine an older installer set up on k3d, k3d cluster delete removes the cluster’s context and may make another cluster in your kubeconfig current, such as a remote or production cluster. Switch with kubectl config use-context <context>, or clear it with kubectl config unset current-context.

Manual removal (advanced)

helm --kube-context k3s-tracebloc uninstall <namespace> -n <namespace> removes only the release (on a machine an older installer set up on k3d, k3d cluster delete tracebloc removes the cluster; check kubectl config current-context afterwards, as the warning above says). The machine credential stays live, so your secure environment stays registered on your dashboard, and the tracebloc CLI and ~/.tracebloc stay on disk. Prefer tracebloc delete.After a helm uninstall, PVCs are annotated helm.sh/resource-policy: keep, so your data survives. To remove it too: kubectl --context k3s-tracebloc delete pvc --all -n <namespace>.

With no secure environment linked

Signing out clears this machine’s link to its secure environment along with your sign-in, and a machine where you never created a secure environment has no link. tracebloc delete then reads the install record, needs no sign-in and asks tracebloc nothing:

The install record lists a secure environment: it still runs here, so tracebloc delete refuses and removes nothing. Only a delete with the link can check for running trainings and revoke the machine credential. Signed out, it names the way forward: tracebloc login, then tracebloc client create to relink it (it adopts the secure environment already here), then tracebloc delete again. Signed in, it stops with no active secure environment on this machine and names the same relink.
No secure environment here: it removes what is left on this machine: ~/.tracebloc (kept with --keep-data), the tracebloc CLI and the entry its installer added to your PATH, on a Mac the login item older installers added (io.tracebloc.runtime), and on Windows %LOCALAPPDATA%\tracebloc. It revokes nothing. To confirm, type tracebloc, since there is no secure environment name; --yes and --confirm-name tracebloc work as usual. Signed out, it ends with a reminder: if a secure environment of yours ran here, revoke it from the dashboard, or with tracebloc client remove as under Delete it by hand.
No install record, but tracebloc still runs here: on Windows, tracebloc’s WSL distro or its tracebloc-keepalive logon task is still there; on Linux, k3s is. tracebloc delete refuses and removes nothing, since it removes them only as a record lists them. Run the installer again (on Linux, tracebloc upgrade), which writes the record, then tracebloc delete again, or delete it by hand.

Delete it by hand

When tracebloc delete refuses and you can’t take the way forward it names, for example because the install record is gone or the machine can’t be relinked, these commands remove what the one-line installer put on this machine. They also finish what a tracebloc delete with no secure environment linked leaves: the k3s-tracebloc entries in your kubeconfig, and on a Mac any node VM, login items and ~/Library/Application Support/tracebloc still there. They erase your secure environment’s datasets, as tracebloc delete does. The install record, ~/.tracebloc/install-record.json (%USERPROFILE%\.tracebloc\install-record.json on Windows), lists everything the installer made here: read it first, and skip a line whose item it doesn’t list. The names below are the defaults: with TRACEBLOC_CLUSTER_NAME set, the context is k3s-<name>, and with TRACEBLOC_INSTALL_PREFIX set, the CLI is in that folder.

Windows (PowerShell)
macOS
Linux

Run these in a normal PowerShell window, as the user who installed tracebloc. None of them needs administrator rights.

schtasks /Delete /TN tracebloc-keepalive /F                          # the logon task first, or it starts the distro again
wsl --unregister tracebloc                                           # the distro, with your secure environment and its datasets
Remove-Item -Recurse -Force "$env:LOCALAPPDATA\tracebloc"            # the distro's folder
Remove-Item -Recurse -Force "$env:LOCALAPPDATA\Programs\tracebloc"   # the tracebloc CLI
Remove-Item -Recurse -Force "$env:USERPROFILE\.tracebloc"            # your sign-in, settings and the install record
[Environment]::SetEnvironmentVariable('Path', (([Environment]::GetEnvironmentVariable('Path', 'User') -split ';' | Where-Object { $_ -and $_ -ne "$env:LOCALAPPDATA\Programs\tracebloc" }) -join ';'), 'User')   # the CLI's entry in your Path

The k3s-tracebloc context, cluster and user stay in your Windows kubeconfig, %USERPROFILE%\.kube\config. Remove them with a kubectl you installed yourself (kubectl config delete-context k3s-tracebloc, then delete-cluster and delete-user with the same name), or leave them. On a machine an older installer set up, C:\Program Files\tracebloc\bin may also be on the system Path; removing it takes an administrator.

kubectl config delete-context k3s-tracebloc; kubectl config delete-cluster k3s-tracebloc; kubectl config delete-user k3s-tracebloc
[ "$(kubectl config current-context 2>/dev/null)" = k3s-tracebloc ] && kubectl config unset current-context   # no current context left naming it
launchctl bootout gui/$(id -u)/io.tracebloc.node     # the login items first, or they start the node again
launchctl bootout gui/$(id -u)/io.tracebloc.runner
rm -f ~/Library/LaunchAgents/io.tracebloc.node.plist ~/Library/LaunchAgents/io.tracebloc.runner.plist
C="$(ls -d "$HOME/Library/Application Support/tracebloc/container/"[0-9]*/bin/container | tail -1)"   # tracebloc's copy of Apple's container tool
"$C" delete --force k3s-tracebloc      # the node's VM
"$C" volume delete k3s-tracebloc       # its volume, with your secure environment's data
"$C" system stop
rm -rf "$HOME/Library/Application Support/tracebloc"   # Apple's container runtime and the runner's engine bundles
rm -rf ~/.tracebloc                    # your sign-in, settings, the install record, and the job-data folder where there is one
for B in ~/.local/bin ~/bin /usr/local/bin; do [ -f "$B/tracebloc" ] || continue; [ "$(readlink "$B/tb")" = "$B/tracebloc" ] && rm -f "$B/tb"; rm -f "$B/tracebloc"; done   # the CLI, and its tb alias where that is tracebloc's

K=~/.kube/config                                     # the kubeconfig the installer merged k3s-tracebloc into
kubectl --kubeconfig "$K" config delete-context k3s-tracebloc; kubectl --kubeconfig "$K" config delete-cluster k3s-tracebloc; kubectl --kubeconfig "$K" config delete-user k3s-tracebloc   # first: k3s's uninstall takes kubectl with it
[ "$(kubectl --kubeconfig "$K" config current-context 2>/dev/null)" = k3s-tracebloc ] && kubectl --kubeconfig "$K" config unset current-context   # no current context left naming it
sudo /usr/local/bin/k3s-uninstall.sh                 # k3s, its cluster and every volume in it, with your secure environment's data
sudo rm -f /etc/rancher/node/password; sudo rmdir /etc/rancher/node /etc/rancher /var/lib/rancher 2>/dev/null   # the node password k3s's uninstall leaves, then the folders, only if empty
[ -e /etc/apparmor.d/runc ] && { sudo rm -f /etc/tracebloc/apparmor-k3s-runc; sudo env LC_ALL=C apparmor_parser -r /etc/apparmor.d/runc; }   # AppArmor, only where the install record lists apparmor-runc: Ubuntu's own runc profile back in place of ours
[ -e /etc/apparmor.d/runc ] || { sudo env LC_ALL=C apparmor_parser -R /etc/tracebloc/apparmor-k3s-runc; sudo rm -f /etc/tracebloc/apparmor-k3s-runc; }   # with no Ubuntu runc profile, ours out of the kernel, then its file
sudo rm -f /etc/systemd/system/k3s.service.d/tracebloc-apparmor-runc.conf /etc/apt/apt.conf.d/99tracebloc-apparmor-runc   # the drop-in and apt's hook that put our profile back
sudo systemctl disable --now tracebloc-firewall.service
sudo nft delete table inet tracebloc                 # the host firewall rule that kept the k3s API off the network
sudo rm -f /etc/systemd/system/tracebloc-firewall.service; sudo systemctl daemon-reload
sudo rm -rf /etc/tracebloc "/var/lib/tracebloc/$USER"   # the firewall rules file and the install record's root copy
rm -rf ~/.tracebloc                                  # your sign-in, settings and the install record
sudo rm -f /usr/local/bin/helm                       # Helm, only where the install record lists it
for B in ~/.local/bin ~/bin /usr/local/bin; do [ -f "$B/tracebloc" ] || continue; [ "$(readlink "$B/tb")" = "$B/tracebloc" ] && sudo rm -f "$B/tb"; sudo rm -f "$B/tracebloc"; done   # the CLI, and its tb alias where that is tracebloc's
grep -n -A1 '^# Added by the tracebloc CLI installer' ~/.bashrc   # the CLI's PATH entry: this line and the export PATH line under it

The CLI’s installer puts the CLI in ~/.local/bin (or ~/bin, when that is already on your PATH) and adds that folder to your PATH in ~/.bashrc (~/.zshrc for zsh, ~/.profile for other shells), as two lines: # Added by the tracebloc CLI installer (prefix: <folder>), then export PATH="<folder>:$PATH". The grep above shows them. If nothing else you use is in that folder (ls -A on it lists nothing), remove both lines in an editor, or with sed -i.bak '/^# Added by the tracebloc CLI installer/{N;d;}' ~/.bashrc, which keeps a copy in ~/.bashrc.bak; check first that the grep showed only those lines. Otherwise keep them: other tools there need that folder on your PATH, which is why tracebloc delete keeps them too.Installed with KUBECONFIG set, the installer merged into the first file it named, and the install record’s kube-context entry gives that path: set K to it. Helm goes in only when there was none on the machine, so leave /usr/local/bin/helm where the record doesn’t list it. On a machine an administrator prepared for you, Helm is in ~/.local/bin/helm instead (no sudo), and the installer may have added ~/.local/bin to your PATH under a line that starts # Added by tracebloc installer and ends user-local tools; the same rule applies to it.The AppArmor profile for k3s. On a machine with AppArmor enabled and kernel.apparmor_restrict_unprivileged_unconfined set to 1 (Ubuntu 25.10 and 26.04 set it by default), the installer writes three files, because without them that kernel gives every k3s container a second AppArmor profile that stops it from signalling itself, and MySQL’s first start never ends:

/etc/tracebloc/apparmor-k3s-runc: an AppArmor profile named runc, Ubuntu’s own runc profile extended to the runc k3s ships, put in the kernel before k3s starts. The install record lists it as apparmor-runc.
/etc/systemd/system/k3s.service.d/tracebloc-apparmor-runc.conf: a systemd drop-in that puts the profile back in the kernel before every k3s start.
/etc/apt/apt.conf.d/99tracebloc-apparmor-runc, on a machine with apt: a hook that puts the profile back in the kernel after every package update, since an apparmor update puts Ubuntu’s own runc profile back.

On any other machine it writes none of them, and the record lists no apparmor-runc: skip the three AppArmor lines. Where it does, tracebloc delete removes all three files and runs the same commands as those lines. With /etc/apparmor.d/runc there, it removes the profile file and puts Ubuntu’s runc profile back with apparmor_parser -r; without it, it takes the profile out of the kernel with apparmor_parser -R first, then removes the file. The systemctl daemon-reload further down makes systemd forget the drop-in. An older tracebloc delete removes only the profile file. The drop-in and the hook it leaves do nothing once k3s and that file are gone, and the third AppArmor line removes them; the profile itself stays in the kernel until the next reboot, or until the first AppArmor line puts Ubuntu’s back.Where the install record names the firewall rule iptables:TRACEBLOC-API instead of nft:inet tracebloc, remove it with sudo iptables -D INPUT -j TRACEBLOC-API, sudo iptables -F TRACEBLOC-API and sudo iptables -X TRACEBLOC-API, then the same three with ip6tables. A k3s an administrator prepared for you stays: skip k3s-uninstall.sh and leave it to that administrator. With TRACEBLOC_STORAGE_MODE=hostpath, your data is in the data directory (TRACEBLOC_HOST_DATA_DIR, ~/.tracebloc by default); some of it is root’s, so remove that folder with sudo.

Deleting by hand doesn’t revoke the machine credential: your secure environment stays on tracebloc and reads Offline. Your use cases, the catalog entries of your datasets and the models trained here are kept, as with tracebloc delete. To revoke it as well, sign in on any machine with the CLI: tracebloc client list shows your secure environment’s id, and tracebloc client remove <id> revokes it and keeps its history. If it refuses because it can’t confirm that secure environment isn’t on the machine you run it from, and its machine is gone, pass --force. Skip this if you moved it to another machine: the new host uses the same credential.

Back up

Your data lives in the secure environment’s PVCs: the dataset PVC and the MySQL PVC, which holds the ingested tables (kubectl --context k3s-tracebloc get pvc -n <namespace> lists them). Back up those volumes on your normal schedule — tracebloc keeps nothing of yours off your infrastructure. On a default Linux install, those volumes sit in k3s’s storage directory, not in ~/.tracebloc (see Linux prerequisites). On a Mac set up with version 1.12 or later, the datasets, logs and resume points training uses are in ~/.tracebloc/job-data, and the rest sits in the node’s volume. On a Mac set up before version 1.12, all of it sits in the node’s volume (see Mac prerequisites). To back them up as a host directory, install with TRACEBLOC_STORAGE_MODE=hostpath: your data then lives under ~/.tracebloc (or TRACEBLOC_HOST_DATA_DIR).

Delete a dataset

tracebloc data delete <name> removes a dataset’s table and files from your secure environment (see List and delete datasets). Right after the delete, your secure environment reports its datasets to tracebloc, and My Data shows the dataset as Deleted within a few minutes. If the CLI says tracebloc wasn’t told yet, nothing needs doing: the next scheduled report, about hourly while your secure environment runs, marks it Deleted. The dataset’s record on tracebloc is kept, never removed.

Overview

Create a Use Case

Join a Use Case

Environment Setup

Tools & Help

Releases

Which context kubectl and Helm use

kubectl and Helm on Windows

Which version am I on?

Health & status

Environment status

Logs

Stop & start (local machine)

Upgrade

Roll back

Move to another machine

Uninstall

With no secure environment linked

Delete it by hand

Back up

Delete a dataset