Backup :: NON Scrivener ?

Scrivener Scrivener for macOS
1

As I approach the end of my first book I have become slightly more concerned about backups of my work, however good or bad it may be :confused:

I am WELL covered in terms of Scrivener backups. I have the project on Dropbox 100% of the time. I also have Time Machine and a weekly SuperDuper.

However I am concerned slightly about “file corruption” after a critical file that a writer friend of mine was working on, became corrupt (not a scrivener file I must add). His backup file also became corrupt and he lost 6 months work


Am I right in thinking that a Compile to ‘plain text’ would be the way to go to output a simple text version of the whole book ? Would it include any formatting ? gaps between documents/chapters ? Does it output to one single txt file of the Project ? How would one deal with non project docs, research, Doc notes etc. ?

2

You can compile to many formats, if that is what you want to do to be extra sure of keeping the files. Plain text will wipe out any bold, italic, underline, and so on, formatting. You might find rtf is a better choice. But there is also html, odt, word doc, docx, and so on


You should also look into sync. Set up sync with external folder (either as plain text or rtf exporting) and have that take place whenever you close the project. I think you can also sync non-draft files.

Your research files you can treat in a number of ways. If they are capable of being converted to Scrivener text, you can bring them into your draft (at the end). They will then surely be subject to the Sync like any other part of your draft, or you can include them in your compile. But you can also export the research files if they cannot be converted - a sound recording, for example.

For research, much of what most of us gather comes from outside sources, and we don’t edit them much. So these research files can be saved outside your Scrivener project before you even bring them into Scrivener. That is: when you import that video file or PDF, the original stays where it was before you imported it. These files you already have.

I also recommend turning on automatic backups, as zip compressed files. Copy each of these onto other media.

If you plan on going straight from Scrivener into a publishable format, into Amazon Kindle or pdf for example, compile is a good way to go at the end of each day’s session, or at any particular milestone in the project. This gives you a non-Scriv backup that also tests how the work will look in that format.

Remember also that you can always right-click or control-click on a scrivener project in the Finder and “Show Package Contents” and copy out of the project the texts and files in their native format. But this is tricky unless you know what you are doing.

  • asotir
3

Thanks asotir. Yes rtf seems to be the best choice. You didn’t say anything about document comments but that is less important to me as the book approaches completion. I think you are right about Research to a point, but in my case I have several documents in research made up of notes that I took as I read through some reference books.
I use Keywords to maintain a master list of characters and locations, so I need to figure that one. A screen snap may be the simplest.

With all due respect to Scrivener, we have to also think beyond Scrivener. What if I choose to abandon scrivener and move to another app at some stage. What if, as I said in my original post, all of the backups become corrupt. And that is not an impossible situation. Yes of course if the book is successfully published, there will always be a copy on line :slight_smile:

I personally think that Scrivener could look at, just look at, this issue and consider automatically including an rtf file output in tandem with ‘save as’ backups.

4

If you are zip-compressing your scrivener backups, then the chance that something will corrupt all copies of a given part of your project are reduced considerably. Without compression, a program may erroneously (or maliciously) crawl through every file & folder on both your hard drive and your backup drive “fixing” something about your project that renders all or part of it unreadable. But in order for the same program to do that with a .zip compressed backup, it has to be able to open the zip file, extract the files, make the change, and replace the original .zip.

So, make sure your .zip compressed Scrivener backups are both in the cloud and in an easily accessible place in your Time Machine backups, and you should be as golden as you can be. The only guaranteed way to avoid destruction via computer issue though, is hard copy. I think it’s worth it to print a novel’s worth of work to paper at important milestones; you only have to keep one physical copy if space is an issue.

5

The File/Export/Files
 command is designed to be something useful for making large-scale backups. If you select your entire Binder, and enable most or all of the optional checkboxes, you’ll have a lot of data organised into folders in approximation of the Binder hierarchy. Follow this up with a simple compile of the Draft folder so you have a copy of the manuscript that is put together rather than in a bunch of small pieces (like file export will do), and you should be golden.

For one thing, I’m not sure if you meant it literally, but I wouldn’t recommend using Save As for making backups because that moves you to the new project. It is usually better to use File/Back Up/Back Up To
 which is very similar to Save As, except that it has an automatic zip compression option (which you should use if you can), and it doesn’t move you from the current working project—you stay in that one spot, the backup is the copy. I find it a little less confusing to work that way than a trail of Save As versions. Whatever works best for you though!

As for compiling as a part of the backup process, I’m not sure how helpful that would be in all cases. Consider that compiling can take quite a while in a larger project. It could extend backup times (and that means how long it takes to shut down the software, especially if you have multiple projects open) considerably. Additionally, there is no guarantee that the user’s current compile settings will result in anything useful at all. One might have last used the compiler with the “Current Selection” compile group set, or collection, or a filter that is removing 75% of the items from the Draft. We could make some assumptions and use a more thorough set of temporary compile settings, but then that might make a huge mess of some people’s projects, who interleave notes and old revisions with their current manuscript text, directly in the Draft. Then there are cases where people are using Scrivener to author long technical documents, like XML, HTML, LaTeX and even Markdown variants—an RTF “backup” would be next to useless.

Really, we need you to compile. :slight_smile: Only you know how that is supposed to be done with the project at hand.

6

Keep in mind too that Scrivener’s project format is already quite open. Right-clicking on a Scrivener file will allow you to “Show Package Contents”, whence you can access all your project’s binder documents. Each text document is an RTF file; synopses are plain-text files; other media types are saved in their original format. So all of this is already accessible to you should you decide to stop using Scrivener at some point down the road.

We never recommend you open these files directly in another program while you do want to handle the project in Scrivener, because doing so could corrupt the project as a whole by getting files out of sync, and because there are some special tweaks that Scrivener makes for including inline annotations and so forth which will be lost opening in another program, saving, and returning to Scrivener. But in the emergency situation you’re describing, these files are there for rescue. :slight_smile:

7

MimeticMouton - I am sure you know more than me about this stuff but if the file is corrupted I doubt if it will open in Show Package. Whereas a corrupted RTF is a lot more likely to be readable with something.

Just to let anyone know that is interested.

I Compiled my Manuscript folder to RTF and it comes out excellently. Exactly what I want as a parallel file type backup.

Thanks Guys.

8

I agree with Robert:
the only safe way to back up Scrivener projects
Is with the zip-compression option,

9

Sorry Druid, no offence, but that wasn’t really the topic.

10

A Scrivener project is a folder of multiple files; as such, you always get the option to “Show Package Contents” when right-clicking it in the Finder. In the event that the project is corrupted and Scrivener cannot open it or can’t load all the files properly, e.g. because files are out of sync or some files are missing, using the “Show Package Contents” option to access the individual RTF files within the project folder can be useful. If all those RTF files are themselves corrupted, then no, that won’t help you, any more than having compiled them all to RTF would help you if that RTF became corrupted.

I was just addressing your suggestion that Scrivener should regularly save an RTF version of your work as part of your project backups by pointing out that the files are already saved as RTFs within the project backup, because the project package in the backup contains all the files in RTF form.

11

In a slight corollary 


I am sure someone who is using Scrivener will produce a top class book that will sell big time and become famous, if they haven’t already.

What should a writer do to save his work product (side notes, research, comments etc) for ‘posterity’ ? In the way that such notes are prized and valued today ?

Will Scrivener ensure that the current file format will remain readable in five years time ? Has that question been considered by the development team ?

12

Most internal Scrivener files are in either .txt or .rtf format. Both already have long histories, and are used universally enough that format converters for them are likely to exist long into the future.

A few of the component files in a project are in XML format. They’re readable by any text editor, and designed to be self-documenting.

Imported non-text files stay in their original formats, and are as robust or as fragile as that format. HTML, again, can be read by any text editor. PDF is extremely widely used, although that is offset somewhat by it being under Adobe’s control.

Katherine

13

The age of the word processor has raised many questions along these lines. You might check various librarian and archivist groups to find something on best practices, if this is a personal concern.

I like pdf (the ISO standard, if possible the archivist pdf-x variant, and not the additional advances Adobe has created since these standards were formalized) since it is more ‘fixed’ if you will, and less editable. You might put all your research – everything that can go there – into a subfolder of your Drafts, and at the end of each writing session, or day, or milestone, Compile the whole to pdf. You would need to make sure that everything is compile-able though. This would only need to be done once in the case of a writer freezing for posterity the work in its state when she submits it for publication, or later when she submits the final, to-be-published, work.

  • asotir
14

Interesting question. How many people will really have the foresight (or conceit) to archive the kind of incidental information or ephemeral material that humanities academics currently rely on? Digital content is so easily deleted, or revised in a fashion that leaves no trace of its evolution.

15

That is the essence of my thoughts on this. My son recently showed me a scan that JK Rowling put on line of her hand drawn time-line for the characters in one of her HP books. It is a fascinating part of literary history now and a magical insight into how she dealt with this process.

But what of current writers like those of us using Scrivener ? I am unlikely to produce anything memorable myself but I am sure that with the advent of Scrivener and Storymill etc. there will be a tragic loss of the ‘process’ and as you say, the ephemeral material, that goes into writing a popular piece of writing. Not just for academics, but anyone who is fascinated by the creative process.

16

kewms - I don’t know if you realise how few writers know a tiny minutiae of the technicalities of what you are saying here 


17

Translation: The files that make up Scrivener projects can be opened and read by programs that have existed for decades, and will likely be readable for many decades to come. Even if Scrivener is wiped off the face of the earth, archivists will be able to piece together the contents of one’s scrivener project will relative ease, making such ‘historical’ data available to the rest of the world.

18

How come ? I have used many programs over the years and even when a later ‘version’ of that program comes out, it won’t open the old files unless they were ‘converted’.

I have many PSD files from the Photoshop program I used to own several years ago, but when I asked a tech expert what I could use to open them now he said there is no way I can open them without Photoshop.

19

I think the point being made by Robert and Kewms is that the file formats mostly used by Scriv (as outlined by Kewms) are so universally used that they will be supported for the foreseeable future. Any significant developments in file format are unlikely to cut off the readability of, say, .txt, .rtf or PDF without allowing a significant period of transition (i.e. format conversion).

Using programs that employ proprietary file formats (such as PSD - incidentally this might help: pcsupport.about.com/od/fileexten 
 d-file.htm) is more open to future problems as the program that uses the format may be abandoned or significantly altered. Evernote is another programme that employs a proprietary format, which can be very frustrating when trying to export notes.

A good aggregator program (such as Scriv, Devonthink, etc) will not apply a proprietary file format to files created within or imported. Thus you can easily export research files from a Scriv project in their original format, and export text files created within in a number of different formats. The chances of being unable to export a file from Scriv in a format that is unusable in any program won’t happen in our lifetime.

20

I must be using Scrivener wrong then. All of my Scrivener files are “.scriv” files and my Mac doesn’t have any program that will open them except Scrivener. And I have a LOT of programs.