Skip to main content
Version: 3.4.7

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 .vgp too 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.

This is a project backup, not a data backup

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 saveIf Backup On Save is enabled. Backup Interval then decides how often one is actually kept — Always, Hourly, Daily, Weekly, Monthly, Yearly or Never.
On demandFile → Backup DB and VGP.
Before a version upgradeAutomatically, and the upgrade is abandoned if the backup fails — so there is always a way back.
Before a database migration or vacuumAutomatically.
Before a recoveryOptionally, 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.

On a large project, do not leave Backup Interval on Always

Every 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.

  1. 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.
  2. File → Recover a project.
  3. Browse to the project file you want to restore (.vgpx, or .vgp for an older project). VRGS finds its VGP_BACKUP folder and lists every backup it holds, with Date/Time, Type, Size and File Name.
  4. Pick the backup you want. Double-clicking it starts the recovery.
  5. 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.
  6. 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.
  7. 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.

Recovery overwrites the live project

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:

  1. Take a copy of the whole project first: the .vgpx and its Data folder.
  2. Extract the backup zip somewhere outside the project.
  3. Copy the .vgpx (and .vgp, if present) next to the original project file.
  4. Copy SQLDBv4.db into <project> Data\DATABASES.
  5. Copy the version-control sidecar from the same folder in the zip, so it stays in step with the database.
  6. Open the project.

VRGS must be closed, or at least the project closed, while you do this.

Still stuck?

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