Help › Settings and Log

Settings and Log — Making the Program Yours

The Settings window holds two kinds of setting side by side: those that are yours alone (theme, window layout, shortcuts) and those that affect company operation (HNR preferences, users, connections, company details and print forms). Experiment freely with the first group; in the second, change only what your job requires. The four administrator-only sections are marked clearly below. The Log window answers "what just happened".

0. Opening path and actual section map

Opening path: bottom Dock › Settings. A regular user sees Appearance, Windows, Account, HNR Preferences, Connections, Shortcuts and System. An administrator also sees Users, Status, Active Users and Print Forms. On mobile, the desktop-specific Windows and Shortcuts sections are hidden. Not seeing an administrator section is a permission result, not a fault.

Collapsible sections: All main headings and inner settings groups start closed. Click a heading, or reach it with Tab and press Enter or Space. Several main sections can stay open together. Closing and reopening a section preserves its unsaved draft; it does not save it. Closing the entire Settings window and reopening it starts with all headings closed again. HNR Preferences › Company Details › Production Preferences is visible only to system administrators; other users see neither the company settings heading nor a read-only summary.

1. Appearance and Windows

This is purely a matter of taste; no choice here affects your data. The three that matter most:

2. Account — where your password lives

This is where you change your password. Three rules:

• Share your password with nobody — not even the administrator if asked; an administrator has no need of your password.
• Sign out when you leave a shared computer; otherwise whatever is done there is recorded under your name.
• If you forget your password the administrator issues a new one; they cannot read the old one — and that is correct design.

3. Shortcuts

Keyboard shortcuts are listed and can be changed. For a beginner only a few are worth learning:

4. HNR preferences

These are not about looks but about working habits: which warehouse comes as the default, how lists open, and so on. Over time, whatever you find yourself changing every single time, set it here once.

5. The administrator's sections

The sections below appear only to a user with the system administrator right. If you do not see them, nothing is broken — you simply lack the permission. Hiding the section is only cosmetic; the real gate is on the server: an unauthorised request is refused there too.

6. Log — "what just happened?"

The Log window is the operation journal the program keeps about itself. You look here when an operation did not go as expected or you saw an error message. It is not an accounting record — it is a technical one.

7. Frequently asked

I changed a setting — did it change for my colleague too?

Appearance, windows, shortcuts and HNR preferences are yours alone: nobody is affected. Users, connections and company details affect everyone. When in doubt, look at the two columns in Figure 1.

I cannot see a section at all

You lack the permission. This is not a fault; administrator sections are visible only to administrators. If you genuinely need one, ask your system administrator and say why you need it — permissions are granted with a reason.

The program slowed down — should I look at the log?

First look at the Server monitor section (or ask your administrator to): it tells you whether the problem is at your end or on the server. The log is the place for "which operation failed". The two answer different questions.

8. Glossary

9. Users › "Role template": creating a user without cloning

The old way to give a new employee permissions was "copy someone similar, then fix a hundred-odd permission boxes one by one"; the result was usually everyone walking around with warehouse-clerk rights — a salesperson could open production orders, a quality officer could see the bank. The Role template group on the Users section ends that: pick, apply, save.

1. Settings › Users › select the user (or create one) › choose the role in the "Role template" selector. Below it the template's description and the modules it opens are listed.
2. Apply (add): the template's bits are added on top of the existing permissions (to combine two templates). Template only: bits outside the template are switched off; the system-administrator bit is preserved.
3. Adjust individual boxes if needed (the template is only a starting point); Save. Nothing is written to the server until you press Save.

Immediate effect: the moment you press Save the user's open sessions are refreshed; no logout is needed. If you change the password, open sessions drop and the user logs in with the new one. The response shows "session refresh: refreshed / dropped" counts. Rule: Security guide, section 8.

Production Preferences: Level 1 and industry templates — administrator guide

10. Login screen › ⚙ "First setup / New company" wizard

The wizard opens from the gear icon on the login screen and creates a new company in seven steps: language and country, database, master administrator, check and create, users, production level, setup summary. No setup key is needed; existing companies are untouched and the wizard stops if a main database, EK1 or company entry already exists under the same code.

Step 2 has two layers: the simple view and "Advanced settings"

The simple view (default) asks a single question: the new company code. The database engine, server address and administrator password are not on screen; they all come from the application server configuration. The administrator account line is read-only and shows hnr_kurulum · password kept on the server ✓: that password is never sent to the browser — the server injects it into the setup request. For this line to appear, the operator must define kurulum.basitKimlik=<user>:<password> in server.properties (the password may come from an environment variable with ${env:NAME}; use kurulum.basitMotor=firebird5 to change the engine). Without that line the wizard opens directly in the advanced view. The account is not a superuser — it only creates company databases; change its password before going to production.

"Advanced settings" asks where the database will live, with three selectable cards; only the fields of the card you pick expand: (1) A database on this computer — the server software runs on the same machine as the application; engine, administrator account and the read-only server line are shown. (2) A remote SQL server on the same network — the database is on another machine; server name, address, port, TLS mode, CA certificate, the Firebird data directory and the runtime role fields open. (3) SQL cluster / cluster servers — the profiles defined in the server configuration are listed; the "Define a cloud cluster…" entry at the bottom opens the same form for Neon and CockroachDB Cloud with verify-full preselected. New definitions in (2) and (3) are selectable only while kurulum.uzakSunucuIzin=true; when it is off the cards are visible but disabled and state why. Every field carries a plain-language explanation next to its technical name plus a ? tooltip (hover, tap or focus with the keyboard).

The "Import data from an existing company" button under the advanced view now opens a real flow: it moves the records of your old Firebird database into a company that already exists (see the section below). The "Starts at Level 1…" note no longer sits in step 1 — it is right under the heading of step 6 (Production level), where the choice is actually made.

Advanced › "A database on this computer": the administrator password is no longer asked

When HNR installed the database server itself (or the operator recorded the credentials once in the configuration file), no engine asks for an administrator user name and password. Pick the "A database on this computer" card in the advanced view and the user-name field shows the stored account (for example postgres, sa, SYSTEM, root, SYSDBA), the password field shows •••••••• and a note underneath reads "Saved administrator password is ready." The password is never sent to the browser: the client only sends a "use the saved credential" flag and the application server injects the password into the setup request. To change it, simply type in either field — the saved mode drops and you continue with your own account; press "Use saved credentials" to go back.

When you choose a different data location (folder) a more privileged account is needed: PostgreSQL creates a new tablespace and only a superuser may do that; in Oracle the same job requires the CREATE TABLESPACE privilege. If that account is recorded in the configuration file too, the user-name field switches to it automatically (hnr_kurulum → postgres) and states "The stored database administrator account will be used for the selected folder." — you are still asked nothing. When no privileged account is stored, an amber box appears with an "Enter the database administrator account" button that opens the fields. The same box also opens by itself if the server returns PG_DIRECTORY_PRIVILEGE_REQUIRED, ORACLE_TABLESPACE_PRIVILEGE_REQUIRED or ORACLE_PRIVILEGE_REQUIRED.

For the operator: the line is kurulum.yerelKimlik.<engine>=<user>:<password> in server.properties; the engine codes are firebird5, postgresql, cockroach, mssql, oracle. The password may come from an environment variable with ${env:NAME}. The credential is used only for the database on this computer: if a remote server or a cluster is selected the server rejects it with SAVED_CREDENTIAL_TARGET_INVALID, and when nothing is stored it returns SAVED_CREDENTIAL_UNAVAILABLE (it never silently tries an empty password). Empty passwords are refused; for an insecure CockroachDB that wants no password, write root:root. Firebird needs no extra line: the existing firebird.user/firebird.password are used. Deleting the line restores the old behaviour — the user types the credentials again.

Advanced › ⤓ "Import a database": moving data from an old company

What it does: it reads the customer and stock cards, invoices, delivery notes, orders, quotations, receipts, cheques, warehouse vouchers, production recipes and orders, personnel records and the images/documents in the EK1 database of your old Firebird database, builds objects from them and saves each one through the company's own write path. What it does not do: it DOES NOT CREATE a company. The target company must already have been created with this wizard. The source database is read-only: not a single row changes during the import.

Step 1 — target company and administrator sign-in. You type the company code and sign in with that company's system administrator. The company list is deliberately not shown: the session itself proves both that the company exists and that you are an administrator in it. A non-administrator can do nothing on this screen (403). If the server is read-only (HNR_WRITE off) the import is rejected.

Step 2 — source database. The source type is FirebirdSQL only for now (the others are listed but cannot be picked). You supply the server address, the port (3050 by default), the database path or alias, the database user (usually SYSDBA) and its password. If the EK1 database path is left empty, _ek1 is appended to the main path. "Test the connection" connects to the source and reports the version, the number of tables and whether EK1 was found; if EK1 is missing, images and documents are not imported and the screen says so plainly.

Step 3 — table inventory. Every table in the source is listed with one of four decisions; none is dropped silently. Object: cards/documents are built from the table and saved through the company's own write path (e.g. MUSTERI → customer card, FATURA + IRSALIYEITEM → invoice and its lines). Copy: if the target has a table with the same name, the shared columns are copied row by row. Derived: not copied — values such as account balances (CARIDURUM) and stock levels (STOKDURUM) are recomputed by the write path and aligned with the source at the end of the import. Skip: a system or log table.

The "skip" decision now covers only regenerable caches. The previous version treated 53,662 rows as "system tables" and never imported them — exchange-rate history (KUR), Logo transfer status (FATURA_LOGO), printer definitions (SISTEMDOSYA), interface and field-label dictionaries (METIN_SOZLUK, ALAN_SOZLUK), HR and production logs. All of them are copied now. The only genuinely skipped item is the file preview cache, and its reason is written in the list. Tables of the EK1 database other than file content (e.g. the access trail) are also carried over and appear in the list with an EK1. prefix.

Document numbers are preserved. Invoice, delivery note, order, quotation, receipt, cheque batch and warehouse voucher numbers stay exactly as they were — after twenty years of archive, "which invoice number" still has the same answer. At the end of the import the number counters are advanced past the largest value, so the first document issued afterwards cannot collide.

Fidelity to the source — automatic alignments. A twenty-year-old database is not always internally consistent; the import does not correct the source, it resembles it. Four alignments therefore run at the end: (1) customer ledger code — when a customer card was renamed, older HNR versions did not update receipt headers, so the ledger row and the document header carry different codes; in the target the ledger row takes the code from the source ledger row, (2) leftover balance rows — balance rows that do not exist in the source and have neither a card nor a cash/bank account are removed, (3) stock rows without a card — stock status rows never seen in the source and without a card are removed, (4) production consumption rows — the lot split of production consumption is brought to the source’s row list. Every alignment is fail-closed: if the totals on the two sides differ, nothing is touched; the counts appear in the "Automatic corrections" line of the result screen and in the import log.

The company's own configuration OVERWRITES the target defaults. A fresh company setup seeds tables such as production preferences, approval rules, shifts, warehouses and cash accounts. Those seed rows collide with the source rows that share the same key, and the source used to be skipped SILENTLY — the imported company opened with the "Level 1" profile and APQP/subcontracting rules turned off. In small configuration tables the source now wins: the target row is updated from the source. There are two deliberate exceptions: user cards (so you do not lose the administrator password created during setup) and the company setup identity. Every skipped key appears in the "Per-table result" list in step 5.

Shifted document number protection. When you import into the same company a second time (finishing an interrupted run, the remainder of a selective import), a document number can shift. That ledger entry used to be treated as "not in the source" and DELETED, removing money from the statement; because CARIDURUM is written from the source, the balance still looked right and contradicted the statement. Two things happen now: (1) in import mode the definite-number ledger no longer makes a number count as "taken", so the number is preserved; (2) if a shifted group is found anyway it is not deleted — it is recorded in the reconciliation as a Deviation and written to the log. In production consumption rows the price is now carried from the source as well, and the new line value check verifies it per document type.

Open invoice balances (KALAN) and the Maintenance section

Open invoice balances are derived. The old desktop program never filled an invoice's remaining amount (FATURA.KALAN), while in HNR ageing, the cockpit's "overdue receivables", cash flow and closing invoices from receipts all read this field. So in the derived-reconciliation phase the import processes each account's movements in date order: payments, returns and cheques close the oldest invoices first (FIFO) and the account's open balance is written to the newest invoices. Sales and purchase invoices follow the same rule; cancelled invoices stay closed; accounts whose net balance is below 1 TL (old rounding residue) get no open invoice. An account that already has a remaining amount on any invoice is left untouched. The fatura.kalanTop row of the reconciliation table compares the target with the total the same rule gives on the source database. Part of an open balance may sit on an issued cheque/note, a debit note or a bank/cash movement rather than on an invoice; that part is not shown on invoices but is visible in the account statement.

Maintenance section (in step 2, after sign-in). Repair open balances applies the same rule in place to a company that was imported earlier. A preview is shown first (invoices to change, previous and next total, skipped accounts, open balance outside invoices) and nothing is written; Apply repair writes only the remaining-amount field, re-checks the old value on every row (an invoice changed by a receipt in the meantime is not overwritten) and is recorded in the activity trail. Running it again produces no changes. Reseed the dictionary adds the missing rows of the interface and field translations (24 languages); manually edited translations are not touched and it takes a few minutes. When a new company is set up, this seeding runs automatically in the background once the company is open; if it fails the setup does not fail, it is written to the setup log and can be completed with this button. If the page is reloaded or the server restarts, an import still running opens in step 4 by itself when you sign in; the result of the last finished import is available through Show result of the last import. The inventory in step 3 also lists the tables of the EK1 database with their row counts.

Import options. Dry run: everything is read and counted but nothing is written — run this first to see the inventory and an estimate of the duration. Also import the deleted-document archive and Also import historical movements: the archive tables of the old company (imported in the last phase; interrupting them does not make the import a failure). Import images and documents (EK1): the files in the EK1 database. Continue even if the target already has data: by default the import stops when the target company already has records; this box is your consent. Batch size: how many records are written per transaction (200 by default).

Step 4 — import and progress. You see the stage (preparation → cards → documents → production → images and documents → general table copy → archive → derived-value reconciliation → reconciliation measurement), the percentage, the written/skipped/failed counters and the last lines of the import log. The log is masked: passwords, tokens and credentials inside connection strings are never written. Stop ends the job at the next safe point; a half-finished batch is rolled back. The job runs on the server: closing the window does not stop it, and when you come back you see the state of the same job.

Step 5 — how to read the reconciliation table. Each row is one measured item: Source is the value read from the old database, Target the value read from the new company, Difference the gap between them. A status of Matches means the item came across exactly. Deviation is printed in red and must be examined by hand. Known deviation is an expected difference that comes from the source itself (for example a customer duplicated in the source, or cheques without a batch). The measured items are: account balances, stock levels (overall and per warehouse), cheque count/amount/status, receipt and invoice counts and amounts, production recipe and order counts, the EK1 file count and table coverage.

If the reconciliation deviates, the job does not say "completed". When a check deviates, the result heading reads "Import finished — BUT the reconciliation shows a deviation" and the names of the deviating checks are listed in an amber band above the table. The "Per-table result" disclosure shows, for every source table, its decision, source row count, written, skipped and failed rows and the reason; tables with failed rows are at the top and in red. Look at both lists before you start using the imported company.

You can import the same source a second time. The import is identity-based: a card, document, cheque or file that already exists in the target is not written again, it is counted as skipped. Restarting an interrupted import from the beginning is safe; no duplicates are created.

A selective (table-filtered) import does not run the derived-table alignment. When you import only certain tables, writing derived tables such as customer balances and stock levels from the source is skipped — some documents have not been imported yet and a partial alignment would mislead. This is recorded in the reconciliation as a Known deviation. Once you import the remaining tables (an unfiltered run) the alignment runs normally.

Error codes. AKTARIM_OTURUM_GEREKLI no session or it expired · AKTARIM_YONETICI_GEREKLI / AKTARIM_YETKI_YOK the user is not a system administrator · AKTARIM_YAZMA_KAPALI the server is read-only · AKTARIM_HEDEF_UYUSMAZ the chosen company is not the session's company · KAYNAK_GECERSIZ the source form is malformed · KAYNAK_ERISILEMEDI could not connect to the source · KAYNAK_KIMLIK the source user/password was rejected · KAYNAK_UZAK_YASAK the allow list in the server configuration blocks that address · KAYNAK_EK1_YOK EK1 could not be opened (the import continues, files are skipped) · HEDEF_DOLU the target has records, the consent box is required · HEDEF_SEMA_EKSIK the target has no counterpart table (it is skipped) · AKTARIM_SURUYOR a job is already running for this company · AKTARIM_IS_BULUNAMADI the job record is gone or expired · AKTARIM_IPTAL_EDILDI stopped by the user · AKTARIM_FAZ_HATASI a phase stopped (see the log).

Take a backup of the target company before importing. The import writes to the target and never touches the source. If the result in the target is not what you wanted, the way back is the backup — so run a dry run first, review the inventory, then take a backup and start the real import.

Database engine: Firebird SQL 5 and PostgreSQL 17 — both fully supported

You choose the engine in step 2. Firebird SQL 5: the SYSDBA account and the password set when Firebird was installed; the server must be local. PostgreSQL 17: company data lives in hnr_<company code> and file attachments in hnr_<company code>_ek1; the given account must be a superuser with CREATEDB, and the created databases are handed over to the server runtime role (postgresql.user). Document entry, reports, stock/account cards and attachments (upload / list / download / preview / cancel) behave identically on both engines.

The "Server" line: host:port · TLS — read-only

Once an engine is selected, a Server · <engine> line appears under the administrator password, e.g. localhost:5432 · TLS: disable. These values are read from the application server configuration (server.properties) and cannot be changed in the wizard: no address, port or path coming from the browser is ever forwarded to the server, so the administrator identity cannot be pointed at an arbitrary target. The Firebird line additionally says "local server required". Contact the server operator if you need a different database server.

The "Sorting/letter-case language" line: the company database language follows the country

Below the Server line you will see Sorting/letter-case language: the official language of the regulatory country chosen in step 1 (e.g. Türkiye → Turkish (tr), Sweden → Swedish (sv), Indonesia → Indonesian (id)); the same line appears in the setup summary. This language sets the letter rules of the company database: equality searches are language-independent (case- and accent-insensitive root comparison — "ali" matches "ALİ", "sema" matches "ŞEMA" in every country), while sorting and upper/lower-case conversion follow the country's official language (Turkish ç/ş/ı order and ı↔I, i↔İ; Swedish ä/ö at the end of the alphabet). The value is read from the server's country→language table, cannot be changed on screen and is fixed after setup. On the CockroachDB engine language ordering applies only to ORDER BY in simple single-table queries; complex queries may show code-point order.

A database on another server: the "Server" selection

The company database can also be created on a database server running on another machine instead of the one hosting the application server. You install the database server yourself (Firebird 5, PostgreSQL or CockroachDB) on that machine, make it reachable over the network and set its administrator password; the wizard installs nothing, it only connects and creates the company database there. This requires the line kurulum.uzakSunucuIzin=true in the operator's server.properties; if the address is outside the private ranges (10.x, 172.16-31.x, 192.168.x, 127.x) it must additionally be listed in kurulum.sunucuIzinListesi=host1,host2. While the permission is off, the Server line in step 2 stays read-only as before.

When the permission is on, the Server line in step 2 becomes a selector: it lists the servers defined in the server settings (kume.<name>.*) plus "This server (configured)", and at the bottom "Define another server…". A new definition asks for: a server name (at most 30 letters/digits/underscores/hyphens starting with a lowercase letter; firebird, postgresql and cockroach are reserved), address and port, for PostgreSQL/CockroachDB a TLS mode and an optional CA certificate (PEM file, at most 16 KB), for Firebird the data directory (the root directory on the remote machine where the company file is created) and an optional runtime role user/password. If the runtime role already exists on that server its password is verified; otherwise setup creates the role and generates its password. When setup finishes, the server definition and the company line (firma.<company>=kume:<name>) are written to server.properties, where the password and certificate are stored as well; the application does not need a restart.

Error codes the precheck may return

Several company setups at once, and the setup log

Different company codes can be installed at the same time; companies going to separate database servers no longer wait for each other. The lock is on the company code: a second setup for the same code is rejected with SETUP_IN_PROGRESS (the company code is unique server-wide). By default at most 3 setups run at once. When the setup window reports a failure, a "Setup log (last lines)" disclosure appears under the error: these lines are the diagnostic output of the database server and the setup helper (stage timings, engine warnings, database error messages). Passwords and connection details are not shown there; you can forward the content as-is to the server operator.

If PostgreSQL is not on this computer: HNR installs it

If no PostgreSQL is found in the Database step, the wizard shows an "Install PostgreSQL" button. One click runs the built-in installer: it takes about a minute, uses roughly 200 MB and the resulting server accepts connections only from this computer (listen_addresses=localhost, password check scram-sha-256). Progress is shown stage by stage: data directory, configuration files, starting the server, database roles, template database, server settings, verification. When it finishes you continue where you left off; no database user name or password is ever requested.

What does the installer write? The cluster is installed under data/pg (data directory data/pg/veri, log data/pg/pg.log). The role model matches data/pg-calisma-rolu.sql: runtime role hnr_uygulama (not a superuser, cannot create databases), provisioning role hnr_kurulum (CREATEDB) and a hnr_sablon template database for the company language (with the implicit cast layer inside). Only the lines postgresql.host/port/user/password/sslmode and kurulum.basitKimlik are appended to server.properties; no existing line is changed and a server.properties.bak-… backup is taken first. The superuser (postgres) password is never written to the settings file: it lives only in data/pg/HNR-PG-SIRLAR.txt — back that file up and keep it away from unauthorised access.

Limits and troubleshooting. The installer can only be started from the computer running the application (a remote browser gets 403) and currently runs on Windows only. If the PostgreSQL program files are missing, instead of the button you see a warning that the operator must extract the Windows x64 binaries zip into tools/postgresql — the installer never downloads anything. If PostgreSQL is already configured the installer does nothing. Setup also registers a task that starts PostgreSQL when the computer starts; if that task cannot be registered (permission limits) PostgreSQL still runs, but a warning says it must be started manually after a restart. Only a cluster HNR installed itself can be removed; removal clears the task, the data directory and the server.properties lines together, and all company data in that cluster is deleted.

If Oracle is selected: privileges of the setup account

Privileges required for setup. On Oracle a company is created as two schema owners (main + EK1). The database account you type into the wizard must hold these system privileges: CREATE USER, ALTER USER, GRANT ANY PRIVILEGE. If you chose a custom data location (your own tablespace/DBF path) under advanced settings, CREATE TABLESPACE is also required. If any is missing the wizard stops before starting and names the missing privileges (ORACLE_PRIVILEGE_REQUIRED) — it never leaves a half-created company.

Recommended extra privileges. DROP USER (plus DROP TABLESPACE for a custom location) is not required for setup, but if something fails mid-setup HNR uses it to remove the half-created schema owners itself. Without it setup is still attempted; the error message then states which schema owner you must delete by hand via ORACLE_YARIM_KURULUM_KALDIRILAMADI. Granting DROP USER only for the duration of setup and revoking it afterwards is therefore good practice.

The runtime account is separate. The wizard creates two schema owners per company and grants them only CREATE SESSION, CREATE TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE PROCEDURE, CREATE TRIGGER; the quota is set as QUOTA UNLIMITED on the selected tablespace. So the account used in daily work cannot see another company and cannot create users or schemas.

11. Settings › HNR › "Company database backup" and restoring from a backup

What it is for. The Company database backup card in Settings › HNR writes the main and EK1 databases of the company you are in into a single encrypted package folder. The package appears as a new folder under the directory you choose on the computer running the HNR server: main.enc, ek1.enc and the completion marker hnr-yedek.json, written last. You must be a system administrator and re-enter your current HNR administrator password; that same password opens the package. No server or database credentials are stored in it.

Restoring. The "Create a new company from an HNR backup" screen, opened from the ⋮ menu on the login screen, always restores into a NEW company code — an existing company is never overwritten. The restore asks both for the HNR administrator password used when the backup was taken and for the target database administrator (Firebird: SYSDBA, PostgreSQL: a superuser, CockroachDB: root/admin, SQL Server: sysadmin, Oracle: an administrator holding CREATE USER). The company is published only after both payloads are opened and verified; with a wrong password or a corrupted second part nothing is created on the target.

Supported engines. Firebird, PostgreSQL, a local CockroachDB node installed by HNR itself, Microsoft SQL Server and Oracle. For Firebird/PostgreSQL/CockroachDB the engine's own backup tool is used. For SQL Server and Oracle the package is logical: the schema definition plus every table's rows are read over the database connection. That way a backup can be taken even when the database server is remote or inside a container; no access to the server's file system is needed. The restore creates a new database/schema and a new runtime user for the new company; for an Oracle package you must enter the target cluster name (and, if needed, the service name, default FREEPDB1).

Things to know. Main and EK1 are backed up separately; there is no single atomic instant across the two — choose a short window with no activity in the company. Only one backup or restore can run at a time. The backup folder is on the server's file system, not the browser's, and linked (symlink/junction) folders are rejected. Copy the package somewhere safe: without the package there is no way back, and without the password the package cannot be opened.