Back up before the event
Create a current backup before major data changes, version upgrades, restore operations or computer migration.
Help Center · Backup and Restore
A backup is not just a file copy; it is a safe state you can return to.
Dersiva’s portable `.ddbackup` format is used to move supported school data and timetable state to another installation or restore it later. A safe process begins with choosing the right backup point and ends with post-restore verification.
Backup approach
A backup is valuable only when it can be restored and verified.
Use the portable package
Use Dersiva’s `.ddbackup` for migration; do not manually copy machine-specific files from the application directory.
Know the restore scope
Not every restore does the same thing. Full restore, last timetable + other data, and data without timetable history produce different outcomes.
Verify after restore
A successful message is not the end. Check teachers, lessons, assignments, timetable and, where relevant, duty and portal publication state.
01
Understand what a .ddbackup file is
`.ddbackup` is Dersiva’s portable full-backup format. Its purpose is to move supported school state as a restorable package rather than merely copying a raw database file.
02
Create backups at the right moments
Take a fresh backup before significant lesson-assignment changes, data reset, version upgrades, migration to another computer and restore attempts. Creating a milestone backup after the applied timetable is finalized is also useful.
03
Use meaningful backup filenames
Include distinguishing information such as date, school or purpose in the backup filename. Choosing the wrong file among many similar backups is a common operational mistake.
04
Do not keep the only backup on the same computer
Keep at least one copy in another secure location to protect against disk or computer failure. An external drive, controlled institutional storage or another secured location may be used according to the sensitivity of school data.
05
Verify that the backup file exists and is accessible
After backup, confirm that the file was actually created, is not zero bytes and can be accessed from its storage location. This is only a first integrity check, but it catches basic failures.
06
Do not manually migrate machine-specific key files
Some local protection files can be tied to the Windows or machine context. A machine-specific DPAPI-protected key file, for example, should not be copied to another computer as part of portable migration. Use the `.ddbackup` restore workflow.
07
Option 1: Restore everything
A full restore makes the supported state in the backup the primary state of the target installation. It is suitable for migration or full-recovery scenarios where the target should closely match the backed-up system.
08
Option 2: Restore the last timetable plus other data
This scope restores core school data together with the last timetable when you do not want to carry the entire timetable history. Verify which timetable was restored and whether its applied status is correct.
09
Option 3: Restore other data without timetables
Use the data-without-timetables scope when you want teachers, lessons, classes, settings and other supported core data but do not want old timetable history. A new timetable may need to be generated afterwards.
10
Protect the current target state before restoring
If the target computer already contains valuable data, back it up before starting restore. This gives you a return point if the wrong backup or restore scope is selected.
11
Move to a new computer in two stages
Install a compatible Dersiva version on the new computer and confirm that it opens normally. Then restore the `.ddbackup`. Do not use direct copying of the old application folder or machine-specific security files as the migration method.
12
Check version compatibility
A backup from an older Dersiva version may require data-model migration during restore. Where possible, use a supported target version that is the same as or newer than the backup version and review release notes.
13
Compare core data after restore
Review teacher count, lessons, classes/sections, lesson assignments, school time structure and critical settings. Compare totals and selected sample records with the expected backed-up state.
14
Verify timetable and duty state separately
If timetables are included, check the last timetable, applied timetable, related duty snapshot and publication state independently. Make sure an old timetable has not accidentally become the applied timetable.
15
Do not assume portal publication is automatically correct after restore
Restoring local data does not automatically mean the Teacher Portal server is on the same revision. Verify which timetable is applied and which revision is published, and republish when necessary.
16
Test critical backups when possible
For critical milestone backups—such as term start, applied timetable or computer migration—performing a controlled test restore is the strongest way to prove recoverability. Do not rely only on the backup operation completing successfully.
Restore scopes
Restore only what the scenario requires.
ALL
Full restore
All supported school state
Migration / full recoveryLAST
Last timetable + other data
Core data + last timetable
Keep timetable history leanDATA
Without timetables
Core data, no timetable history
Start clean timetable generationSafe restore chain
A sequence designed to prevent wrong-file selection and irreversible loss
Back up current state
Create a return point for the target computer.
Choose backup and scope
Verify filename, date and restore mode.
Restore
Do not interrupt the application or alter files during the operation.
Verify
Check data, timetable, duty and portal publication where relevant.
Critical migration mistake
Copying the old application folder directly to the new computer.
The application folder, database and machine-specific security files are not the same thing. Use `.ddbackup` for portable data transfer; install Dersiva normally on the target computer and restore through the supported workflow.
Next guide
v3.23 — Troubleshooting Guide
Timetable-generation crashes, OR-Tools/native runtime, license/API connectivity, portal publication problems, data/constraint issues and log analysis will be combined into one diagnostic tree next.
Help Center