Answers.Body: <p>My process is always to start from the recording media, move the files from recording media to a 12TB external RAID5 array with a utility that verifies the integrity of the transfer.  This is my long term working archive.  </p>
  
  <p>While I don't do this at this time, I'd recommend making periodic off-site backups of this array (either to a cloned array or to tape) to guard against loss of the entire RAID array.</p>
  
  <p>For actually working with the assets, I copy (not move) the files to an internal scratch SSD RAID0 array.  Upon completion or archiving of a project, I move only the project files and any newly created files that need to be stored to the RAID5 archive.  I then rename my scratch folder, verify the project works when loaded on the archive array and then delete the renamed folder (which should only contain copies of the master source files.)</p>
  
  <p>This protects against any corruption of original source files while editing and also minimizes the amount of data that I have to move off of the scratch disk.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2013-12-23T15:56:51.277Z
Answers.LastActivityDate: 2013-12-23T15:56:51.277Z
Answers.UserDisplayName: AJ Henderson
Body: <p>We've had a video production studio for about 6 months, and we're revisiting how we should back-up/archive our client files and in general what our workflow should be with about a 8K limit on hardware.  We've sketched out a couple options for what hardware and procedures we're using.</p>
  <p>Here is one:</p>
  <ol>
  <li>Transfer RAW footage (we're shooting DSLR) to portable bus
  powered HD</li>
  <li>Import RAW footage into FCPX using Ext. Drive for
  Scratch Disk (here we have RAW footage and FCPX project files
  separated) Step</li>
  <li>Delete SD Cards</li>
  </ol>
  <p>EDIT Footage</p>
  <ol start="4">
  <li><p>Move FCP Projects files to RAID &amp; Delete bus powered HD that had raw footage
  Step</p>
  </li>
  <li><p>Delete Scratch Disks</p>
  <p><img src="https://i.sstatic.net/LfELF.png" alt="breakdown of example" /></p>
  </li>
  </ol>
  <p>Here is possibly another option:</p>
  <ol>
  <li>Transfer RAW footage to Scratch Drives</li>
  <li>Copy RAW Footage to RAID</li>
  <li>Delete SD Cards</li>
  </ol>
  <p>EDIT Footage Step</p>
  <ol start="4">
  <li>Move FCP Projects files to RAID</li>
  <li>Delete Scratch Disks</li>
  </ol>
  <p><img src="https://i.sstatic.net/9dZBP.png" alt="enter image description here" /></p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2013-12-09T14:08:48.013Z
Comments.Text: We go straight from SD cards into the raid, then edit from our various terminals across the network.  Raw footage and finished projects all stay on the raid, and that gets a nightly off site backup to an identical raid via carbon copy cloner.  Why do you have so many disks in the chain?  SD to external disk to scratch sounds excessive to me, but maybe you have good reason?
Comments.UserDisplayName: Jason Conrad
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2013-12-09T14:51:31.490Z
Comments.Text: We have the external scratch TB for editing.  We don't want to use our internal HD b/c they are not large enough.  Do you edit off your RAID directly or do you transfer files to a scratch to edit?
Comments.UserDisplayName: zkidd
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2013-12-09T15:13:01.520Z
Comments.Text: For us, all of the media stays on the raid.  Whenever we start a new project, we create a sparse disk image to contain the new project (we do this, and all of the editing remotely from MBP retinas over gigabit ethernet)  For now, it works for us, but we'd like to upgrade to 10GBe soon.
Comments.UserDisplayName: Jason Conrad
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2013-12-10T01:19:48.763Z
Comments.Text: This seems to be a really technical question and I don't believe it is in the scope of this stack exchange website. You might try asking on the Information Security website because they would more likely know of appropriate ways to back up information.
Comments.UserDisplayName: Weylin Schreck
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2013-12-10T13:11:31.880Z
Comments.Text: @WeylinSchreck, This is certainly a technical question, but I do believe it is a good fit here.  The question is about the technical aspects of a production setup... work flows, etc.  While it may also be on topic elsewhere, there's no reason it can't find a good home here.
Comments.UserDisplayName: JoshP
Tags: <video-editor><post-production><production>
Title: How should we back-up our media files for our production studio
UserDisplayName: zkidd
ThreadText: # How should we back-up our media files for our production studio
  
  (Asked by: username_0 on 2013-12-09)
  
  We've had a video production studio for about 6 months, and we're revisiting how we should back-up/archive our client files and in general what our workflow should be with about a 8K limit on hardware. We've sketched out a couple options for what hardware and procedures we're using.
  
  Here is one:
  
  1. Transfer RAW footage (we're shooting DSLR) to portable bus
     powered HD
  2. Import RAW footage into FCPX using Ext. Drive for
     Scratch Disk (here we have RAW footage and FCPX project files
     separated) Step
  3. Delete SD Cards
  
  EDIT Footage
  
  4. Move FCP Projects files to RAID & Delete bus powered HD that had raw footage
     Step
  5. Delete Scratch Disks
  
     ![breakdown of example](https://i.sstatic.net/LfELF.png)
  
  Here is possibly another option:
  
  1. Transfer RAW footage to Scratch Drives
  2. Copy RAW Footage to RAID
  3. Delete SD Cards
  
  EDIT Footage Step
  
  4. Move FCP Projects files to RAID
  5. Delete Scratch Disks
  
  ![enter image description here](https://i.sstatic.net/9dZBP.png)
  
  **Tags:** video-editor, post-production, production
  
  > **Comments:**
  > **username_1**: We go straight from SD cards into the raid, then edit from our various terminals across the network.  Raw footage and finished projects all stay on the raid, and that gets a nightly off site backup to an identical raid via carbon copy cloner.  Why do you have so many disks in the chain?  SD to external disk to scratch sounds excessive to me, but maybe you have good reason?  
  > **username_0**: We have the external scratch TB for editing.  We don't want to use our internal HD b/c they are not large enough.  Do you edit off your RAID directly or do you transfer files to a scratch to edit?  
  > **username_1**: For us, all of the media stays on the raid.  Whenever we start a new project, we create a sparse disk image to contain the new project (we do this, and all of the editing remotely from MBP retinas over gigabit ethernet)  For now, it works for us, but we'd like to upgrade to 10GBe soon.  
  > **username_2**: This seems to be a really technical question and I don't believe it is in the scope of this stack exchange website. You might try asking on the Information Security website because they would more likely know of appropriate ways to back up information.  
  > **username_3**: @username_2, This is certainly a technical question, but I do believe it is a good fit here.  The question is about the technical aspects of a production setup... work flows, etc.  While it may also be on topic elsewhere, there's no reason it can't find a good home here.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_4 on 2013-12-23. Score: 1
  
  My process is always to start from the recording media, move the files from recording media to a 12TB external RAID5 array with a utility that verifies the integrity of the transfer. This is my long term working archive.
  
  While I don't do this at this time, I'd recommend making periodic off-site backups of this array (either to a cloned array or to tape) to guard against loss of the entire RAID array.
  
  For actually working with the assets, I copy (not move) the files to an internal scratch SSD RAID0 array. Upon completion or archiving of a project, I move only the project files and any newly created files that need to be stored to the RAID5 archive. I then rename my scratch folder, verify the project works when loaded on the archive array and then delete the renamed folder (which should only contain copies of the master source files.)
  
  This protects against any corruption of original source files while editing and also minimizes the amount of data that I have to move off of the scratch disk.
  
  
  ---
  
  