ध्यान दें: (late 2024) यह डॉक पेज बहुत ही पुराना है, लेकिन अभी भी कुछ मान होना चाहिए - विशेष रूप से यदि TKLBAM बैकअप को काफी नया TurnKey संस्करण में माइग्रेट करना है।

कृपया देखें TKLBAM docs अधिक सामान्य और अप करने के लिए तारीख TKLBAM जानकारी। देखें समर्थन प्राप्त करना यदि आपको अधिक अनुरूप और मौजूदा समर्थन की आवश्यकता है तो विकल्प और जानकारी के लिए पृष्ठ।

पिछले संस्करणों से Debian Jessie (What TurnKey Linux v14.x पर आधारित है) में कुछ महत्वपूर्ण बदलाव हुए हैं। इस पृष्ठ का उद्देश्य एक सामान्य अवलोकन और कुछ सामान्य मुद्दों पर कुछ जानकारी प्रदान करना है। यह थकावट नहीं है और आप अन्य मुद्दों का अच्छी तरह से सामना कर सकते हैं।

यदि TKL के पहले संस्करण से v14.x में माइग्रेट होने के बाद आपके पास अजीब चीजें होती हैं तो कृपया पोस्ट करें समर्थन मंच यदि आप ASAP की मदद करने की कोशिश करेंगे तो भी यदि आप एक हैं हब उपयोगकर्ता (or) AWS मार्केटप्लेस इसके बाद कृपया हमारे सपोर्ट पोर्टल ( हब में लॉग इन करते समय स्वीकार्य) की कोशिश करने के लिए स्वतंत्र महसूस करें।

यह सुझाव दिया गया है कि आप शुरू होने से पहले इस पूरे पृष्ठ के माध्यम से पढ़ सकते हैं। फिर भी, आगे बढ़ें। सुझाया गया वर्कफ़्लो या सेमी-मैनुअल / staged TKLBAM प्रवासनकिसी भी तरह से आप अभी भी कुछ बनाने की उम्मीद करेंगे विशिष्ट सॉफ्टवेयर के लिए मैनुअल समायोजन.

सुझाया गया प्रवासन वर्कफ़्लो

यह सुझाव दिया गया है कि आप एक चरणबद्ध प्रक्रिया में TurnKey के पुराने (pre v14.x) संस्करणों से माइग्रेट करते हैं, इस तरह कुछ:

इस पृष्ठ के नीचे विस्तृत के रूप में विशिष्ट बिंदुओं को नोट करें।
लेखा परीक्षा ने नए सर्वर में डेटा बहाल किया - क्या काम कर रहा है और क्या नहीं है इसकी जांच करें।
अपने लेखा परीक्षा में उल्लिखित मुद्दों को हल करें, जैसा कि आप जाना चाहते हैं, उसे दस्तावेज करना।
अंतिम प्रवास करना।

1. प्रारंभिक पुनरीक्षण और लेखा परीक्षा

यह अनुशंसा की जाती है कि आप अपने प्रोडक्शन सर्वर को स्पर्श न करें (जहां आपका बैकअप आता है) जब तक माइग्रेशन पूरा नहीं हो जाता है और आप 100% संतुष्ट नहीं होते हैं।

पहले जांच लें कि आपका नवीनतम बैकअप हाल ही में है। यह मानते हुए कि आपने पिछले महीने या उससे पहले अपने सर्वर में कोई महत्वपूर्ण बदलाव नहीं किया है; उस समय से बैकअप हमारे प्रारंभिक उद्देश्यों के लिए पर्याप्त होना चाहिए। Then restore your data to a disposible test server (e.g. a local VM or a fresh AWS server, etc) and do a full audit. Take careful note of what is working and what isn't. जब आपके पास ऑडिट पूरा हो जाता है, तो कुछ समय पहले कुछ शोध करने के लिए कुछ समय लें, जो आप अपरिचित हैं।

जब विशिष्ट मुद्दों पर प्रलेखन/हिंटों की खोज की जाती है, तो आम तौर पर गूगल आपके दोस्त है। ध्यान रखें कि हुड TurnKey के तहत Debian पर बनाया गया है, इसलिए आम तौर पर Debian पर लागू होने वाली सामग्री, TurnKey पर भी लागू होती है। v14.x Debian Jessie aka Debian 8. पर आधारित है।

कृपया ध्यान दें कि जब सर्वर में सॉफ़्टवेयर शामिल होता है जो अपस्ट्रीम (जैसे) से स्थापित होता है। TurnKey WordPress को सीधे WordPress से स्थापित करता है, जो आमतौर पर आपके बैकअप में पूरा एप्लिकेशन शामिल होता है। यदि आप अपने v13.0 WordPress साइट को माइग्रेट करते हैं (लेट का दिखावा WordPress v3.2) को v14.2 WordPress सर्वर पर चल रहा है, तो आप अभी भी सॉफ्टवेयर का पुराना संस्करण चला रहे हैं। दूसरे शब्दों में, भले ही TurnKey v14.2 WordPress v4.4 के साथ आता है, आपकी पुरानी 3.2 साइट इसे ओवरराइट करेगी।

चूंकि हमारे सर्वर LAMP आधारित हैं, मैं PHP का उपयोग एक उदाहरण के रूप में कर रहा हूं, लेकिन यह आम तौर पर अन्य सॉफ्टवेयर पर भी लागू होता है। यदि आप v13.x से आ रहे हैं, और सक्रिय रूप से सॉफ्टवेयर को अपडेट नहीं किया है, तो v13.x पर चल रहे अधिकांश PHP अनुप्रयोगों को अभी भी ok को V13.x में PHP के बीच अंतर के रूप में काम करना चाहिए। (PHPv5.4) और v14.x (PHPv5.6) बहुत महत्वपूर्ण नहीं हैं। हालांकि, एक ऐसा मौका है कि पुराने सॉफ्टवेयर जो v13.x पर ठीक हो गया, v14.x पर थोड़ा सा ग्लिच हो सकता है, या शायद बिल्कुल काम नहीं कर सकता है।

यदि आप सॉफ़्टवेयर का उपयोग कर रहे हैं, तो PHP (या जो भी भाषा/प्लेटफ़ॉर्म) के नए संस्करण पर ठीक से समर्थन नहीं किया जाता है, तो आपको सॉफ़्टवेयर को अपग्रेड करने की भी आवश्यकता हो सकती है (उदाहरण के लिए, आप सॉफ्टवेयर को अपग्रेड करने की भी आवश्यकता हो सकती हैं) WordPress)। भले ही आपको आवश्यकता नहीं है, आप नए संस्करण को अपडेट करना चाहते हैं। नए संस्करणों में अक्सर नई सुविधाएँ शामिल होती हैं, और चल रहे सुरक्षा फिक्सेस।

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

2. लेखा परीक्षा के दौरान मिलने वाले मुद्दों के माध्यम से कार्य करना

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

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

3. अंतिम प्रवास

आपने अपने सभी मुद्दों के माध्यम से काम किया है जो आपके लेखा परीक्षा में शामिल नहीं हैं और उनके संकल्प को दस्तावेजीकृत किया है। अपने उत्पादन सर्वर पर वापस जाएं, जहां प्रासंगिक और संभव हो; इसे "रखरखाव मोड" में डालें या अन्यथा इसे लॉक करें (इसलिए कोई नई सामग्री नहीं जोड़ा गया है)। फिर एक अंतिम बैकअप चलाएं।

अपने नए बैकअप को नए सर्वर पर पुनर्स्थापित करें। माइग्रेशन को पूरा करने के लिए अपने डॉक्स का पालन करें ताकि सब कुछ अच्छी तरह से काम कर रहा हो। इसे "रखरखाव मोड" (एटीसी) से बाहर ले जाएं।

एक बार जब आप 100% खुश होते हैं, तो किसी भी अंतिम ट्वीट्स (जैसे DNS को नए मशीन के लिए मैप करने के लिए कॉन्फ़िगर करें) को उत्पादन में डाल दिया जाता है और अपने नए सर्वर का पूरा TKLBAM बैकअप करता है:

tklbam-backup --full-backup now

जब आप तैयार हो जाते हैं तो आप पुराने सर्वर को नष्ट कर सकते हैं। ध्यान दें कि कुछ पुराने सर्वर को थोड़ी देर के लिए चलने के लिए छोड़ देना पसंद करते हैं। इसके अलावा यह अनुशंसा की जाती है कि सर्वर को नष्ट करने से पहले हब ने "अधिकतम बैकअप" को 1 से सेट किया और एक अंतिम पूर्ण बैकअप को मजबूर किया। यह सभी पिछले बैकअप को साफ़ करेगा और आपको संग्रह/ऐतिहासिक उद्देश्यों के लिए अंतिम विरासत बैकअप के साथ छोड़ देगा।

TKLBAM अर्ध-मैनुअल / चरणबद्ध प्रवासन

यदि आपके पास कुछ विचार हैं जहां आपको बहाल करने की महत्वपूर्ण फाइलें स्थित हैं, तो एक अच्छा विकल्प एक मैनुअल (या अर्ध-मैनुअल) बहाल है। यह शॉर्ट सर्किट चीजें हो सकती हैं और लंबे समय तक कम काम का मतलब हो सकता है। यह बहुत पुराने सर्वरों से माइग्रेट करने के लिए आदर्श है, या भारी अनुकूलित या विशेष रूप से जटिल सेटअप। हालांकि TKLBAM अभी भी अपने डेटा को नए सर्वर में स्थानांतरित करने और पूरी तरह से मैनुअल के बजाय प्रक्रिया को अर्ध-मैनुअल बनाने का एक बहुत ही उपयोगी तरीका हो सकता है। अभी भी कुछ हद तक समान वर्कफ़्लो का पालन करने की सलाह दी जाती है जो क्या है ऊपर उल्लेखित.

हालांकि, एक पूर्ण बहाल करने के बजाय, बस एक डाउनलोड और डंप करें:

mkdir /tklbam-dump
tklbam-restore BACKUP_ID --raw-download=/tklbam-dump

उपयोग tklbam-restore, आप अपने बैकअप के विशिष्ट भागों को बहाल कर सकते हैं --limits= स्विच करें। Eg सभी को बहाल करने के लिए /var/www/ और यह सामग्री है, साथ ही एक MySQL डेटाबेस जिसका नाम 'DATABASE_1' है, लेकिन कोई पैकेज नहीं है, आप इस लाइन का उपयोग कर सकते हैं:

tklbam-restore /tklbam-dump --skip-packages --limits="/var/www mysql:DATABASE_1"

वैकल्पिक रूप से, पैकेज को छोड़ देना और सब कुछ बहाल करना /etc (और यह सामग्री है) और /boot (और यह सामग्री है) इस पंक्ति का उपयोग करें:

tklbam-restore /tklbam-dump --skip-packages --limits="-/etc -/boot"

कृपया देखें tklbam-restore man page अधिक जानकारी के लिए।

यदि आप कुछ तोड़ते हैं, तो आप वापस रोल कर सकते हैं tklbam-restore-rollbackहालांकि TKLBAM केवल एक रोलबैक स्टोर करता है। तो यह सब कुछ आप की जरूरत है / एक में चाहते बहाल करने की कोशिश करने के लिए सबसे अच्छा हो सकता है। एक अच्छा विकल्प प्रक्रिया के प्रत्येक चरण में इस नए सर्वर के TKLBAM बैकअप को मैन्युअल रूप से बनाने के लिए शुरू किया जा सकता है।

You can also manually restore files from the /tklbam-dump directory if you wish. The downloaded files should be in locations which are relative to the download directory. E.g. जो फाइल्स से आते हैं /var/www होना चाहिए /tklbam-dump/var/wwwकृपया ध्यान दें कि डिफ़ॉल्ट रूप से, अनुमतियों को मैन्युअल रूप से फ़ाइलों को स्थानांतरित करने पर संरक्षित नहीं किया जाएगा, इसलिए अनुमति समायोजन की आवश्यकता हो सकती है।

किसी भी तरह, आपको अभी भी यह तय करने की आवश्यकता होगी कि क्या करना है और क्या नहीं करना है, लेकिन यह एक मैनुअल माइग्रेशन को थोड़ा आसान बना सकता है। यह निश्चित रूप से एक पूर्ण मैनुअल माइग्रेशन करने की तुलना में आसान होगा!

विशिष्ट सॉफ्टवेयर

Webmin (सभी सर्वर)

V14.0 Webmin के रूप में अब स्टनेल के पीछे छिपे हुए हैं। इसका मतलब यह है कि यदि आप पहले के संस्करण से बहाल करते हैं तो आपको Webmin से पहले कुछ बदलाव करने की आवश्यकता होगी। Webmin सर्वर विन्यास फ़ाइल में (/etc/webmin/miniserv.conf) यह सुनिश्चित करता है कि आपके पास ये प्रविष्टियां हैं (उनमें से किसी को जोड़ना या उन्हें उचित रूप में बदलना):

port=10000
ssl=
listen=10000
inetd_ssl=1
bind=127.0.0.1
sockets=
no_resolv_myname=0
ipv6=0

इसके अलावा डबल चेक कि स्टनल विन्यास (/etc/stunnel/stunnel.conf) में यह (अंतिम रूप से सही) है:

[webmin]
accept  = 12321
connect = 127.0.0.1:10000

यदि आपने Webmin (and/or Webshell) के लिए SSL प्रमाणपत्र को कॉन्फ़िगर किया है तो आपको इसके बजाय उपयोग करने के लिए स्टालों को कॉन्फ़िगर करने की भी संभावना होगी। उदाहरण के लिए, Eg /etc/stunnel/stunnel.conf में लाइनों को समायोजित करें जो कहते हैं:

cert = /etc/ssl/private/cert.pem

Apache (inLAMP) और लाइब्रेरी का लगभग 70%)

Apache विन्यास में कुछ महत्वपूर्ण बदलाव हुए हैं, हालांकि जो चीजें टूट जाएगा वह वास्तव में TurnKey संबंधित है। हमने v14.0 में SSL को कठोर बनाया और डिफ़ॉल्ट प्रमाणपत्र स्थान स्थानांतरित किया। हमने सभी अतिरिक्त SSL / TLS को एक साथ कॉन्फ़िगर किया (/etc/apache2/mods-available/ssl.conf). में)

सबसे महत्वपूर्ण मुद्दा से बचने का सबसे आसान तरीका है Apache की ssl.conf फ़ाइल को अपने बहाल से बाहर करना। आप ऐसा कर सकते हैं:

tklbam-restore --limits="-/etc/apache2/mods-available/ssl.conf"

यदि आपके पास एक तृतीय पक्ष सीए प्रमाणित है तो यह आपको प्रभावित नहीं करेगा (हालांकि आप चाहें तो अपने प्रमाण को स्थानांतरित कर सकते हैं)। यदि आप स्वयं हस्ताक्षरित certs का उपयोग कर रहे हैं, तो बस अपने Apache भूत साइट फ़ाइलों से पुराने Cert के संदर्भ को हटा दें (/etc/apache2/sites-available) में चाल करना चाहिए)। उदाहरण के लिए, E.g. यहाँ पर कार्रवाई में अद्यतन है Trac सर्वर.

अन्य परिवर्तन भी हैं जिन्हें शायद बनाया जाना चाहिए (हालांकि Apache अभी भी उनके बिना काम करना चाहिए)। अधिक जानकारी के लिए नीचे दिए गए लिंक देखें।

अधिक जानकारी:

Apache docs: https://httpd.apache.org/docs/2.4/upgrading.html
Digital Ocean पर ग्रेट पोस्ट: https://www.digitalocean.com/community/tutorials/migrating-your-apache-c...

MySQL

MySQL के संबंध में कुछ भी महत्व को नहीं बदला जाना चाहिए, इसलिए यह उम्मीद की जाती है कि अधिकांश उपयोगकर्ता ठीक होंगे। हालांकि, एक के कारण PHPMyAdmin में बगहमने MySQL वेब यूआई को स्विच किया है; व्यवस्थापक.

यदि आप पसंद करेंगे तो आप PHPMyAdmin के साथ जारी रखने के लिए स्वागत करते हैं, लेकिन आपको एक उप निर्देशिका का उपयोग करने के लिए व्यवस्थापक और ट्वीक PHPMyAdmin को निष्क्रिय करने की आवश्यकता होगी। और PHPMyAdmin का उपयोग करने के लिए उपयोग करें https://YOUR_DOMAIN.COM/phpmyadmin (i.e.) अपनी साइट के एक उपनिर्देशिका के रूप में, बल्कि किसी विशिष्ट बंदरगाह के माध्यम से).

इसके अतिरिक्त (मैं नहीं सोचता कि यह संबंधित है, लेकिन यकीन नहीं) कुछ उपयोगकर्ताओं ने बताया है कि उनके MySQL रूट पासवर्ड पोस्ट रिस्टोर नहीं काम करता है। यह आसानी से MySQL इनिटहुक को फिर से चलाने से रीसेट किया जा सकता है:

/usr/lib/inithooks/bin/mysqlconf.py

फ़ाइलसर्वर

Samba v3.x से V14.x में v4.1/v4.2 के लिए TKL के पिछले सभी संस्करणों में चला गया है, इसलिए फिर कुछ महत्वपूर्ण बदलाव हुए हैं। एक सहायक समुदाय सदस्य ने मुख्य मुद्दों को हल किया है और मंचों में स्पष्ट रूपरेखा पोस्ट की है यहाँ.

फ़ाइल एक्सेस WebUI ने भी बदल दिया है। दुर्भाग्य से, उपयोगकर्ता खाते जो आपने फ़ाइलसर्वर WebUI के पुराने संस्करण में सेट किया हो सकता है, उसे पुनर्निर्मित करने की आवश्यकता हो सकती है। OTOH नया WebUI Samba उपयोगकर्ताओं का उपयोग करता है, इसलिए मौजूदा उपयोगकर्ता इसे अपने मौजूदा खाते और पासवर्ड के साथ स्वचालित रूप से उपयोग कर सकते हैं।

मीडियाविकि

V14.2 MediaWiki के रूप में डेवलपर्स (एक Debian पैकेज के बजाय) से सीधे स्थापित किया गया है। v14.1 से v14.2 तक माइग्रेट करने के निर्देश दस्तावेज दिए गए हैंपिछले संस्करणों के लिए कोई पुष्टि निर्देश नहीं हैं, हालांकि यह बहुत समान होना चाहिए।