A Backup Strategy That Survives a Bad Day | Timebars Ltd.

Your plan lives in your browser. That makes the tools fast and lets them work offline. It also means your browser holds the working copy of your data, so a backup strategy is part of using them well. Browser data can be cleared, a laptop can be replaced, and an import can go wrong. A good backup turns each of those into a five-minute restore instead of a week of re-typing.

The one backup that matters: Full Backup

Choose Hamburger Icon → Full Backup. It saves one file, tbFullBackup_YYYY-MM-DD_HH-MM-SS.js, containing every part of your data: bars, metadata, resources, picklists and configuration. Restoring it puts the application back exactly as it was.

To restore, drop the file onto Hamburger Icon → Import SpreadSheet, CSV or JSON. A restore replaces everything, so take a fresh backup of the current state first if you might want to come back to it.

Your other copies

Copy	How	What it is for
Publish	Main Menu → Publish	a copy on the server you can re-hydrate on any device, and the source of your dashboards
Export to CSV	Hamburger Icon → Export to CSV (SpreadSheet sync.)	the spreadsheet round trip, and a copy you can read in any spreadsheet
Export to JSON	Hamburger Icon → Export to JSON	integrations and external tools
The workbook	import the CSV files into the Timebars spreadsheet	your editable master, kept with your other documents

Only a Full Backup is a complete restore point. The others each hold part of your data.

Automatic backups

The application takes a Full Backup for you, unasked, just before anything destructive:

importing a spreadsheet, CSV or JSON file
loading demo data
clearing timebars and metadata

They land in your downloads folder. They are a safety net, not a strategy: after a couple of weeks you will not be able to tell which one is the good one.

A routine that works

Practice	Why
Keep a dedicated backups folder, not Downloads	the automatic backups bury the ones you meant to keep
Keep three to five recent Full Backups	enough to step back past a bad day, few enough to tell apart
Keep one monthly backup for as long as the plan matters	someone will ask what the plan looked like at approval
Keep the filename the application gave it	the date is in the name, and a renamed file will not import
Take one before, not after	any import, bulk change, configuration change or new browser
Copy the folder to your document system or cloud storage	your company's backups then cover it, off the machine

How often? Daily while you are actively working a critical plan, weekly for stable work. The honest test is how much re-typing you are willing to do, because that is what a restore costs you.

When something goes wrong

What happened	What to do
Browser data was cleared and your work is gone	Restore your latest Full Backup, then stop the browser clearing site data on exit
Your data seems missing in another browser	Nothing is lost: data is kept per browser and per machine. Go back to the one you used, or restore a backup here
You imported the wrong file	Restore the automatic backup taken just before the import: the newest `tbFullBackup_` file in Downloads
You are moving to a new machine	Take a Full Backup on the old one and import it on the new one, or publish and re-hydrate

Running your own servers?

If you host the suite yourself, the server side has its own nightly backup. One script saves the backend database, its uploads and the settings, and your normal backup system copies them off the server. Users' plans still live in their browsers, so the routine above applies to every user as well.