{"course":{"slug":"image-editing","title":"Editing an Image","url":"https://addaly.com/learn/image-editing","level":"beginner","track":"create"},"lesson":{"slug":"history-versions-and-backup","title":"The file you will need is the one from Tuesday","url":"https://addaly.com/learn/image-editing/history-versions-and-backup","position":18,"of":78,"minutes":8,"answer":"History dies when the document closes and a synced folder replicates your mistakes.","keyIdea":"History dies when the document closes and a synced folder replicates your mistakes, so the record that actually rescues a job is named versions on disk plus three copies on two kinds of media with one of them elsewhere."},"body":{"format":"markdown","text":"## History is not a safety net\n\nThe History panel holds a list of recent states you can step back through. In Photoshop the default is 50; each state on a large document can cost tens of megabytes of scratch space, which is why the number is not higher.\n\nThree things people assume about history that are wrong:\n\n**It is not saved with the file.** Close the document and the history is gone. Open it tomorrow and there is one state.\n\n**It is linear by default.** Step back five states, make a new edit, and the five you stepped over are destroyed. Photoshop offers *Allow Non-Linear History* in the History Options, which keeps them, at a cost in memory. It is off by default.\n\n**It fills up.** Paint fifty brushstrokes and the state you actually wanted has been pushed off the end.\n\n**Snapshots** partly fix this: click the camera icon and the current state is pinned, immune to the rolling window, until you close the document. Take one before any large irreversible operation. It still dies when the file closes.\n\nGIMP's undo history behaves similarly and is bounded by a memory setting in Preferences. Krita's is also memory-bounded and, unusually, it can be configured to survive a crash through its autosave and recovery system.\n\n> Figure: What survives, and for how long. Timeline: While the file is open, Fifty history states, linear by default. Step back five, make one edit, and those five are destroyed. Snapshots pin a state against the rolling window.; The moment you close it, History and snapshots are gone, including the snapshot you took before the irreversible operation. The document reopens with one state.; Every version you save, v01, v02, v03 on disk, zero-padded so v10 sorts after v02. Three a job: before anything destructive, before a client sees it, after they approve.; Up to about thirty days, A sync folder's own version history can still return Tuesday's file. It is a replica, not a backup: a deletion syncs, and so does a corruption.; For as long as you keep it, Three copies, two kinds of storage, one in another building. That covers the drive dying, the laptop being stolen, the flood, and deleting the wrong folder.. History is a convenience inside one session, not a record. The thing that actually rescues a job is a file on disk with a different name, and the thing that rescues the disk is a copy the live system cannot reach and overwrite.\n\n## Versions: the part that actually saves you\n\nThe reliable record is files on disk with different names.\n\nA naming convention that works and sorts correctly:\n\n```\nhoney-500ml_front_v01.psd\nhoney-500ml_front_v02.psd\nhoney-500ml_front_v03-client-notes.psd\nhoney-500ml_front_v03_APPROVED.psd\n```\n\nZero-padded numbers so `v10` does not sort before `v2`. A short reason attached to versions that are not routine. The word APPROVED, or FINAL, used once and never followed by FINAL2: if a revision comes after approval, it becomes v04.\n\nSave a new version at each of these moments: before a destructive operation you cannot undo later, before sending anything to a client, and after a client approves. Three saves a job, and every one of them has a specific future use.\n\nThe habit that costs the most when missed: **save a version before flattening.** Flatten is the one command that turns a working file into a picture, and it is a single keystroke away from Save.\n\n## Backups: three copies, two media, one elsewhere\n\nThe standard rule, and it is standard because it survives the four realistic failures.\n\n- **Three copies** of anything you cannot recreate.\n- **Two different kinds of storage**: the laptop and an external drive, not two folders on the same disk.\n- **One off site**: a different building, or a cloud account.\n\nThe four failures it covers: the drive dies, the laptop is stolen, the building floods, and you delete the wrong folder. Only the third is rare.\n\nFree tools do this well. `rsync -a --delete source/ destination/` mirrors a folder to an external drive in one line and runs in seconds on subsequent passes because it copies only what changed. On Windows, `robocopy /MIR` is the equivalent. Both are built in.\n\n## The trap in cloud sync\n\nA synced folder (Drive, Dropbox, OneDrive, iCloud) is **not a backup**. It is a replica. Delete a file, and the deletion syncs. Corrupt a file, and the corruption syncs. Ransomware encrypts a file, and the encryption syncs.\n\nWhat sync services do provide is **version history**, usually 30 days, which recovers the Tuesday file. Learn where that is in the service you use before you need it, because finding it during a crisis is a bad time to learn. And know its limit: 30 days is not an archive, and files removed from the sync folder eventually leave the version history too.\n\nA real backup is a copy the live system cannot reach and overwrite.\n\n## When a file will not open\n\nLarge layered files do occasionally corrupt: an interrupted save, a full disk, a flaky USB drive during a write.\n\n- **Do not save over it.** Copy the broken file somewhere else and work on the copy.\n- Try opening it in a different application. Photopea and GIMP both recover partially damaged PSDs that Photoshop refuses, because they are more tolerant of malformed sections.\n- Photoshop writes a flattened composite inside every PSD for compatibility with other software. If *Maximise Compatibility* was on when it was saved, another application can often pull that composite out even when the layer data is unreadable. That setting costs file size and buys you this. Leave it on.\n- Krita and GIMP both autosave recovery files; check the recovery prompt on next launch rather than dismissing it.\n\n## What none of this solves\n\nVersions and backups protect the file. They do not protect the *decision*. Six versions in, nobody can remember why v03 looked better than v05, and comparing them means opening both.\n\nThe cheap fix is a plain text file beside the images (`notes.txt`), with two lines per version saying what changed and what the client said. It takes fifteen seconds and it is the only part of this lesson that survives you leaving the job."},"check":{"question":"A designer keeps all working files in a cloud-synced folder and considers them backed up. On Thursday they accidentally flatten and save over a layered file, then close it. What is the realistic position?","options":[{"text":"The flattened save has synced everywhere, so the layered version is gone from every copy, but the service's file version history may still hold Wednesday's file for a limited window.","correct":true},{"text":"Sync services keep the most recent healthy version and reject a save that removes data, so the layered file is still the one stored remotely.","correct":false,"tempting":"Credits sync clients with content awareness they do not have: they replicate whatever bytes the application writes, with no notion of layers being lost."},{"text":"Reopening the file and using the History panel will step back past the flatten, because history is stored inside the document.","correct":false,"tempting":"Assumes history persists across a close, which is exactly the property it does not have in any of these editors."},{"text":"The layered data is still inside the file because a flatten only hides the layers, so unflattening restores them.","correct":false,"tempting":"Imagines flatten as a view toggle: it composites the layers into one and discards them, which is why it is one of the few commands worth saving a version before."}]},"prev":{"slug":"channels-and-saved-selections","title":"The panel where selections go to live","url":"https://addaly.com/learn/image-editing/channels-and-saved-selections"},"next":{"slug":"setting-up-to-work-fast","title":"Eleven shortcuts and a scratch disk","url":"https://addaly.com/learn/image-editing/setting-up-to-work-fast"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The file you will need is the one from Tuesday', in Editing an Image. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/image-editing/history-versions-and-backup (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The file you will need is the one from Tuesday","courseTitle":"Editing an Image","module":{"index":2,"slug":"the-non-destructive-workshop","title":"The non-destructive workshop"},"answer":null,"keyIdea":"History dies when the document closes and a synced folder replicates your mistakes, so the record that actually rescues a job is named versions on disk plus three copies on two kinds of media with one of them elsewhere.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure","figure":{"type":"timeline","title":"What survives, and for how long","events":[{"when":"While the file is open","what":"Fifty history states, linear by default. Step back five, make one edit, and those five are destroyed. Snapshots pin a state against the rolling window."},{"when":"The moment you close it","what":"History and snapshots are gone, including the snapshot you took before the irreversible operation. The document reopens with one state."},{"when":"Every version you save","what":"v01, v02, v03 on disk, zero-padded so v10 sorts after v02. Three a job: before anything destructive, before a client sees it, after they approve."},{"when":"Up to about thirty days","what":"A sync folder’s own version history can still return Tuesday’s file. It is a replica, not a backup: a deletion syncs, and so does a corruption."},{"when":"For as long as you keep it","what":"Three copies, two kinds of storage, one in another building. That covers the drive dying, the laptop being stolen, the flood, and deleting the wrong folder."}],"caption":"History is a convenience inside one session, not a record. The thing that actually rescues a job is a file on disk with a different name, and the thing that rescues the disk is a copy the live system cannot reach and overwrite."},"alt":"Figure: What survives, and for how long. Timeline: While the file is open, Fifty history states, linear by default. Step back five, make one edit, and those five are destroyed. Snapshots pin a state against the rolling window.; The moment you close it, History and snapshots are gone, including the snapshot you took before the irreversible operation. The document reopens with one state.; Every version you save, v01, v02, v03 on disk, zero-padded so v10 sorts after v02. Three a job: before anything destructive, before a client sees it, after they approve.; Up to about thirty days, A sync folder’s own version history can still return Tuesday’s file. It is a replica, not a backup: a deletion syncs, and so does a corruption.; For as long as you keep it, Three copies, two kinds of storage, one in another building. That covers the drive dying, the laptop being stolen, the flood, and deleting the wrong folder.. History is a convenience inside one session, not a record. The thing that actually rescues a job is a file on disk with a different name, and the thing that rescues the disk is a copy the live system cannot reach and overwrite."}},"blocks":[{"t":"h2","id":"history-is-not-a-safety-net","runs":[{"text":"History is not a safety net"}]},{"t":"p","runs":[{"text":"The History panel holds a list of recent states you can step back through. In Photoshop the default is 50; each state on a large document can cost tens of megabytes of scratch space, which is why the number is not higher."}]},{"t":"p","runs":[{"text":"Three things people assume about history that are wrong:"}]},{"t":"p","runs":[{"text":"It is not saved with the file.","b":true},{"text":" Close the document and the history is gone. Open it tomorrow and there is one state."}]},{"t":"p","runs":[{"text":"It is linear by default.","b":true},{"text":" Step back five states, make a new edit, and the five you stepped over are destroyed. Photoshop offers "},{"text":"Allow Non-Linear History","i":true},{"text":" in the History Options, which keeps them, at a cost in memory. It is off by default."}]},{"t":"p","runs":[{"text":"It fills up.","b":true},{"text":" Paint fifty brushstrokes and the state you actually wanted has been pushed off the end."}]},{"t":"p","runs":[{"text":"Snapshots","b":true},{"text":" partly fix this: click the camera icon and the current state is pinned, immune to the rolling window, until you close the document. Take one before any large irreversible operation. It still dies when the file closes."}]},{"t":"p","runs":[{"text":"GIMP’s undo history behaves similarly and is bounded by a memory setting in Preferences. Krita’s is also memory-bounded and, unusually, it can be configured to survive a crash through its autosave and recovery system."}]},{"t":"h2","id":"versions-the-part-that-actually-saves-you","runs":[{"text":"Versions: the part that actually saves you"}]},{"t":"p","runs":[{"text":"The reliable record is files on disk with different names."}]},{"t":"p","runs":[{"text":"A naming convention that works and sorts correctly:"}]},{"t":"code","lang":"","label":"Text","text":"honey-500ml_front_v01.psd\nhoney-500ml_front_v02.psd\nhoney-500ml_front_v03-client-notes.psd\nhoney-500ml_front_v03_APPROVED.psd"},{"t":"p","runs":[{"text":"Zero-padded numbers so "},{"text":"v10","code":true},{"text":" does not sort before "},{"text":"v2","code":true},{"text":". A short reason attached to versions that are not routine. The word APPROVED, or FINAL, used once and never followed by FINAL2: if a revision comes after approval, it becomes v04."}]},{"t":"p","runs":[{"text":"Save a new version at each of these moments: before a destructive operation you cannot undo later, before sending anything to a client, and after a client approves. Three saves a job, and every one of them has a specific future use."}]},{"t":"p","runs":[{"text":"The habit that costs the most when missed: "},{"text":"save a version before flattening.","b":true},{"text":" Flatten is the one command that turns a working file into a picture, and it is a single keystroke away from Save."}]},{"t":"h2","id":"backups-three-copies-two-media-one-elsewhere","runs":[{"text":"Backups: three copies, two media, one elsewhere"}]},{"t":"p","runs":[{"text":"The standard rule, and it is standard because it survives the four realistic failures."}]},{"t":"ul","items":[[{"text":"Three copies","b":true},{"text":" of anything you cannot recreate."}],[{"text":"Two different kinds of storage","b":true},{"text":": the laptop and an external drive, not two folders on the same disk."}],[{"text":"One off site","b":true},{"text":": a different building, or a cloud account."}]]},{"t":"p","runs":[{"text":"The four failures it covers: the drive dies, the laptop is stolen, the building floods, and you delete the wrong folder. Only the third is rare."}]},{"t":"p","runs":[{"text":"Free tools do this well. "},{"text":"rsync -a --delete source/ destination/","code":true},{"text":" mirrors a folder to an external drive in one line and runs in seconds on subsequent passes because it copies only what changed. On Windows, "},{"text":"robocopy /MIR","code":true},{"text":" is the equivalent. Both are built in."}]},{"t":"h2","id":"the-trap-in-cloud-sync","runs":[{"text":"The trap in cloud sync"}]},{"t":"p","runs":[{"text":"A synced folder (Drive, Dropbox, OneDrive, iCloud) is "},{"text":"not a backup","b":true},{"text":". It is a replica. Delete a file, and the deletion syncs. Corrupt a file, and the corruption syncs. Ransomware encrypts a file, and the encryption syncs."}]},{"t":"p","runs":[{"text":"What sync services do provide is "},{"text":"version history","b":true},{"text":", usually 30 days, which recovers the Tuesday file. Learn where that is in the service you use before you need it, because finding it during a crisis is a bad time to learn. And know its limit: 30 days is not an archive, and files removed from the sync folder eventually leave the version history too."}]},{"t":"p","runs":[{"text":"A real backup is a copy the live system cannot reach and overwrite."}]},{"t":"h2","id":"when-a-file-will-not-open","runs":[{"text":"When a file will not open"}]},{"t":"p","runs":[{"text":"Large layered files do occasionally corrupt: an interrupted save, a full disk, a flaky USB drive during a write."}]},{"t":"ul","items":[[{"text":"Do not save over it.","b":true},{"text":" Copy the broken file somewhere else and work on the copy."}],[{"text":"Try opening it in a different application. Photopea and GIMP both recover partially damaged PSDs that Photoshop refuses, because they are more tolerant of malformed sections."}],[{"text":"Photoshop writes a flattened composite inside every PSD for compatibility with other software. If "},{"text":"Maximise Compatibility","i":true},{"text":" was on when it was saved, another application can often pull that composite out even when the layer data is unreadable. That setting costs file size and buys you this. Leave it on."}],[{"text":"Krita and GIMP both autosave recovery files; check the recovery prompt on next launch rather than dismissing it."}]]},{"t":"h2","id":"what-none-of-this-solves","runs":[{"text":"What none of this solves"}]},{"t":"p","runs":[{"text":"Versions and backups protect the file. They do not protect the "},{"text":"decision","i":true},{"text":". Six versions in, nobody can remember why v03 looked better than v05, and comparing them means opening both."}]},{"t":"p","runs":[{"text":"The cheap fix is a plain text file beside the images ("},{"text":"notes.txt","code":true},{"text":"), with two lines per version saying what changed and what the client said. It takes fifteen seconds and it is the only part of this lesson that survives you leaving the job."}]}],"check":{"question":[{"text":"A designer keeps all working files in a cloud-synced folder and considers them backed up. On Thursday they accidentally flatten and save over a layered file, then close it. What is the realistic position?"}],"options":[{"text":[{"text":"The flattened save has synced everywhere, so the layered version is gone from every copy, but the service’s file version history may still hold Wednesday’s file for a limited window."}],"correct":true,"tempting":null},{"text":[{"text":"Sync services keep the most recent healthy version and reject a save that removes data, so the layered file is still the one stored remotely."}],"correct":false,"tempting":[{"text":"Credits sync clients with content awareness they do not have: they replicate whatever bytes the application writes, with no notion of layers being lost."}]},{"text":[{"text":"Reopening the file and using the History panel will step back past the flatten, because history is stored inside the document."}],"correct":false,"tempting":[{"text":"Assumes history persists across a close, which is exactly the property it does not have in any of these editors."}]},{"text":[{"text":"The layered data is still inside the file because a flatten only hides the layers, so unflattening restores them."}],"correct":false,"tempting":[{"text":"Imagines flatten as a view toggle: it composites the layers into one and discards them, which is why it is one of the few commands worth saving a version before."}]}],"order":[2,0,1,3],"why":null},"prev":{"slug":"channels-and-saved-selections","title":"The panel where selections go to live","minutes":9},"next":{"slug":"setting-up-to-work-fast","title":"Eleven shortcuts and a scratch disk","minutes":8}}}