Managing backups
VRGS keeps dated snapshots of your project so a bad edit, a failed upgrade or a corrupted database does not cost you the work. This page covers what it keeps, where, and how to get it back.
What gets backed up
A backup is a single .zip written into the VGP_BACKUP folder inside your
project's Data folder. Each one holds:
- the project file — the
.vgpx, and the legacy.vgptoo if the project still has one; SQLDBv4.db, the project database, which is where every interpretation lives;- the interpretation version-control sidecar that sits beside the database.
The database is held open for the whole session, so VRGS snapshots it to a temporary copy and archives that — which is why a backup is safe to take while you are working.
Point clouds, meshes, textures and imported images are not in the zip. They
are large, and they have not changed. A backup restores your project and your
interpretation; it assumes the rest of the Data folder is still there.
When backups are taken
| On save | If Backup On Save is enabled. Backup Interval then decides how often one is actually kept — Always, Hourly, Daily, Weekly, Monthly, Yearly or Never. |
| On demand | File → Backup DB and VGP. |
| Before a version upgrade | Automatically, and the upgrade is abandoned if the backup fails — so there is always a way back. |
| Before a database migration or vacuum | Automatically. |
| Before a recovery | Optionally, so restoring an old backup does not throw away the current state. |
Both settings live in Project Properties → Saving & Backup, alongside Enable Auto Save and the Autosave interval. See Project Properties.
AlwaysEvery save then writes a full zip of the database, which makes saving slow on a
big project. Daily keeps a useful safety net without the cost.
Reading the backup names
Backups are named for the moment they were taken, with the reason appended:
Sat_Oct_24_172750_2020.zip ← a routine backup on save
Sat_Oct_24_172750_2020_Manual.zip ← File → Backup DB and VGP
Sat_Oct_22_201643_2020_UpgradeFrom_266.zip ← taken before upgrading from v266
Sat_Oct_22_201643_2020_PreVacuum.zip ← taken before compacting the database
Sat_Oct_22_201643_2020_PreRecovery.zip ← taken before restoring another backup
The stamp is weekday_month_day_HHMMSS_year. You rarely need to read these
yourself — the recovery dialog below parses them for you and shows a sortable
date, type and size.
Recovering a project
Use the built-in dialog. VRGS has a recovery command that does the whole job — no renaming files, no unzipping by hand.
- Close the current project. The Recover a project command is greyed out while one is open, because recovery overwrites the very files a loaded project is holding.
- File → Recover a project.
- Browse to the project file you want to restore (
.vgpx, or.vgpfor an older project). VRGS finds itsVGP_BACKUPfolder and lists every backup it holds, with Date/Time, Type, Size and File Name. - Pick the backup you want. Double-clicking it starts the recovery.
- Choose what to restore: Restore VGP file, Restore Database, or both. Both are ticked by default, and both is almost always what you want — the project file and the database describe the same state, and restoring one without the other leaves them disagreeing.
- VRGS offers to back up the current files first. Say yes. It costs seconds and it is the difference between an experiment and a one-way door.
- When it finishes, VRGS offers to open the recovered project.
The Type column tells you what each backup was for — Normal, Manual,
Upgrade from v###, Pre-Recovery — which is usually how you find the one you
want. If a backup could not be compressed at the time it was made, it is stored
uncompressed and shown as … (uncompressed); recovery handles both.
Restoring replaces the current .vgpx and SQLDBv4.db with the archived ones.
Anything done since that backup was taken is gone unless you accepted the
pre-recovery backup in step 6.
If you are unsure which backup you want, copy the whole project — the .vgpx
and its Data folder — somewhere else first and experiment on the copy.
If you have to do it by hand
You should not need to, but if the dialog cannot reach a backup — you are restoring into a different folder, or recovering only a fragment — the zip is an ordinary archive:
- Take a copy of the whole project first: the
.vgpxand itsDatafolder. - Extract the backup zip somewhere outside the project.
- Copy the
.vgpx(and.vgp, if present) next to the original project file. - Copy
SQLDBv4.dbinto<project> Data\DATABASES. - Copy the version-control sidecar from the same folder in the zip, so it stays in step with the database.
- Open the project.
VRGS must be closed, or at least the project closed, while you do this.
If a project will not open and none of the backups help, contact VRGS support before experimenting further — and send the copy you took in step 1, not the original.
See also
- The project directory structure — where the backup folder sits, and what else is in the data folder.
- Project Properties — the autosave and backup settings in full.