I think I’ve deleted some events in my calendar, how can I retrieve them from my regular backups?
When I backup, I use Events & Tasks>Export, which saves the calendars as .ics files. I tried to Import, but that just seemed to me as if it merged two calendar events together - the current and the imported one? Then I thought I’d delete the current calendar and import an earlier backup. Trying to find the location of the calendar files is not easy. Calendar tells me there are located at “moz-storage-calendar://”, but I can’t work out where it might be. Searching hasn’t turned anything up. Or perhaps the curent calendar data is not saved as .ics? Should I perhaps delete the calendar via the menu, then import a backup, find the data I want, delete that earlier imported backup then import the current backup? Or is there some other way to manage this job?
Chosen solution
I think all this points to the export and import process being ill-suited to a backup process. Since there is no scripting or automation in Thunderbird, you must be having to do a tiresome number of manual steps to export your calendars.
No, Thunderbird doesn't use .ics files internally, just as it doesn't use .eml for email nor .csv for address books, though these are all useful export/import formats. Your internal calendar data is stored in your profile in sqlite files inside calendar-data, e.g. "C:\Users\xxx\AppData\Roaming\Thunderbird\Profiles\xxx_profile\calendar-data".
I keep a lot of my data backed up by storing elsewhere, either in a google account or on dropbox. These are automatic procedures that I don't need to think about or have to remember to do, and part of choosing this approach is making some calendars available to my computer at work, my computer at home and to my phone and tablet.
An alternative approach might be to back up your entire profile.
Read this answer in context 👍 1All Replies (3)
Chosen Solution
I think all this points to the export and import process being ill-suited to a backup process. Since there is no scripting or automation in Thunderbird, you must be having to do a tiresome number of manual steps to export your calendars.
No, Thunderbird doesn't use .ics files internally, just as it doesn't use .eml for email nor .csv for address books, though these are all useful export/import formats. Your internal calendar data is stored in your profile in sqlite files inside calendar-data, e.g. "C:\Users\xxx\AppData\Roaming\Thunderbird\Profiles\xxx_profile\calendar-data".
I keep a lot of my data backed up by storing elsewhere, either in a google account or on dropbox. These are automatic procedures that I don't need to think about or have to remember to do, and part of choosing this approach is making some calendars available to my computer at work, my computer at home and to my phone and tablet.
An alternative approach might be to back up your entire profile.
Thank you for your comprehensive answer, and explaining clearly where the calendar files are stored.
What I have done now is to store the .ics files within my Thunderbird profile on my D drive. My entire profile is over 8Gb, so for me I think it’s better to still export to .ics format monthly, in case I need to refer back to them.
I notice that when opening calendar files (restoring) via File>Open>Calendar File, the individual calendar colors I used are lost, and all revert to a default light blue. What I’ve done is to save a text file with all the RGB colors I’ve used, then at least I can restore them easily if necessary.
Thanks once again for taking the trouble to reply.
I have never tried it, but you could try selectively backing up just those sqlite files. Or the whole calendar-data folder.
The important thing with any backup system is to be sure you can restore from the backed-up data. It's easy to copy files; it may not be so easy to put the data back into place.
My concern is that I don't know if the sqlite files tell the whole story; if they rely on some other magic file that glues it all together, they won't be of much use without that file. The colours, for instance, may be handled separately.