Proper backup procedure

[Sean Sweeney]

After speaking to a few different red-saavy AC's and DIT's I'm noticing some discrepancy in how backups are done. Perhaps someone with a bit more experience can take a look at how I do things, and let me know how you might change it, or how you do your own backups.

When I backup I always:

-Plug the red-raid power cable in, regardless of my connection

-(now) use USB 2.0 after having the firewire 400/800 ports fail on one drive (this will hopefully be remedied soon after we ship the drive off to red)

-connect each of my two backup drives separately (no daisy chaining)

-for the copying of the camera files I always copy directly from the red drive to the backup media

-check that the files sizes match up

-when time is available, watch first and last proxies of each mag

Rinse and repeat. Is it absolutely necessary to copy from the red drive for each of the two backups, or is it possible to copy to backup drive A, and then from drive A to B. An AC warned me that this could pose problems.

Also, occasionaly the client wants to view some material while it's in the middle of a transfer - will any playback of proxies or the R3D tweaking in Red Alert affect the transfer? I haven't had this happen despite the client's insistence on viewing some material while the drive was transferring, but I'd like to know that if there's even the slightest risk, so I can change this.

Thanks!

 

[Matthew Rogers]

Just a question...why aren't you using a RAID-1 to back up data? It will be much faster on the backup and I feel your are less likely to miss a folder in all your copying.

Another tech around here actually watches all the takes for dropped frames. I see that being kinda pointless as Quicktime will drop frames just because it's having issues processing all of the data. I do think it's a good idea to scrub through all your proxies (just one proxy of each take) to make sure something horrible hasn't happened.

Another tech did show me a good idea for the camera op to know if a card shouldn't be formatted because the data didn't get copied off. When he's finished downloading the card and confirming that it copied correctly he goes into disk utility and formats it as FAT32. That way when the camera op sticks the card in, a card that's been downloaded and ready to use again the RED shouldn't complain about there being clips on the card and he can then format it.

Matthew

 

[Allan Chesher]

I would always plug the red raid into the fw800 of my macbook pro and since i use a dual FW800 PcExpess card it doesn't use internal power so i need to run AC for the backups drives.

-Run each copy from the original media. Not a copy of a copy.
-Also as a rule i never use USB 2.0, understandable since your Drive is broken and you dont have any readily available supply but if you could i would set it aside and mail it to red asap.
-I also understand the logic of checking your first and last clip but if there are issues in transfer it could be anywhere in within those individual files so i after comparing byte sizes of the original media and the copy, make sure theyre exact and number of files match too. Then to load all the media for that mag into redcine and scrub through all the clips as a brief spot check for drop frames.
-In regards to transferring and playing, i would never play back clips off the original media as im transferring it. 1. it increases the chances of it spasing out and crashing as you accessign the media from 2 different sources and it slows it all down to and unbearably slow playback speed. Better off to wait and watch it after transfer is complete and if there is an urgeancy to see the media then play it back off camera.
-If there are drop frames camera will know,
just remember to check all your backups

 

[Conrad Hunziker]

Heres how I set it up to work on "Manure", and all the other features Ive consulted with/worked on. It removes a lot of the human error that can happen:

- Hook red drive up via firewire 800

- Hook media drives via eSATA or other NON-firewire interface (san/nas/usb if you have to). Always at least 2 drives, and one of them is at least raid 1 (usually raid 5). The other is usually a shuttle drive to get data to post. I always use a non-firewire device because if you are reading and writing to the same bus, it takes roughly twice as long to complete the operation.

- Open the red drive in R3D Data Manager

- Select the destinations, if not already saved (each project / day gets its own folder)

- Hit copy. R3D Data Manager will do the copy to each destination and verify that each copy is valid. Just because its the same number of bytes doesnt mean its in the right order. It does this for every file on the drive.

- After copy, watch each clip - every take - from the copied RAID.

- Only after each take on the copied RAID is verified, I remove all takes on the red drive (select all, delete, empty trash). The drive then is available for new takes.

- On loading a fresh mag, the camera formats the red drive with the new drive number. No numbers are (hopefully) every re-used. And because the drive appeared to be empty, the camera didnt complain. If the drive was not empty, send it back - something is wrong.

On Manure, Eric Yu had his job cut out for him, running 2 cameras all the time, and sometimes up to 4. However, using the above practices ensured that no data was ever lost or misplaced - on our end at least (Post is another story).

 

[Conrad Hunziker]

Well, the issue with making a backup to drive B from drive A is that whatever errors might have landed on drive A are then simply duplicated on drive B, right? Just as with P2 transfers, I would suggest a transfer to drive A from the original media - then a transfer to drive B from the original media. It just gives you one more opportunity for a glitch free copy.

I just wanted to point out that using a checksum verification, you can copy from backup A to backup B, as long as you do a checksum verification on backup B.

So, with the R3D Data Manager creating a checksum of the r3d files from the source, your backup A will already have a complete checksum verification. Just select backup A as the source, and backup B as the destination. Or if you wish you could even do a OS level copy (i.e. finder copy) to backup B, then do a checksum verification with R3D Data Manager. However, by doing a OS level copy, you wont ensure that every file & folder made it over. R3D Data Manager does a check to ensure that each file in the source is also in the destination.

This way you can ensure that your backup B will not only have all the right bits, but also in the right order.

 

[Sean Sweeney]

Just a question...why aren't you using a RAID-1 to back up data? It will be much faster on the backup and I feel your are less likely to miss a folder in all your copying.

I work for a very small group of red owners, so unfortunately a lack of financial resources has us relying on a RAID 0 setup (a set of dual g-tech drives). In the future, however, I'd like to use something a bit more secure.

Where is this R3D data manager you're speaking of? We've been doing it the old fashioned way! I'm not the actual owner of the red I work for - is there a piece of software that they may have forgotten to include in my package that has this R3D manager?

 

[Eirik Tyrihjel]

Where is this R3D data manager you're speaking of? We've been doing it the old fashioned way! I'm not the actual owner of the red I work for - is there a piece of software that they may have forgotten to include in my package that has this R3D manager?

Google is your friend...

http://www.r3ddata.com/

 

[Sean Sweeney]

Wow - this is a handy piece of software! Gotta love 3rd party developers making the RED even better.

 

[David Wakeley]

Hi,
New to RedUser, as I've always found it hard to fight through the non essential to the essential. However, now I have a question: Loaded build 16, did some key green tests, ie: normal exp: one up: one down etc to find the best spot. The results, using the new Redspace, give wonderful flesh tones, but horrible fluro colours - the key green & some fluro pink tape we were using went very flat. Not using Redspace gives good fluro but magentaish unattractive flesh tones. Eventually the key was ok in Flame off Redspace, both using 3200k & 5600k light sources. The 5600k still better though but a bit worrying that you can't see a decent key green until Flame or other Post box.
Any thoughts on the new RedSpace & keying??
David Wakeley, Sydney.