I’m backing up my data to both an external hard drive (via Chronosync) and an online service (Rackspace via Jungle Disk).
In addition to backing up data, both backup processes are configured to keep archives of older versions of my data files.
To my relief, the latest Scrivener backed up files are readable after transferring the data from either backup location to my desktop.
To my surprise, archived versions of my Scrivener data files at both backup locations fail to open properly after transferring them to my desktop. Thus, I have two independent backup processes that both fail to make usable archived versions of Scrivener data files.
Is this a Scrivener problem, a backup software problem, or one of those dumb user problems? Could there be some characteristic of data packages that has something to do with this?
When you say that they fail to open properly, what exactly happens? Is there an error message or some other problem? Are these files zipped up or regular .scriv files? Do those backup processes use incremental backups (which may only copy partial projects)?
All the best,
When archived versions are transferred from their backup location to my desktop, I get different error messages, depending on the backup source.
I’m not compressing any files, so its .scriv files that are being transferred back to my desktop.
I am certain that Chronosync is not doing incremental backups. It is supposed to be creating a synchronized copy of the file on my external hard drive. When a newer version comes along, it is supposed to be moving the older version from a backup location to an archive location.
As for Jungle Disk, I’m reasonably sure, but not 100% certain, that it is not doing incremental backups. If I find out that it is, and incremental backups are a problem, then I can easily avoid the incremental backup process.
Regarding error messages, for a file named Main.scriv:
From the online Rackspace source, I get two error messages. The first message says: “Project not found, no project could be found at the specified path.” When I press OK on that dialog box, another message appears: " The document “Main.scriv” could not be opened, no valid project could be found at the specified path."
From my external hard drive, though I’m not at my external hard drive and can’t currently give the exact error messages, the problem goes something like this: When I attempt to open the file, I get an error message about the file being a version that is not supported. Scrivener proceeds to make its own backup copy, which has the name old in it. I attempt to open the “new” file, but that also fails. To give you the exact error message, I will need to reproduce the error when I have access to my external hard drive.
Both of those errors indicate that certain crucial files are missing from the project package. .scriv files are package files, which are essentially folders as far as sync and backup software is concerned. The “project not found” error indicates that the main binder structure file (binder.scrivproj) is missing from within the .scriv package. The “update” message indicates that the info.plist file is missing from inside the .scriv package.
So in both cases, it seems that the backup software is not archiving the whole project - it may only be copying files it believes have changed. How does it behave when backing up folders? If they only backup changed files within a folder, and store each as individual snapshots, then my guess is that the .scriv files you are trying to open are incomplete snapshots. You may need to change the settings of your backup software to backup all files inside a .scriv file every time it backs them up (if that is possible), or start backing up .scriv files as .zip files.
This sticky thread should have some useful info, too:
All the best,
Ah, it makes sense both of my backup programs are set up such that archiving changed files may corrupt Scrivener packages.
The referenced sticky thread was informative and helpful with it’s suggestion to make zipped Scrivener backed up projects, and then back these up to other media.
It would be nice if I could just schedule backups/archiving to run automatically, and then not think about backup schedules any more. That’s what I was doing. Now I see that there needs to be an additional small manual PITA step to avoid corrupting packages.
Hopefully, I can reconfigure Chronosync to treat packages as single entities. If yes, then the need to manually back up and zip Scrivener projects will go away. I also have an inquiry with Jungle Disk to see if they have the means to secure the integrity of packaged files.
Thanks again for your support.
Glad that helped. This does seem to be a general issue with synchronisation programs and package files. I have it on my list to investigate these issues more thoroughly, although I don’t really want to try to provide my own synchronisation features within Scrivener, as that would open up a massive area of support issues in itself. Scrivener 2.0 will add an automatic backup feature though, in which it can be set to zip up and backup projects automatically upon open or close, which should take some of the pain out of it, at least.
Thanks and all the best,
I did a little more investigating of both Chronosync and Jungle Disk.
There is an option to either dissect package files or not. The default setting is to not dissect packages. This is good. I made a small test scrivener file, backed it up with Chronosync set to not dissect packages, modified the Scrivener file, and backed it up again. That created an archived version of the original file. I transferred the archived version back to my desktop and it was fully functional. When the Chronosync option is set to dissect packages, the Scrivener archived packages become corrupt. So, we have an easy solution to successfully archive Scrivener packages via Chronosync.
Using their backup software, I was not able to archive files and keep packages intact. They are implementing a new backup system, which I did not test. However, the beauty of Jungle Disk is that it provides webDAV access to online storage. This means that I can use Chronosync or any other third party backup software to store files online instead of using the Jungle Disk backup software.
Going forward with Jungle Disk & Rackspace, I have created a password protected disk image that is stored at Rackspace. I will be using Chronosync to securely back up and archive my files on the disk image at Rackspace.
Given the current lack of confidence in using backup/synchronization programs to store Scrivener packages, it still makes sense to create and back up Scrivener zip files, but I now have greater confidence that Chronosync is configured by default to respect the integrity of packaged files.
This is just an update on my experience retrieving archived Scriv packages.
Given the general concern about Scriv packages not being backed up/synchronized properly, I tested the latest Jungle Disk vault system for backing up files. I also tested the use Chronosync to back up to a disk image stored on a Jungle Disk network drive via webDAV.
Using the Jungle Disk vault system I was able to successfully retrieve archived scriv package files. It appears that Jungle Disk has solved the backup problem associated with scriv packages.
As a backup strategy, I had hoped to put a disk image on the Jungle Disk network drive, and then back up to the online disk image using Chronosync. While testing this setup, I discovered that there is a problem with Apple’s implementation of WebDAV, making it impractical to store dynamic large disk images online. Chronosync may still be used to successfully back up scriv packages to mounted drives (provided that Chronosync is configured not to dissect packages), but online disk images are not currently practical to use as backup locations.