Yes that should work. But I suspect that you need to be more precise as to where the places.sqlite file that you want to backup is located. Backup software typically needs to be told the exact location of the file the user wants to backup.

AppData\Roaming\Mozilla\Firefox\Profiles - then have the Profile name - \a1b2c3d4.default\place.sqlite - which is where the places.sqlite file is sitting.

And of course, you need to use the name of the Profile as it appears on your PC. I gave an example Profile name.

Yes, to be clear I did specify that same target address, I just didn't type out that last profile folder name in my original post.

But I had not considered extending the target destination down to the file level, since that has never been necessary in my past backup operations, where simply specifying the containing folder to be backed up would ensure all files pertaining therein would be covered.

In this case however, the only items I particularly care about within that profile folder are places.sqlite and the "sessions" subdirectory. Would it be okay to specifically target these as the only elements to be backed up within the profile directory at the exclusion of all other files/folders? Or are there are other files within the profile folder required for these to be functional as backup/profile restore files?

Hope that makes sense, thanks.

I just got around to re-attempting to backup process, this time specifically designating the target backup address down to actual places.sqlite file level within the Seagate software. And I can now confirm that this file does not seem to be recognizable by the program, because it simply will not copy this file even after being specifically directed to do so.

I'm fully prepared to accept this as a limitation of the program (it is free from the manufacturer), however this is still pretty unusual. As previously stated, this is the first time I've run into this issue (files failing to copy in backup) using this program. Any idea why this may be happening?

Thanks again.

Is Firefox closed when this software is running?

Otherwise the file might be locked.

No, as a matter of fact FF has been open during each of my backup attempts. You're saying keeping it open locks other programs from accessing the profile.sqlite file?

You can try if it works with Firefox closed.

You know, honestly even if that were to solve the issue, it wouldn't really make much of a difference for me. Since my original intent was rendering a real-time, persistent backup state on my system specifically pertaining to bookmarks, and considering the fact that I have FF open the majority of the time my system is running, requiring the browser to be closed for the software to kick in would be pretty unfeasible. So I think I'll probably just let this one go for now. Thanks for the suggestions.

The backup program can try to set a lock on the file to create the backup and that will fail because Firefox already has a lock on the file.

Some backup programs use VSS (shadow copy) to work around file locks, not sure about that one. You might consider another free one that has more advanced features such as:

https://www.comodo.com/home/backup-online-storage/comodo-backup.php

http://www.easeus.com/backup-software/tb-free.html

There is a potential issue, however, with restoring a .sqlite file that's in use, which is there may be cached disk writes in the journaling files: places.sqlite-shm and places.sqlite-wal. I think you should back those up at the same time since you may need to restore them together. Most likely, the difference will be history rather than bookmarks, but you never know. The worst case scenario is Firefox declaring the .sqlite file corrupt, and rebuilding from the last bookmark backup file, so it's essential to back those up as well.

Considering your intent it to backup your bookmarks, why not use the bookmarks.html format for those backups.

Recent versions of Firefox don't use bookmarks.html any longer, and the last few versions don't even have the bookmarks.html file (with the default bookmarks) present; but the underlying code for that 'system' still seems to be there - it is still working for me and it's quite easy to enable and use it to create / update a bookmarks "export" to the bookmarks.html format in the Profile folder. And that file shouldn't be locked as with place.sqlite.

• In about:config toggle this preference to true - browser.bookmarks.autoExportHTML and restart Firefox.
• That will create the first "export" of your bookmarks in bookmarks.html format.
• After that a new, updated file will overwrite the previous version as Firefox is closed each time (or daily I'm not sure which as I haven't monitored the date / timestamp in recent versions - but it does still work for me in Firefox 46.0.1 (as of 05-18-2016 @ 08:02 am, the last time I used that Firefox installation).

Not "real-time" as you are looking to do, but IMO it overcomes issues with the places.sqlite file being locked while Firefox is running. Of course the "export" bookmarks.html file won't be updated until Firefox is being closed down, but that file won't be locked while Firefox is running, either.

jscher2000 said

Some backup programs use VSS (shadow copy) to work around file locks, not sure about that one. You might consider another free one that has more advanced features such as: https://www.comodo.com/home/backup-online-storage/comodo-backup.php http://www.easeus.com/backup-software/tb-free.html There is a potential issue, however, with restoring a .sqlite file that's in use, which is there may be cached disk writes in the journaling files: places.sqlite-shm and places.sqlite-wal. I think you should back those up at the same time since you may need to restore them together. Most likely, the difference will be history rather than bookmarks, but you never know. The worst case scenario is Firefox declaring the .sqlite file corrupt, and rebuilding from the last bookmark backup file, so it's essential to back those up as well.

Thanks for this, noted.

In this particular case, things would be much simpler if bookmarks were saved by default in the bookmarks.html file as they were in earlier FF iterations. AFAIK the only way to generate a bookmarks.html file is to manually export one yourself, which would only store bookmarks as new as when the file was created.

the-edmeister said

Considering your intent it to backup your bookmarks, why not use the bookmarks.html format for those backups. Recent versions of Firefox don't use bookmarks.html any longer, and the last few versions don't even have the bookmarks.html file (with the default bookmarks) present; but the underlying code for that 'system' still seems to be there - it is still working for me and it's quite easy to enable and use it to create / update a bookmarks "export" to the bookmarks.html format in the Profile folder. And that file shouldn't be locked as with place.sqlite.

• In about:config toggle this preference to true - browser.bookmarks.autoExportHTML and restart Firefox.
• That will create the first "export" of your bookmarks in bookmarks.html format.
• After that a new, updated file will overwrite the previous version as Firefox is closed each time (or daily I'm not sure which as I haven't monitored the date / timestamp in recent versions - but it does still work for me in Firefox 46.0.1 (as of 05-18-2016 @ 08:02 am, the last time I used that Firefox installation).

Not "real-time" as you are looking to do, but IMO it overcomes issues with the places.sqlite file being locked while Firefox is running. Of course the "export" bookmarks.html file won't be updated until Firefox is being closed down, but that file won't be locked while Firefox is running, either.

Ah, very good, this is indeed exactly the kind of thing I was looking for. i will try this later and report back, thanks.

Note that you can specify the full path of the bookmarks.html file.

• http://kb.mozillazine.org/browser.bookmarks.autoExportHTML

This HTML backup is created by default in the profile folder as bookmarks.html every time you close Firefox, but you can set the path and file name via the browser.bookmarks.file pref on the about:config page.

• http://kb.mozillazine.org/browser.bookmarks.file

The browser.bookmarks.file pref doesn't exist by default and you need to create a new String pref with the name browser.bookmarks.file and set the value to the full path of the backup bookmarks.html file including the file name.

You can open the about:config page via the location/address bar. You can accept the warning and click "I'll be careful" to continue.

• http://kb.mozillazine.org/about:config

Yes this will work, but by having Firefox move the file to a backup location there will be just one file named bookmarks.html - the "latest" file sent there will overwrite the previous file with that name. From what I have seen happen, bookmarks.html won't be appended with -1 etc or provide a "date" as with Pike's Bookmark Backup extension from the olden days; unless this user only wants one "backup" saved and not serial backups.

cor-el said

Note that you can specify the full path of the bookmarks.html file.

• http://kb.mozillazine.org/browser.bookmarks.autoExportHTML

This HTML backup is created by default in the profile folder as bookmarks.html every time you close Firefox, but you can set the path and file name via the browser.bookmarks.file pref on the about:config page.

• http://kb.mozillazine.org/browser.bookmarks.file

The browser.bookmarks.file pref doesn't exist by default and you need to create a new String pref with the name browser.bookmarks.file and set the value to the full path of the backup bookmarks.html file including the file name. You can open the about:config page via the location/address bar. You can accept the warning and click "I'll be careful" to continue.

• http://kb.mozillazine.org/about:config

Toggling the browser.bookmarks.autoExportHTML setting within about:config did the trick. FF is now auto-exporting and updating the bookmarks.html file which the Seagate backup software is successfully copying without any issue; I specified the target backup address down to the file level, though I suspect this is an unnecessary precaution. While the result isn't the persistently up-to-date backup state I was initially looking for, it seems to be the most feasible option available, and rendering a newly updated version of the file at browser reboot gets the job done. Its certainly better than nothing.

Thanks to every one for the help, I greatly appreciate it. IMO it wouldn't be a bad idea activating this setting within FF by default, it seems to be a safe and simple way of ensuring an up-to-date iteration of the bookmarks library apart from places.sqlite is regularly backed up, and at apparently no cost other than the generation of a single extra file within the profile directory of negligible filesize.