How to run it

Getting started

The path from nothing to a restore you have watched work. About half an hour for the first machine, about five minutes for each one after that. Do not skip the last step: a backup you have never restored from is a guess.

1. Sign in to the console

   Go to console.satkosh.com and sign in with your email and password, or use Sign in with Microsoft if your organisation has connected Microsoft 365. Set up multi-factor authentication when you are prompted. Enrolment checks your authenticator app before it switches MFA on, so a half-finished setup cannot lock you out of your own console. Keep the single-use recovery codes somewhere that is not the machine you are about to protect.

2. Choose the client the machine belongs to

   Every device, policy, job and report belongs to exactly one client. If you run backups for several businesses, create that client first. If you are protecting your own company, there is one client and it is already waiting for you.

3. Add a storage target

   A target is where backups land, plus the credentials to reach it. Add one before you enrol machines, because a policy has to point somewhere. There are three kinds and the section below covers how to choose between them.

4. Enrol the first machine

   Generate an enrolment token in the console, run the installer on the machine, and give it the token. The machine registers itself, attaches to the right client and starts reporting. There is no backup server to buy or rack first. Budget about five minutes.

5. Build a policy

   Pick the folders and drives that matter, how often to back them up, how long to keep each copy, and which target it goes to. Set a retention lock here if you want copies nothing can delete. Apply it to this machine, or to every machine belonging to this client.

6. Run it once by hand

   Use 'Back up now' rather than waiting for the schedule. A manual run takes exactly the same path as a scheduled one, so a manual run that works proves the scheduled one will. Watch it appear in the job list and finish.

7. Restore something, before you need to

   Take the snapshot you just made, restore a single file to an alternate location, and open it. This is the only step that proves the whole chain end to end. Every step before it proves only that data left the machine.

How the pieces fit

Two things do the work: an agent on each machine, and a console you sign into. They travel deliberately different routes, and that split explains most of the rest of this page.

• The agent reads the files you told it to protect, encrypts them on the machine, and sends them straight to your storage over your own connection
• The console decides what runs and when, and records what happened. That is all it ever sees
• Your backup data never passes through a Serverstock server. Whether it comes to rest on our equipment depends on which storage you chose
• We hold your storage credentials encrypted, which is what lets backups run unattended and lets us help you recover
• Choose zero-knowledge instead and we hold nothing we can read, at the cost that a lost password means nobody can recover that data, including us
• Each machine holds its own credential rather than a shared one

Client

The business a machine belongs to. This is the hard boundary in the product: devices, policies, jobs and reports never cross it, and one client can never see another's.

Device

One protected machine, physical or virtual.

Target

Where backups land, plus the encrypted credentials needed to reach it.

Policy

The whole definition of a backup: what to protect, how often, how long to keep it, and where it goes.

Job

One run of a policy against one device. It succeeds, it fails, or it is recorded as missed.

Snapshot

What a successful job leaves behind, and what you browse and restore from.

Retention

How long copies are kept, on a ladder that holds hourly, daily, weekly, monthly and annual copies at the same time.

Installing the agent

The agent is the only thing that goes on your machines. There is no on-premise backup server to stand up first, and nothing separate to install or keep patched alongside it.

1. Generate an enrolment token in the console, against the client the machine belongs to.

2. Run the installer on the machine. On Windows that is a signed installer, or a silent install you can push across a fleet through your RMM. On Linux the same agent installs as a background service.

3. Give it the token. The agent registers, attaches to the right client, and starts reporting.

4. Check the machine appears in the console. From this point it is managed from the console, not from the machine.

• Enrolment tokens belong to one client and expire, so they cannot be reused indefinitely
• Once enrolled, the machine holds its own credential and the enrolment token is discarded
• Enrolling a device is rate limited, so a stolen token cannot be paired with unlimited attempts
• On laptops and desktops a small icon in the corner of the screen tells the person using it that they are protected, without anyone having to sign in and check

Storage targets

A target is where backups land, plus the credentials to reach it. Machines sharing a target also share deduplication, so protecting fifty similar workstations costs far less storage than fifty separate copies. Credentials are held encrypted and unlocked only to run a job you scheduled or a restore you asked for.

• Storage bought from us, kept in India, is on the roadmap and is not available yet. When it ships you will be able to buy it per GB on what you hold once compressed, and move it to a bucket of your own without paying us to hand it back. Today, bring your own storage
• Your own cloud storage. Amazon S3, or any S3-compatible provider through a custom endpoint. Your account, your access rules, your bill from them. We hold nothing except the key needed to write to it, and that is encrypted
• A local drive. Genuinely useful as a fast local copy you can restore from in minutes. We would not recommend it as your only copy, because a drive in the same room as the servers it protects shares their fire, their flood and their burglary
• Retention locking works on Satkosh storage and on your own cloud storage. A local drive cannot enforce it
• Expired snapshots release their space automatically, so storage does not grow quietly forever while the console shows a tidy list
• Encryption passwords can be managed by us, or held only by you in zero-knowledge mode

Policies and scheduling

A policy is the whole definition of a backup. Build it once, then apply it to one machine or to every machine belonging to a client.

1. Choose what to protect: the folders and drives that matter on that machine.

2. Choose how often. Schedules run from hourly to monthly.

3. Choose how long to keep it. Hourly, daily, weekly, monthly and annual copies sit on one retention setting, so you can answer both 'restore yesterday' and 'show me last March' without paying to keep everything forever.

4. Choose where it goes, from the targets you have already added.

5. Apply it to this machine, or to every machine belonging to this client.

• After the first backup a nightly run moves only what changed, so backup windows stay short and less of your line is taken up during the working day
• 'Back up now' takes exactly the same path as a scheduled run, so testing it actually proves something
• Files that are open or in use are captured properly rather than skipped, so a busy server does not leave holes in its own backup
• A scheduled slot that can never now be covered is recorded as missed rather than quietly vanishing

Locking backups against deletion

Set a retention period on a policy and, inside that period, the copies it makes cannot be changed or deleted. Not by the agent's own credentials, not by a compromised console account, not by someone holding your stolen password, and not by us. That last part is what makes this a control rather than a promise: it does not rest on our staff behaving well, or on our access rules being configured correctly.

• Choose the period when you build the policy. Inside it, a copy cannot be deleted or overwritten by anyone
• A write lands as a new copy rather than replacing the one before it, so an overwrite cannot quietly erase history
• Available on Satkosh storage and on your own cloud storage
• A locked copy keeps using storage until its period expires, and cannot be deleted early to bring a bill down. That is the whole point of it, so set the period deliberately rather than generously
• This is recovery you cannot destroy, not endpoint protection. Satkosh does not scan for or block ransomware on your machines, and we will not pretend otherwise

Restoring

Pick a snapshot, pick what to recover, pick where it goes. Restores are unlimited and are never charged for.

1. Open the device and browse its snapshots by date.

2. Pick what to recover, down to a single file or folder.

3. Choose where it goes: back in place, or to an alternate location so nothing around it is disturbed.

4. Run it, and check the result rather than assuming it.

• The everyday case: someone deleted or changed the wrong thing. Pick yesterday, or last March, and put it back
• The hardware case: a machine is gone and a replacement needs its data. The backup belongs to the work, not to the hardware that happened to be running it, so losing the hardware does not lose the work
• The disaster case: the machine is destroyed, stolen, or will not switch on. You can browse and restore its snapshots without that machine being reachable, or in one piece. This is the case Satkosh is built around
• Recovering onto a different machine asks you to sign in again, raises a high-priority alert, emails the people you nominated, and is written to the audit trail. Moving data between machines is also something an attacker would like to do, so it is guarded rather than convenient

Monitoring and alerts

The console shows you current state. Alerting is what reaches you when that state changes, so nobody has to remember to log in and look. Failing quietly is the worst thing a backup product can do, and most of the design here goes into preventing it.

• A failed backup raises an alert and emails the people nominated for that client
• A machine that stops checking in is reported as unprotected, not merely offline
• A scheduled slot that can never now be covered is recorded as missed, so a week of downtime reads as a week of gaps rather than an unbroken row of green ticks
• Alerts are raised by severity, so a failed run and a machine that has gone quiet do not arrive looking identical
• Protection history exports per client and per day, in a form you can hand to an auditor

Sign-in, access and the audit trail

Who can get into the console, and what gets written down when they do.

• Multi-factor authentication with an authenticator app, plus single-use recovery codes. Enrolment verifies before it is switched on, so a half-finished setup can never lock you out
• Sign in with Microsoft 365 is available. If your tenant admin has connected your organisation's Microsoft 365 account, users can sign in with their existing Microsoft identity instead of a separate password. See the section below for setup steps
• Changing a password signs that account out everywhere it was already signed in, so a departing employee or a stolen login does not keep working because a browser tab stayed open
• Signing in and enrolling a device are both rate limited, so a stolen password cannot be paired with unlimited guesses at the second factor
• Logins, restores, policy and credential changes and user administration are all recorded with who did it and where from
• The audit trail survives deletion of the client it belongs to

Microsoft 365 single sign-on

If your organisation uses Microsoft 365, your team can sign in to the Satkosh console with their existing Microsoft account instead of managing a separate password. A tenant administrator connects the account once, and after that any user created in the console can use the Sign in with Microsoft button on the login page.

1. A tenant administrator signs in to the Satkosh console and navigates to the organisation settings.

2. The administrator connects the organisation's Microsoft 365 account. This is a one-time setup that authorises Satkosh to accept sign-ins from your Microsoft 365 directory.

3. The administrator creates users in the Satkosh console. Each user is mapped to their Microsoft 365 identity.

4. Once created, users go to console.satkosh.com and click Sign in with Microsoft. They authenticate with their existing Microsoft 365 credentials and land in the console without a separate password.

• Only a tenant administrator can connect the Microsoft 365 account. This is deliberate: linking an identity provider is a security decision, not a convenience one
• Users must be created in the Satkosh console first. A Microsoft 365 account alone does not grant console access until an administrator has explicitly added that user
• Removing a user from your Microsoft 365 directory, or disabling their account, immediately prevents them from signing in to the Satkosh console
• Microsoft 365 SSO works alongside multi-factor authentication. If your Microsoft 365 tenant enforces MFA, that carries through to the Satkosh sign-in
• Email-and-password sign-in continues to work for accounts that are not connected to Microsoft 365, so mixed environments are supported
• Google Workspace SSO is on the roadmap for organisations that do not use Microsoft

Updating agents

You decide when agents update, from the console. Nothing is pushed to your machines behind your back.

• Updates are started by you, per machine or in bulk
• Each update is cryptographically signed, and an agent verifies that signature before it installs anything
• An update whose signature does not verify does not install, and there is no override
• The console shows which agents are behind the current release

Not built yet

Published deliberately. If you can see what is missing, you can trust what is here. None of the following is available today, so do not plan around it.