लागत प्रभावी, वीडियो और छवि डेटा के दीर्घकालिक अभिलेखीय? ~ 50 टी.बी.


16

मेरी प्रयोगशाला एक छोटा सर्वर स्थापित करने की प्रक्रिया में है जो उस परियोजना के लिए डेटा (ज्यादातर वीडियो और छवि डेटा, प्लस कुछ दस्तावेज़) रखती है, जो हमारे समूह समय पर काम कर रहे हैं। ऐतिहासिक रूप से, एक शोध परियोजना के समाप्त होने के बाद, डेटा मुश्किल से एक हार्ड ड्राइव में संग्रहीत किया जाता है, या डीवीडी का एक बड़ा ढेर (या पुराने दिनों में सीडी), और / या कुछ वीडियो सोनी कैसेट या यहां तक ​​कि समाप्त हो गया वीएचएस टेप (यह लैब शुरुआती 90 के दशक से सक्रिय है), या उपरोक्त सभी का मिश्रण ...

प्रश्न: (1) उन सभी को एक ही प्रारूप और भंडारण माध्यम में समेकित करने का सबसे अच्छा तरीका क्या है, और (2) बहुत सामयिक पहुंच के लिए इस तरह के डेटा के दीर्घकालिक संग्रह के लिए सबसे अच्छा माध्यम क्या है (जैसे, 30+ वर्ष?)। दुर्भाग्य से हमारे पास उद्यम स्तर का बजट नहीं है (हम सिर्फ एक ~ 10 लोगों की प्रयोगशाला हैं), इसलिए उन चीजों को नहीं कर सकते जिनकी लागत हजारों डॉलर है।

धन्यवाद!

PS हमारे पुराने वीडियो और छवियों को ध्यान में रखते हुए छोटे रिज़ॉल्यूशन के हैं, लेकिन हाल ही में बहुत बड़े हैं, मुझे लगता है कि हम वास्तव में पुराने डेटा के लिए 30 ~ 40 टीबी के बारे में बात कर रहे हैं, हाल ही के डेटा के लिए एक और 10 ~ 20 टीबी, फिर लगभग 5 टीबी के वार्षिक जोड़ ।

जवाबों:


22

दुर्भाग्य से, आपके लिए कोई सबसे अच्छा तरीका नहीं है। डिजिटल मीडिया का 30 साल का अभिलेखागार एक बहुत कठिन समस्या है और नियमित निवेश लेता है। 30 वर्षों में पठनीय होने की गारंटी देने वाले एकमात्र प्रारूपों के बारे में ASCII और UTF8 हैं, जो वीडियो प्रारूप नहीं हैं। स्टोरेज फॉर्मेट बदलते हैं, 30 साल पहले हम जिस 8 ट्रैक रील-टू-रील टेप का इस्तेमाल कर रहे थे, वह इन दिनों पढ़ना बहुत मुश्किल है, हालांकि डेटा अभी भी टेप पर है (नासा द्वारा 40 साल पुराने टेप ड्राइव के पुनर्निर्माण के बारे में एक दिलचस्प कहानी है कुछ नए बरामद / खोजे गए अपोलो डेटा टेप) प्राप्त करने के लिए। आपका सबसे अच्छा दांव आवधिक के लिए प्रतिबद्ध है, मैं कहता हूं कि हर 5 साल में, आपके अभिलेखीय वातावरण का आकलन पर्याप्त बजट के साथ नए स्वरूपों में पुराने प्रारूप लाने के लिए होगा।

आप शायद मुझसे बेहतर जानते हैं, लेकिन वीडियो परिदृश्य तेजी से बदल रहा है। रीयलटाइम ऑनलाइन संपादन अब संभव है, जहां यह 10 साल पहले भी गंभीरता से अच्छी किट पर ही संभव था। कौन जानता है कि 30 साल बाद चीजें कैसे दिखेंगी।

  • 5 साल के लिए अपनी अभिलेखीय विंडो सेट करें।
    • तत्काल अवधि में एक लार्ज स्टोरेज ऐरे को पर्याप्त होना चाहिए (
      • बड़े और धीमे 50TB डिस्क $ 70K के तहत हो सकते हैं, संभवतः अच्छी तरह से।
      • एक LTO5 टेप ड्राइव और 50 टेप (अच्छी तरह से 50TB मूल्य से अधिक) $ 15K से कम के लिए हो सकते हैं।
  • आप अपने वीडियो को किस प्रारूप में संग्रहीत करते हैं, यह आपके ऊपर है।
  • अपने सभी पुराने सामान को इस नए संग्रहण में ढूंढना और परिवर्तित करना शुरू करें।
  • 5 साल के अंत में, अपने अभिलेखीय वातावरण का एक और पूर्ण मूल्यांकन करें।
    • आप किन स्वरूपों का उपयोग कर रहे हैं?
    • नए प्रारूप क्या हैं?
    • कोडेक्स क्या प्रतीत होता है कि डेड एंड्स हो जाते हैं, और आपने जो मीडिया स्टोर किया है, वह इस तरह से एन्कोडेड है?
    • तय करें कि आप नए संग्रहण तरीकों (डेटा प्रारूप, डिस्क / टेप / कुछ और) के लिए कैसे स्थानांतरित करने जा रहे हैं, और उचित रूप से खर्च करें।
  • 6 बार दोहराएं।

जो आपको 30 साल तक मिलनी चाहिए।


+1, यदि आप वास्तव में सस्ते होने की कोशिश कर रहे हैं, तो आप शायद हर 10 साल में ऐसा कर सकते हैं। एक दशक पहले एटीए -66 और 100 ड्राइव वरीयता के एचडी थे, और उन लोगों से जुड़ने के लिए अभी भी तकनीकें हैं। लेकिन पहले से ही ऐसे कंप्यूटर हैं जिनके पास IDE हेडर की कमी है, दशक पुरानी तकनीक iffy हो रही है।
क्रिस एस

6
कॉपी करने पर अच्छे अंक के लिए +1, लेकिन उस प्रारूप को दर्शाने के लिए -1 अपठनीय हो जाएगा। एक बार प्रतिलिपि योग्य माध्यम पर डेटा उपलब्ध होने के बाद, जब तक वे बहुत अजीब प्रारूप में नहीं होंगे, तब तक वे फाइलें अप्रयुक्त होने की संभावना नहीं हैं। MPEG2 जैसे कुछ बहुत मुख्यधारा में संग्रहित करना एक टिकाऊ प्रारूप होने की अत्यधिक संभावना है। हानिपूर्ण वीडियो ट्रांसकोडिंग एक हानिपूर्ण प्रक्रिया है। यह नहीं किया जाना चाहिए। यह हमारे बारे में कुछ भी खर्च नहीं करता है एक मुख्यधारा के वीडियो कोडेक के आसपास रखने के लिए ...
पॉल मैकमिलन

@Paul सुझावों के लिए धन्यवाद। पिछली बार जब मैं नियमित रूप से वीडियो लोगों के आसपास लटका था 7 साल पहले, इसलिए मैं कठोर हूं।
sysadmin1138

विस्तृत मूल्यांकन और सुझावों के लिए बहुत बहुत धन्यवाद! हम अपने दुर्भाग्य से सीमित आईटी बजट के साथ सबसे अच्छा करेंगे। इसलिए खुशी है कि आप सभी और serverfault.com यहां मदद के लिए मौजूद हैं।
15

हाँ, हमारे पास एक तरीका है। फिर भी, मुझे 3.1 दिनों की खिड़कियों से 17 वर्षीय AVI फ़ाइलों को चलाने में कोई समस्या नहीं है। चाल उन स्वरूपों को चुनने में निहित है जो पहले से ही व्यापक उपयोग में हैं।
पॉल मैकमिलन

11

मैं पूरी तरह से sysadmin1138 के पोस्ट के साथ हर तरह से सहमत हूं एक बार एक चेतावनी - मुझे नहीं लगता कि आप वास्तव में जो आप चाहते हैं उसे प्राप्त करने के लिए बजट है।

5 मुख्य कार्य हैं जिन्हें आपको बनाने की आवश्यकता है;

  • एक मानकीकृत सामग्री और कैटलॉग नीति - मुझे पता है कि आप सब कुछ एक प्रारूप में संग्रहीत करना चाहते हैं, लेकिन आपको वास्तव में दो पर विचार करना चाहिए - छवियों के लिए पीडीएफ और वीडियो के लिए H.264 - दोनों बहु-मंच कोड के साथ दीर्घकालिक-समर्थन प्रारूप हैं जो लगभग निश्चित रूप से एक पार्टी या किसी अन्य द्वारा उनके वर्तमान रूप में 25-50 वर्षों के लिए दुनिया भर में मौजूदा उपयोग के कारण समर्थन किया जाता है।
  • एक सूची या सीएमएस सामग्री को अनुक्रमित और प्रकाशित करने के लिए।
  • एक 'कंटेंट इनगैस्ट' प्रणाली - यह आपके सभी मीडिया, पैकेज, एनकोड, स्टोर को लेगी और सामग्री के प्रत्येक नए टुकड़े के लिए कैटलॉग को अपडेट करेगी। आपको एक मैन्युअल या स्वचालित सामग्री गुणवत्ता जांच की भी आवश्यकता होगी।
  • एक प्राथमिक सामग्री स्टोर - इसमें दो मुख्य स्टोरेज ब्लॉक होंगे; मूल सामग्री को रखने के लिए एक छोटा सा, जबकि ट्रांसकोड / चेक किया जा रहा है और सामग्री को 'पास' रखने के लिए एक बड़ा ब्लॉक है। यह RAID 6 के लिए एकमात्र वैध उपयोगों में से एक है जो मैं भर में आया हूं, लेकिन यहां 24x365 'कर्तव्य चक्र' वाले उद्यम गुणवत्ता डिस्क का उपयोग करने का प्रयास करें।
  • दीर्घकालिक बैकअप प्रणाली - यह वह जगह है जहाँ असली पैसा खर्च किया जाएगा, आपको एक विक्रेता का चयन करना होगा जो वास्तव में दीर्घकालिक बैकअप क्षमता प्रदान करता है। अगर मैं अभी यह कर रहा था, तो मैं अभी भी डेटा दीर्घायु कारणों के लिए विशुद्ध रूप से डिस्क पर टेप के साथ जाऊंगा, शायद आईबीएम द्वारा क्योंकि उनके पास इस क्षेत्र में बहुत अनुभव है। आपको यह भी विचार करने की आवश्यकता है कि आपको नियमित रूप से टेप पुनर्स्थापन और डेटा सत्यापन भी करने की आवश्यकता है, जिसका अर्थ है कि आपको कम से कम तीसरे भंडारण ब्लॉक की आवश्यकता होगी जो आपके पास सबसे बड़ा टेप है - और सिस्टम भी सत्यापित करने के लिए। उसके ऊपर आपको यह सुनिश्चित करना होगा कि आपके द्वारा उपयोग किया जाने वाला बैकअप सॉफ़्टवेयर भी लंबे समय तक बना रहेगा, कुछ TAR जैसे * nix पर थोड़ी देर के लिए रहने की संभावना है, लेकिन यह कार्यात्मक रूप से आपको वह नहीं दे सकता है जो आप चाहते हैं। यह सुनिश्चित करें कि आपके टेप विक्रेता द्वारा इसे अनदेखा नहीं किया गया है।

तो आप जो करना चाहते हैं वह किया जा सकता है, मैंने पिछले दो दशकों में कई बार खुद ऐसा किया है - लेकिन कोई भी सस्ता नहीं था मुझे डर है।

सौभाग्य।


छवियों के लिए पीडीएफ यह करने के लिए एक बहुत भयानक तरीका की तरह लगता है। हाँ दस्तावेज़ों के लिए बिल्कुल पीडीएफ, लेकिन छवियों को अपने आउटपुट प्रारूप के आधार पर झगड़ा या JPEGS के रूप में रखें। उन लोगों को पढ़ने की क्षमता दूर जाने की संभावना नहीं है।
पॉल मैकमिलन

सुझावों के लिए धन्यवाद! अगर मैं इसके लिए दो स्वीकृत उत्तरों को चिह्नित कर सकता / सकती हूं। :)
hpy

1
ठीक है, 1138, और कलियाँ हैं;)
चॉपर 3

2
ईमानदारी से, किसी भी तरह के सीएमएस सिस्टम के साथ कठिनाई यह है कि यह सिस्टम का पहला और सबसे पुराना हिस्सा होने की संभावना है। आपको लगभग सभी बुनियादी विवरणों के साथ ASCII पाठ फ़ाइल लिखने और इसे अपने कच्चे डेटा के साथ संग्रहीत करने की आवश्यकता होगी। कोई भी CMS या स्वचालित प्रणाली कुछ वर्षों के पैमाने पर पुरानी होने जा रही है।
पॉल मैकमिलन

3

दूसरों ने आपके मीडिया का बैकअप लेने के बारे में अच्छी सलाह दी है। मेरा सुझाव होगा कि आप कांग्रेस के दिशानिर्देशों की लाइब्रेरी को देखते हुए कुछ गुणवत्ता समय व्यतीत करें:

http://www.digitalpreservation.gov/formats/index.shtml

आप एक सस्ते व्हाइटबॉक्स ZFS सरणी के निर्माण पर भी विचार कर सकते हैं। आप शायद $ 10k के तहत अपनी आवश्यकताओं को पूरा करने के लिए कुछ कर सकते हैं। जैसे ही ड्राइव मर जाते हैं, उन्हें बड़े लोगों के साथ बदल दें, और जैसे ही आप डेटा बनाते हैं, आपकी भंडारण क्षमता बढ़ती है। यह संभवतः आपको काफी समय तक जारी रखेगा, और जब आप बूढ़े हो जाएंगे तो आप इसे उच्च क्षमता वाले डिवाइस से बदल सकते हैं। लाभ यह है कि आपका डेटा ऑनलाइन है (और इसलिए इसे आवश्यक रूप से एक्सेस किया जा सकता है), और बिट्रोट के खिलाफ अपेक्षाकृत अच्छी तरह से संरक्षित है, एक गंभीर समस्या जब आपके पास यह डेटा है।

एक सभ्य निर्माण विकल्प यहाँ एक साथ रखा गया था:

http://www.zfsbuild.com/


2

टेक्नोलॉजिस्ट के लिए जितना मुश्किल है, मैं डिस्क और तकनीक के बारे में तुरंत विचार रोकने की सलाह दूंगा। अपनी व्यावसायिक समस्या को उन चीजों में तोड़ दें जिनके बारे में आपको निर्णय लेना है।

उदाहरण:

  • आप एनालॉग / विविध डिजिटल टेप प्रारूपों को डिजिटल मीडिया में परिवर्तित करने से कैसे निपटने जा रहे हैं जो किसी प्रकार के डिजिटल स्टोरेज पर संग्रहीत किए जा सकते हैं?
  • आप सामग्री और संबंधित मेटाडेटा का प्रबंधन कैसे कर रहे हैं? भंडारण आसान है - आप एलटीओ टेप पर सब कुछ डाल सकते हैं और इसे एक पुरानी नमक की खान में संग्रहीत कर सकते हैं, लेकिन आपके पास डेटा तक पहुंच नहीं होगी।
  • क्या आप पहिए का फिर से आविष्कार कर रहे हैं? यदि आप विश्वविद्यालय में हैं, तो क्या केंद्र में पहले से ही सामग्री प्रबंधन के लिए समाधान उपलब्ध हैं? या अगर आपको अपनी सामग्री प्रबंधन खरीदने / बनाने की आवश्यकता है, तो क्या केंद्रीयकृत बुनियादी ढाँचा है जिसे आप एक टुकड़ा खरीद सकते हैं? (टेप, ऑब्जेक्ट स्टोरेज, सैन)
  • वास्तविक व्यावसायिक आवश्यकताएं क्या हैं? आप वास्तव में क्या रखना चाहते हैं और क्यों? जब आप वास्तव में मामले के दिल में खोदते हैं, तो वास्तविक दीर्घकालिक अवधारण आवश्यकताएं वास्तव में केवल डेटा के एक छोटे उपसमुच्चय पर लागू होती हैं।

1

इस बात से अवगत रहें कि यदि आप डेटा को एक हानिपूर्ण प्रारूप में संग्रहीत करते हैं, और फिर एक और हानिपूर्ण प्रारूप में परिवर्तित करते हैं, और फिर दूसरे, आपके वीडियो की गुणवत्ता प्रत्येक संक्रमण से कम हो जाएगी।

निम्नलिखित ऑडियो के बारे में बात कर रहा है, लेकिन समान रूप से लागू होता है:

आप किसी भी ऑडियो प्रारूप को ऑग वॉर्बिस में बदल सकते हैं। हालाँकि, एक हानिपूर्ण प्रारूप से, एमपी 3 की तरह, दूसरे हानिपूर्ण प्रारूप में, वोरबिस की तरह परिवर्तित करना, आमतौर पर एक बुरा विचार है। एमपी 3 और वॉर्बिस एनकोडर दोनों ऑडियो तरंग के कुछ हिस्सों को फेंककर उच्च संपीड़न अनुपात प्राप्त करते हैं जो आप शायद नहीं सुनेंगे। हालांकि, एमपी 3 और वोरबिस कोडेक्स बहुत अलग हैं, इसलिए वे प्रत्येक को ऑडियो के अलग-अलग हिस्सों को फेंक देंगे, हालांकि निश्चित रूप से कुछ ओवरलैप हैं। एक Vorbis के लिए एक एमपी 3 परिवर्तित करने में WAV की तरह एक असम्पीडित प्रारूप में एमपी 3 फ़ाइल को डिकोड करना शामिल है, और Ogg Vorbis एनकोडर का उपयोग करके इसे फिर से जोड़ना। डिकोडेड एमपी 3 मूल ऑडियो के उन हिस्सों को याद कर रहा होगा जिन्हें एमपी 3 एनकोडर ने त्यागने के लिए चुना था। Ogg Vorbis एनकोडर तब अन्य ऑडियो घटकों को त्याग देगा जब यह डेटा को संपीड़ित करता है। सबसे अच्छे रूप में, परिणाम एक ओग फ़ाइल होगी जो आपके मूल एमपी 3 के समान लगती है, लेकिन यह सबसे अधिक संभावना है कि परिणामस्वरूप फ़ाइल आपके मूल एमपी 3 की तुलना में खराब हो जाएगी। किसी भी स्थिति में आपको मूल एमपी की तुलना में बेहतर लगने वाली फ़ाइल नहीं मिलेगी।

चूंकि कई संगीत खिलाड़ी एमपी 3 और ओग दोनों फ़ाइलों को खेल सकते हैं, इसलिए कोई कारण नहीं है कि आपको अपनी सभी फ़ाइलों को एक प्रारूप या दूसरे में बदलना होगा। यदि आपको Ogg Vorbis पसंद है, तो हम आपको इसका उपयोग करने के लिए प्रोत्साहित करेंगे जब आप मूल, दोषरहित ऑडियो स्रोतों (CDs की तरह) से एन्कोड करेंगे। जब मूल से एन्कोडिंग होती है, तो आप पाएंगे कि आप अपने एमपी 3 की तुलना में ओग फाइलों को बेहतर या बेहतर गुणवत्ता (या दोनों) बना सकते हैं।

(यदि आपको एमपी 3 से ऑग में पूर्ण रूप से परिवर्तित होना चाहिए, तो फ्रेशमेट पर कई रूपांतरण स्क्रिप्ट उपलब्ध हैं।)

http://www.vorbis.com/faq/#transcode

इसलिए संभवतः दोषरहित प्रारूप चुनना सबसे अच्छा है, क्योंकि एक बार जब आप एक हानिपूर्ण प्रारूप चुन लेते हैं, तो आप इसके साथ फंस जाते हैं।


3
दोषरहित वीडियो वर्तमान में संग्रहीत करने के लिए व्यावहारिक नहीं है। फुटेज के प्रति मिनट गिग्स को संग्रहित करना बहुत महंगा है। एक हानिपूर्ण कोडेक चुनें, जो अब आप व्यापक उपयोग में है, और इसमें अपने मीडिया को छोड़ दें।
पॉल मैकमिलन

दोषरहित-नेस के बारे में अच्छी बात के लिए धन्यवाद, हम निश्चित रूप से इस बारे में कठिन सोचेंगे।
hpy

1

शायद ऐसा कुछ है जो मुझे याद आ रहा है, क्या आप एक खुले प्रारूप का उपयोग करके सब कुछ सांकेतिक शब्दों में बदलना नहीं कर सकते हैं जहां कोडेक्स के लिए स्रोत कोड उपलब्ध है, और फिर अमेज़ॅन एस 3 पर यह सब छड़ी?

इस तरह से अमेज़ॅन को डेटा के वास्तविक भंडारण के बारे में चिंता करना पड़ता है, और, जब तक कि कोई कंप्यूटर नहीं है जो 30 वर्षों में C / C ++ को संकलित कर सकता है, तो आप जानकारी प्राप्त करने में सक्षम होंगे ...

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.