WordPress-ის სატესტო ასლი: უსაფრთხო განახლება backup-ით

WordPress-ის უსაფრთხოდ განახლება მხოლოდ მკაცრი თანმიმდევრობით შეიძლება: შეინახე ფაილებისა და მონაცემთა ბაზის backup, ეს backup აღადგინე საიტის მეორე ასლში, განახლებები ჯერ იქ გაუშვი, გადაამოწმე გვერდები, რომლებიც შემოსავალს გიტანს, და მხოლოდ ამის შემდეგ გაიმეორე იგივე განახლებები მთავარ საიტზე. მეხუთე ნაბიჯი, რომელსაც უმეტესი ინსტრუქცია გამოტოვებს, არის იმის დადასტურება, რომ backup საერთოდ აღდგება. თუ აღდგენის მიზნად სატესტო ასლს გამოიყენებ, მეორე და მეხუთე ნაბიჯი ერთი და იგივე მოქმედებაა და მთელი წესი თვეში დაახლოებით ოცი წუთი გიჯდება. სტატიის დანარჩენი ნაწილი სწორედ ეს წესია დაწვრილებით: ბრძანებები, wp-config.php-ის კონსტანტები, რომლებიც ასლს ორიგინალივით ქცევას უშლის, და შეცდომები, რომელთა გამოც „ტესტი“ არაფერს ღირს.

რატომ აფუჭებს განახლება WordPress-ის საიტებს#

WordPress-ის საიტი არის ბირთვი, თემა და სხვადასხვა ავტორის პლაგინების გროვა, რომლებიც PHP-ის ერთ ვერსიაზე მუშაობენ ერთ მონაცემთა ბაზასთან. განახლება ამ ნაწილებიდან ერთს ცვლის და არ იცის, დანარჩენი რას აკეთებს. განახლებების უმეტესობა პრობლემის გარეშე გადის. ისინი, რომლებიც გტკივა, ოთხ ჯგუფად იყოფა:

• პლაგინი იძახებს იმას, რაც ახალმა ბირთვმა წაშალა ან მოძველებულად გამოაცხადა, და გვერდი, რომელიც ამას იყენებდა, ფატალურ შეცდომას ან ცარიელ ეკრანს აჩვენებს. სიმპტომები და ლოგის ხაზები გაანალიზებულია სტატიაში WordPress-ის თეთრი ეკრანი და 500 შეცდომები.
• პლაგინის განახლება ცვლის მონაცემთა ბაზის ცხრილებს პირველივე ჩატვირთვისას. ეს ცვლილება ცალმხრივია: პლაგინის ძველი ფაილების დაბრუნება ცხრილების ძველ სტრუქტურას არ აბრუნებს.
• თემის განახლება გადააწერს შენს ცვლილებებს. რაც მშობელი თემის საქაღალდეში შეცვალე, იკარგება და წინასწარ არავინ გაფრთხილებს. ბავშვი თემა (child theme) სწორედ ამის თავიდან ასარიდებლად არსებობს.
• PHP-ის ვერსიის ცვლილება WordPress-ის განახლება არ არის, მაგრამ ხშირად მასთან ერთად ხდება. პლაგინმა, რომელიც 8.2-ზე მუშაობდა, 8.4-ზე შეიძლება გაფრთხილებები დაწეროს ან გაჩერდეს.

ცვლილებების სიით ვერ გამოიცნობ, რომელ ჯგუფს ეკუთვნის განახლება. ამას იგებ მაშინ, როცა მას იქ გაუშვებ, სადაც შედეგს მნიშვნელობა არ აქვს. სატესტო ასლის არსებობის მთელი არსი ეს არის და ამიტომაა „წყნარ ღამეს განვაახლებ“ არა გეგმა: წყნარი ღამე გატეხილ გადახდის გვერდს ნაკლებად გატეხილს არ ხდის, უბრალოდ შენამდე ნაკლები ადამიანი ამჩნევს.

წესი ექვს ნაბიჯად#

თანმიმდევრობა ასეთია. თითოეულ ნაბიჯს ქვემოთ საკუთარი განყოფილება აქვს.

1. ნახე, რა ელოდება განახლებას. ჩამოწერე ბირთვის, პლაგინებისა და თემების განახლებები. ყველაფრის ცვლილებათა სია წაიკითხე, რაც მთავარ ვერსიას ახტება.
2. შეინახე მთავარი საიტის backup: ყველა ფაილი და ცალკე მონაცემთა ბაზის დამპი.
3. სატესტო ასლი განაახლე ამ backup-იდან. აღადგინე ფაილები, შემოიტანე ბაზა, გადაწერე მისამართები და გამორთე ყველაფერი, რის გაკეთებაც ასლს არ უნდა შეეძლოს.
4. განაახლე სატესტო ასლი და შეამოწმე გვერდებისა და მოქმედებების წერილობითი სიის მიხედვით.
5. განაახლე მთავარი საიტი იმავე თანმიმდევრობით, წყნარ საათში, მე-2 ნაბიჯის backup ხელთ გქონდეს.
6. შეამოწმე მთავარი საიტი და ჩაინიშნე, რა შეიცვალა და როდის.

დიაგრამა ერთ მნიშვნელოვან დეტალს აჩვენებს: სატესტო ასლი backup-იდან შენდება და არა პირდაპირ მთავარი საიტიდან. ეს განზრახ არის ასე. წესის ყოველი გავლა აღდგენის გზას ამოწმებს და თუ აღდგენა ჩავარდა, ამას სამშაბათს გაიგებ, როცა არაფერი გკარგავს, და არა მაშინ, როცა საიტი უკვე გაჩერებულია.

ნაბიჯი 1: ნახე, რა ელოდება განახლებას#

სიას wp-admin-ში ნახავ: Dashboard, შემდეგ Updates. თუ იმ მანქანაზე, სადაც WordPress მუშაობს, shell გაქვს, WP-CLI იმავე ინფორმაციას ისეთი სახით გაძლევს, რომლის ჩასმაც ჩანაწერში შეგიძლია:

$ wp core check-update$ wp plugin list --update=available --fields=name,version,update_version$ wp theme list --update=available --fields=name,version,update_version

ამ სიის კითხვის ორი წესი. პირველი: პლაგინის ცვლილებათა სია სრულად უნდა წაიკითხო, თუ ის მთავარ ვერსიას ახტება (მაგალითად, 4.x-დან 5.x-მდე), რადგან სწორედ იქ აცხადებენ ავტორები წაშლილ ფუნქციებსა და ბაზის მიგრაციებს. მეორე: პლაგინი, რომელიც ავტორმა ორი წელია არ განაახლა, გადაწყვეტილებას ახლა მოითხოვს და არა განახლების დღეს: ან შეცვალე, ან აღიარე, რომ ეს რისკია. სტატია WordPress-ის დაცვა ხსნის, რატომაა მიტოვებული პლაგინები საიტების გატეხვის ჩვეულებრივი გზა.

ჩაიწერე ასევე PHP-ის გამოყენებული ვერსია. wp-admin-ში ის არის Tools, შემდეგ Site Health, შემდეგ Info, შემდეგ Server. სატესტო ასლი იმავეზე უნდა მუშაობდეს, თორემ ტესტი არაფერს ამტკიცებს.

ნაბიჯი 2: ფაილებისა და ბაზის backup#

WordPress-ის backup ორი ნაწილისგან შედგება და მხოლოდ ერთის ასლი backup არ არის. ფაილებში არის wp-content (თემები, პლაგინები, ატვირთული ფაილები) და wp-config.php. მონაცემთა ბაზაში არის ყველა პოსტი, გვერდი, კომენტარი, მომხმარებელი და პარამეტრი. ფაილების ბაზის გარეშე აღდგენა გაძლევს საიტს თემით და შინაარსის გარეშე; ბაზის ფაილების გარეშე აღდგენა გაძლევს შინაარსს, რომელიც არარსებულ სურათებზე მიუთითებს.

ჯერ ფაილების backup გააკეთე, მის მერე მაშინვე ბაზის დამპი. RE:NODE-ის ვებ-გეგმებზე backup ღილაკია ან ამოცანა Schedules ჩანართზე, ხოლო backup-ის სლოტები ყველა გეგმაშია; backup სერვერის ფაილებს მოიცავს, ამიტომ ბაზის დამპი ცალკე ნაბიჯია, რომელსაც თავად აკეთებ. თუ shell გაქვს, უმოკლესი გზა არის mysqldump WP-CLI-ით:

$ wp db export - --single-transaction | gzip > ~/pre-update-$(date +%F).sql.gz$ gzip -t ~/pre-update-$(date +%F).sql.gz && echo "archive readable"

WP-CLI-ს გარეშე იგივეს აკეთებს mysqldump wp-config.php-ის მონაცემებით:

$ mysqldump --single-transaction --no-tablespaces \    -h DB_HOST -u DB_USER -p DB_NAME | gzip > pre-update.sql.gz

დროშა --single-transaction InnoDB ცხრილების თანმიმდევრულ სნეპშოტს იღებს საიტის დაბლოკვის გარეშე. დროშა --no-tablespaces შლის უფლებების შეცდომას იმ ჰოსტინგზე, სადაც ბაზის მომხმარებელს PROCESS პრივილეგია არ აქვს, და ეს ჩვეულებრივი შემთხვევაა მომხმარებლისთვის, რომელსაც მხოლოდ საკუთარ ბაზასთან აქვს წვდომა. დროშები სრულად განხილულია სტატიაში backup და აღდგენა mysqldump-ით.

თუ გეგმას პანელში ბაზების გვერდი აქვს, არსებობს მეორე გზა shell-ის გარეშე: Open in phpMyAdmin ერთჯერადი ტოკენით შეგიყვანს, ხოლო Export, შემდეგ Custom, შემდეგ gzip იგივე ფაილს გაძლევს. ზომის ლიმიტები, რომლებზეც დიდი ბაზები ეჯახება, აღწერილია phpMyAdmin-ის იმპორტისა და ექსპორტის გზამკვლევში.

შემდეგ ორივე ფაილი ჩამოტვირთე მანქანიდან. Backup, რომელიც იმის გვერდით დევს, რასაც იცავს, კომფორტია და არა დაცვა. პანელის backup-ები ჩამოსატვირთია; დამპიც შეგიძლია ჩამოტვირთო SFTP-ით ან ფაილების მენეჯერით (SFTP და ფაილების მენეჯერი). თუ backup-ს პანელში ჩაკეტავ, ის იმ როტაციასაც გადაურჩება, რომელიც ახლის შექმნისას ყველაზე ძველ სლოტს შლის. განახლებამდე გაკეთებულ backup-ს ეს გაუკეთე და ჩაკეტვა მოხსენი, როცა განახლება ერთი კვირა პრობლემის გარეშე იმუშავებს.

ნაბიჯი 3: ააწყვე სატესტო ასლი#

სატესტო ასლი WordPress-ის მეორე ინსტალაციაა, რომელშიც მთავარი საიტის ახალი ასლი დევს. ეს შეიძლება იყოს ქვედომენი იმავე ანგარიშში, მეორე პატარა გეგმა ან საქაღალდე მანქანაზე, რომელსაც თავად მართავ. მოთხოვნები ცოტაა:

• PHP-ის იგივე ვერსია, რაც მთავარ საიტზეა, და მსგავსი მეხსიერების ლიმიტი. სატესტო ასლი PHP 8.4-ზე, რომელიც 8.2-ზე მომუშავე მთავარ საიტს ამოწმებს, განახლების შესახებ არაფერს ამტკიცებს.
• საკუთარი მონაცემთა ბაზა. სატესტო ასლი არასდროს მიაბა მთავარ ბაზას, „უბრალოდ ვნახავ“-ის მიზნითაც კი. პლაგინი, რომელიც სატესტო ასლზე ცხრილებს განაახლებს, მაშინ მთავარ საიტსაც შეცვლის.
• საკუთარი მისამართი, მაგალითად staging.example.com, HTTPS-ით. RE:NODE-ის აპლიკაციებისა და ვებ-გეგმები proxy სლოტს მოიცავს: A ჩანაწერი მიმართე ნაჩვენებ მისამართზე და სერტიფიკატი ავტომატურად გაიცემა და განახლდება. ყველაზე სუფთა სატესტო ასლი არის WordPress-ის მეორე სერვერი, ხოლო WordPress-ის გეგმები წერის მომენტში თვეში $5-იდან იწყება - მიმდინარე ჩამონათვალი იხილე ვებ-ჰოსტინგის გვერდზე. ორი გარემოს ქონის ზოგადი მიზეზები და ის, რა უნდა იყოს განზრახ განსხვავებული, განხილულია სტატიაში staging და production ერთ ანგარიშში.

ახლა მასში აღადგინე მონაცემები. ნაბიჯები იგივეა, რაც გადატანისას, რომელიც უფრო დაწვრილებით არის აღწერილი სტატიაში WordPress-ის გადატანა ახალ ჰოსტზე; აი მოკლე ვერსია.

1. ფაილების backup გახსენი სატესტო ასლის ვებ-ფესვში.
2. შეასწორე სატესტო ასლის wp-config.php ისე, რომ DB_NAME, DB_USER, DB_PASSWORD და DB_HOST სატესტო ბაზის მნიშვნელობები ჰქონდეს. მთავარი საიტის მნიშვნელობები არ დააკოპირო.
3. შემოიტანე დამპი.
4. გადაწერე მისამართები.

$ gunzip -c pre-update-2026-10-20.sql.gz | wp db import -$ wp search-replace 'https://example.com' 'https://staging.example.com' \    --skip-columns=guid --all-tables --dry-run$ wp search-replace 'https://example.com' 'https://staging.example.com' \    --skip-columns=guid --all-tables

ყოველთვის ჯერ --dry-run გაუშვი და წაიკითხე ჩანაცვლებების რაოდენობა ცხრილების მიხედვით. wp search-replace PHP-ის სერიალიზებულ მონაცემებს ესმის, სწორედ ამიტომ არსებობს: სერიალიზებულ პარამეტრზე უბრალო SQL REPLACE() სტრიქონის სიგრძეს ცვლის, მაგრამ მის გვერდით შენახულ სიგრძეს არ აახლებს და WordPress მთელ პარამეტრს დაზიანებულად თვლის. --skip-columns=guid პოსტების GUID-ებს არ ეხება, რადგან ისინი იდენტიფიკატორებია და არა ბმულები, და საიტის გადატანისას არ უნდა შეიცვალოს.

თუ shell არ გაქვს, იმავე საქმეს wp-admin-იდან აკეთებს პლაგინი Better Search Replace და სერიალიზებული მონაცემების წესი მასზეც მოქმედებს. დამპის ფაილზე ტექსტური რედაქტორის ძებნა-ჩანაცვლებას არასდროს გამოიყენებ.

ასლი ასლივით იქცეოდეს

სატესტო ასლი, რომელიც ორიგინალივით იქცევა, საშიშია. ის ორიგინალის წერილებს აგზავნის, ორიგინალის გადახდის შლუზით ხსნის თანხას, ორიგინალის სოციალურ ქსელებში აქვეყნებს და საძიებო შედეგებში შენი რეალური საიტის დუბლიკატად ჩნდება. ეს ჩაამატე სატესტო ასლის wp-config.php-ში იმ ხაზის ზემოთ, რომელიც ამბობს, რომ რედაქტირება შეწყვიტე:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );define( 'DISABLE_WP_CRON', true );define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );define( 'WP_DEBUG_DISPLAY', false );define( 'AUTOMATIC_UPDATER_DISABLED', true );

თითოეული კონსტანტა რას აკეთებს:

გამართვის ლოგი მხოლოდ სატესტო ასლზე უნდა იყოს. მთავარ საიტზე ყველასთვის წასაკითხი debug.log ინფორმაციის გაჟონვაა. cron-ის კონსტანტა ახსნილია სტატიაში WP-Cron თუ ნამდვილი cron; სატესტო ასლზე გჭირდება ის, რაც ამ სტატიაში მთავარ საიტზეა გამართული, პირიქით.

შემდეგ გამორთე გამავალი ფოსტა და საძიებო სისტემების ინდექსაცია. ჯერ ფოსტა, პატარა სავალდებულო პლაგინით, რომელიც პლაგინების ცვლილებებს გადაურჩება. შექმენი wp-content/mu-plugins/staging-no-mail.php:

<?php// Staging only: wp_mail() returns false and nothing is sent.add_filter( 'pre_wp_mail', '__return_false' );

რაც ფოსტას სხვა გზით აგზავნის, მაგალითად პლაგინი საკუთარი SMTP-ით ან API ინტეგრაციით, ამ პლაგინის პარამეტრებში უნდა გამორთო. განსაკუთრებით გადაამოწმე გადახდის შლუზები: გადაიყვანე სატესტო რეჟიმში ან სატესტო ასლზე პლაგინი გამორთე.

ახლა საძიებო სისტემები:

$ wp option update blog_public 0

ეს რთავს „საძიებო სისტემებს ჰკითხე, არ დააინდექსონ საიტი“, რაც noindex სიგნალს ამატებს. ეს თხოვნაა და არა საკეტი, ამიტომ სატესტო ასლის მისამართი არც ერთ საჯარო ბმულში არ მოათავსო. თუ ჰოსტინგი ქვედომენის პაროლით დაცვას გვთავაზობს, გამოიყენე; შესვლის ფანჯარა ერთადერთი საიმედო გზაა, რომ როგორც რობოტები, ისე ცნობისმოყვარე კლიენტები მოაცილო.

ბოლოს ასლის იერი გამორჩევადი გახადე, რომ ორი საიტი ვინმემ არ აურიოს. საკმარისია ბანერი ან ადმინისტრირების სხვა ფერთა სქემა. გრძელი დღის ბოლოს არასწორი ჩანართის განახლება სწორედ ისაა, რითაც ასეთი წესი ირღვევა.

ნაბიჯი 4: განაახლე სატესტო ასლი და შეამოწმე#

განაახლე ისეთი თანმიმდევრობით, რომ ჩავარდნის მიზეზი აშკარა იყოს: ერთი ნივთი ერთხელ და, თუ დრო გაქვს, შორის შეამოწმე.

$ wp plugin update --all$ wp theme update --all$ wp core update$ wp core update-db

თანმიმდევრობა განზრახაა არჩეული. wp core update-db ბაზის იმ განახლებას უშვებს, რომელიც ბირთვის მთავარ გამოშვებას მოჰყვება, ხოლო ბირთვი ბოლოს ნიშნავს, რომ პლაგინის ჩავარდნა ბირთვის ჩავარდნაში არ აგერევა. თუ პლაგინები ბევრი გაქვს, განაახლე სამ-ოთხიანი ჯგუფებით და ჯგუფებს შორის შეამოწმე; როცა რამე გაფუჭდება, დამნაშავე ბოლო ჯგუფშია. თუ ჯგუფის ერთი პლაგინითაც ფუჭდება, გამორთე და დაადასტურე:

$ wp plugin deactivate suspect-plugin$ wp plugin list --status=active --fields=name,version

შეამოწმე სიით და არა შეგრძნებით

„დავაჭირე აქეთ-იქით და კარგად ჩანდა“ მხოლოდ იმას ამოწმებს, რაზეც დაჭერა გახსენდა. ჩანაწერში მოკლე წერილობითი სია გქონდეს და ყოველ გაშვებაზე მონიშნე. ტიპური სია მცირე ბიზნეს-საიტისთვის:

ლოგი წაიკითხე, სანამ გადაწყვეტ, რომ ტესტი გავიდა. საიტი კარგად შეიძლება ჩანდეს, მაშინ როცა პლაგინი ყოველ მოთხოვნაზე ფატალურ შეცდომას წერს, რომელსაც ქეში მალავს. საბოლოო შემოწმება გაასუფთავებული ქეშით გააკეთე, რადგან ქეშიდან გამოტანილი გვერდები არაფერს ამოწმებს:

$ wp cache flush$ tail -n 50 wp-content/debug.log

გაუშვი ასევე მთლიანობის შემოწმება, რომელიც ბირთვის ფაილებს ოფიციალურ საკონტროლო ჯამებს ადარებს:

$ wp core verify-checksums$ wp db check

საკონტროლო ჯამის შეუსაბამობა ფაილზე, რომელიც არ გაგირედაქტირებია, ნიშნავს, რომ ბირთვი ვიღაცამ შეცვალა. ამის ცოდნა სასარგებლოა, სანამ იგივე განახლებას მთავარ საიტზე გაუშვებ.

თუ ტესტი ჩავარდა, იმას მიაღწიე, რისთვისაც მოხვედი. ჩაინიშნე, რომელმა პლაგინმა ან თემამ გამოიწვია, გადაწყვიტე, დაელოდო გასწორებულ გამოშვებას, შეცვალო პლაგინი თუ მხოლოდ ის მიმდინარე ვერსიაზე დააფიქსირო, და მთავარი განახლება მის გარეშე გაუშვი. მთავარ საიტს არაფერი შეხებია.

ნაბიჯი 5: განაახლე მთავარი საიტი#

ახლა კი. გააკეთე ახალი backup და ბაზის დამპი, რადგან მე-2 ნაბიჯისა უკვე საათების ან დღეების წინანდელია და ამასობაში პოსტები, შეკვეთები და კომენტარები დაემატა. შემდეგ:

1. ჩართე მოვლის რეჟიმი, თუ საიტი შეკვეთებს ან ფორმების გაგზავნას იღებს. wp maintenance-mode activate ამას WP-CLI-ით აკეთებს; activate და deactivate წყვილი მთელი ინტერფეისია.
2. გაუშვი ზუსტად ის განახლების ბრძანებები, რაც სატესტო ასლზე გაუშვი, იმავე თანმიმდევრობით.
3. გაასუფთავე ქეშები: ქეშის პლაგინი, ობიექტის ქეში, თუ გაქვს, და ნებისმიერი CDN.
4. გაიარე იგივე შემოწმების სია, ამჯერად ცოცხალ მისამართზე.
5. გამორთე მოვლის რეჟიმი.

გააკეთე ეს შენი ანალიტიკით ყველაზე წყნარ საათში, მაგრამ დაძინებამდე არა. განახლება საღამოს თერთმეტზე და დილით შვიდზე იმის აღმოჩენა, რომ გადახდის გვერდი არ მუშაობს, მთელი ღამის შეკვეთებს ჯდება; განახლება სამუშაო დღეს ორ საათზე და აღმოჩენა 14:20-ზე რამდენიმე წუთს ჯდება. „წყნარი“ ნაკლებად მნიშვნელოვანია, ვიდრე „აქ ვარ და უკან დაბრუნება შემიძლია“.

უკან დაბრუნება, თუ მაინც ცუდად წავიდა

სატესტო ასლი პრობლემების უმეტესობას იჭერს, მაგრამ არა ყველას, რადგან მას არ აქვს მთავარი საიტის ტრაფიკი, ქეშები და მიმდინარე მონაცემები. თუ მთავარი საიტი მაინც დაიმტვრა, სამი ბერკეტი გაქვს ფასის ზრდის მიხედვით:

1. გამორთე დამნაშავე. თუ საიტი თეთრ ეკრანს აჩვენებს და wp-admin-ში ვერ შედიხარ, გადაარქვი სახელი პლაგინის საქაღალდეს wp-content/plugins-ში SFTP-ით ან ფაილების მენეჯერში, ან გაუშვი wp plugin deactivate name. ჩვეულებრივ ესეც საკმარისია.
2. დააყენე ამ პლაგინის წინა ვერსია, თუ განახლებას ბაზა არ შეუცვლია. wp plugin install name --version=1.2.3 --force კონკრეტულ გამოშვებას აყენებს. თუ პლაგინმა ცხრილები გადაიტანა, ძველმა ვერსიამ შეიძლება მათი გაგება ვერ შეძლოს.
3. აღადგინე backup მე-5 ნაბიჯიდან, ფაილებიც და ბაზაც, რაც იმ დროიდან ჩაწერილს დაკარგავს. მაღაზიისთვის ეს რეალური ფასია და სწორედ ამიტომ არსებობს მოვლის რეჟიმის ნაბიჯი.

სატესტო ასლზე რეპეტიციის აზრი ისაა, რომ უკან დაბრუნება თითქმის არასდროს უნდა მივიდეს მესამე ბერკეტამდე.

ნაბიჯი 6: დაამტკიცე, რომ აღდგენა მუშაობს#

Backup, რომელიც არავის აღუდგენია, ჰიპოთეზაა. ყველაფერი ზემოთ ვარაუდობს, რომ pre-update.sql.gz-ის იმპორტი მომუშავე საიტს იძლევა. ამას მხოლოდ იმპორტით გაიგებ და სატესტო ასლის განახლება მე-3 ნაბიჯში სწორედ ეს ტესტია, თუ იქ პრობლემას აღმოჩენად მიიღებ და არა ხელშემშლელად.

შემოწმება გახადე აშკარა და არა ნაგულისხმევი. ყოველი აღდგენის შემდეგ სატესტო ასლი შეადარე იმას, რაც მთავარ საიტზე იცი:

$ wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_status='publish';"$ wp db query "SELECT COUNT(*) FROM wp_users;"$ wp post list --post_type=page --post_status=publish --format=count

იგივე მოთხოვნა მთავარ საიტზეც გაუშვი: რიცხვები უნდა ემთხვეოდეს, იმ ცვლილების სიზუსტით, რაც backup-სა და შემოწმებას შორის გამოქვეყნდა. ცხრილების პრეფიქსები საიტებს შორის განსხვავდება; wp db prefix შენსას გამოიტანს. შემდეგ გახსენი ყველაზე ახალი პოსტი და ყველაზე ახალი ატვირთული ფაილი, რადგან აღდგენა სწორი რიცხვებით და სურათების გარეშე მაინც ჩავარდნილი აღდგენაა.

სამი შემოწმება ცუდი backup-ების უმეტესობას იჭერს:

• არქივი იკითხება: gzip -t file.sql.gz არაფერს ბეჭდავს, თუ არქივი მთლიანია. შეწყვეტილი ჩამოტვირთვა ან სავსე დისკი აქ გამოჩნდება.
• ფაილის ზომა დამაჯერებელია. თუ დამპი გასული თვის მეათედია, რაღაც ჩუმად ჩავარდა, ხოლო backup-ის ამოცანა, რომელიც ექვსი კვირაა 2 KB-იან ფაილებს წერს, უფრო ხშირია, ვიდრე უნდა იყოს.
• აღდგენა შეცდომების გარეშე სრულდება. დამპი, რომელიც CREATE TABLE-ის შუაში წყდება, „წარმატებით“ შემოდის, თუ შეცდომებს არსად გაგზავნი. წაიკითხე გამოტანა.

კვარტალში ერთხელ ერთი ნაბიჯით წინ წადი და აღადგინე სრულიად ცარიელ ბაზასა და ცარიელ საქაღალდეში, მხოლოდ backup-ის ფაილებითა და შენი ჩანაწერებით. ეს ტესტის ის ვერსიაა, რომელიც რეალურ კატასტროფას შეესაბამება, როცა ძველი ინსტალაცია არ გაქვს, საიდანაც პარამეტრებს ისესხებ. მსჯელობა დაწვრილებით არის სტატიებში აღდგენის შემოწმება, სანამ დაგჭირდება და backup-ები, რომლებიც ნამდვილად აღდგება.

RE:NODE-ზე პანელის backup-ის აღდგენა ერთი ღილაკია Backups ჩანართზე, ამიტომ შემოწმების ფაილური ნახევარი სწრაფია; ბაზის ნახევარი იმპორტია, რომელსაც თავად აკეთებ, ამიტომ დამპი წესის ნაწილი უნდა იყოს და არა მეხსიერებაში ეკიდოს.

მოსაწყენი ნაწილების ავტომატიზაცია#

წესი მხოლოდ მაშინ გადარჩება, თუ იაფია. სამი რამ ღირს ავტომატიზაციად.

ფაილების დაგეგმილი backup. Schedules ჩანართი backup-ებს cron გამოსახულებით უშვებს, ამიტომ ყოველდღიური backup დილის პატარა საათებში საკუთარ სკრიპტს არ საჭიროებს. დამპისთვის დაამატე მეორე განრიგი რამდენიმე წუთის დაგვიანებით, თუ მის გაშვებას იმავე ადგილიდან შეძლებ. სინტაქსი აღწერილია სტატიაში cron გამოსახულებები განმარტებით.

ბაზის დაგეგმილი დამპი, თუ shell გაქვს:

0 3 * * * cd /var/www/example.com && /usr/local/bin/wp db export - --single-transaction | gzip > /var/backups/wp-$(date +\%F).sql.gz

უკუდახრილი ხაზი %-მდე crontab-ში მნიშვნელოვანია; დაუცველი % ახალ ხაზად აღიქმება. ძველი დამპები წაშალე ბრძანებით find /var/backups -name 'wp-*.sql.gz' -mtime +14 -delete.

სატესტო ასლის განახლების სკრიპტი, რომელიც მე-3 ნაბიჯის მოქმედებებს ერთად ასრულებს, რომ განახლება იყოს ბრძანება და არა ოცი წუთი დაჭერა. მისი ფორმა ასეთია: ფაილების გახსნა, დამპის იმპორტი, search-replace-ის გაშვება, სატესტო ასლის კონსტანტების ჩაწერა. შეინახე ჩანაწერში ან პირად რეპოზიტორიაში მონაცემების გარეშე; მონაცემები გარემოდან აიღე. როცა პირველად დაწერ, აღმოაჩენ ერთ ხელით ნაბიჯს, რომელიც დაგავიწყდა, და ეს სკრიპტის მომხრე საუკეთესო არგუმენტია.

ფონურ ავტომატურ განახლებებზეც უნდა გადაწყვიტო. WordPress ნაგულისხმევად ბირთვის მცირე განახლებებს ავტომატურად აყენებს. პლაგინებისა და თემების ავტოგანახლება wp-admin-ში ცალ-ცალკე შეიძლება ჩაირთოს. გონივრული პოლიტიკა: ბირთვის მცირე განახლებები ჩართული, ხოლო პლაგინებიდან ავტომატურად განახლდეს ისინი, რომელთა გაფუჭებასაც გაუძლებ, დანარჩენები ზემოთ აღწერილი წესით გადიოდეს. ყველაფრის გამოსართავად საიტზე, რომელსაც ხელით ანახლებ:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );add_filter( 'auto_update_plugin', '__return_false' );

პირველი ხაზი ნაგულისხმევი ქცევის ჩაწერაა; ფილტრი (მას პატარა სავალდებულო პლაგინში აქვს ადგილი და არა wp-config.php-ში, რომელიც ფილტრების დამატებამდე იტვირთება) პლაგინების ავტოგანახლებას რთავს გამორთულზე. უსაფრთხოების გამოსწორებები ყველგან არ გამორთო და მერე საიტი არ დაივიწყო.

შეცდომები, რომლებიც სატესტო ასლს უსარგებლოს ხდის#

სატესტო ასლი რამდენიმე მოსალოდნელი გზით ვარდება და ყველა მათგანი მწვანე ტესტითა და გატეხილი მთავარი საიტით მთავრდება.

• ის დაშორდა. ასლი მარტში აიწყო და მას მერე არ განახლებულა. მთავარ საიტზე თორმეტი ახალი პლაგინი და სხვა თემაა. ასლი ყოველ ჯერზე ახალი backup-იდან ხელახლა ააწყვე - წესი ამიტომაც აკეთებს ამას.
• მას PHP-ის სხვა ვერსია ან მეხსიერების ლიმიტი აქვს, ამიტომ განახლება იქ გადის, სადაც მთავარ საიტზე ვერ გაივლიდა.
• მას რეალური მონაცემები არ აქვს. ასლი სამი სატესტო პოსტით ვერასდროს აჩვენებს პლაგინს, რომელსაც 40 000 სტრიქონიანი ცხრილი ახრჩობს. აღადგინე რეალური ბაზა.
• ის რეალურ წერილებს აგზავნის ან რეალურ გადახდებს იღებს. იხილე კონსტანტები ზემოთ.
• მას ვიღაც პირდაპირ ამუშავებს, და შესწორება, რომელიც „სატესტო ასლზე მუშაობდა“, ხელით შეცვლილი ფაილია, რომელიც მთავარ საიტამდე არასდროს მივა. ცვლილებები ორივე მხარეს ერთი და იგივე გზით მიდის.
• ეს მთავარი ბაზაა. ყველაზე იაფი შეცდომა ყველაზე ძვირი შედეგით. რამის გაკეთებამდე გადაამოწმე DB_NAME.

არც ერთი მათგანი ეგზოტიკური არ არის. ისინი ხდება იმიტომ, რომ სატესტო ასლი არასავალდებულოდ გვეჩვენება, და არასავალდებულოა იმ პირველ განახლებამდე, რომელიც მთავარ საიტს დააზიანებს.

FAQ#

მჭირდება სატესტო ასლი პატარა ბლოგისთვის?

ყოველთვის არა. ბლოგს უფასო თემით, ოთხი პლაგინით და მაღაზიის გარეშე გონივრულად შეუძლია backup-ით, ცოცხალ საიტზე განახლებითა და შემოწმებით კმაროს, რადგან ყველაზე ცუდი რეალისტური შედეგია მოკლე გაჩერება, რომელიც backup-იდან უკან ბრუნდება. სატესტო ასლი ამართლებს მაშინვე, როცა საიტი ფულს იღებს, განაცხადებს აგროვებს ან page builder-სა და საკუთარ კოდს იყენებს.

შემიძლია staging პლაგინი გამოვიყენო მეორე ინსტალაციის ნაცვლად?

ასეთი პლაგინები საიტს ქვესაქაღალდეში ან ქვედომენში კლონავენ და ცვლილებებს უკან აბრუნებენ. ისინი მუშაობენ, მაგრამ იგივე საფრთხეები აქვთ, რაც ხელით ასლს (საერთო ატვირთვები, დაკარგული ფოსტა, ბაზის პრეფიქსების კონფლიქტი), ხოლო უკან დაბრუნებამ შეიძლება გადააწეროს შინაარსი, რომელიც მთავარ საიტზე კოპირების შემდეგ შეიქმნა. backup-იდან აწყობილი ცალკე ინსტალაცია უფრო ადვილად გასაგებია და ამავე დროს შენს აღდგენას ამოწმებს.

რამდენად ხშირად ვანახლო?

კვირაში ერთხელ შეამოწმე და უსაფრთხოების გამოშვებები დღეში ან ორში დააყენე. დანარჩენისთვის სრული წესი გაიარე ფიქსირებულ მომენტში, მაგალითად თვის პირველ სამუშაო დღეს. როცა განახლებები გროვდება, ყოველი ჯგუფი დიდია და დამნაშავის პოვნა უფრო რთული.

უნდა გამოიყენოს თუ არა სატესტო ასლმა იგივე მონაცემთა ბაზის სერვერი, რასაც მთავარი საიტი?

გამოიყენე ცალკე ბაზა იმავე ძრავასა და იმავე მთავარ ვერსიაზე. იგივე სერვერი მისაღებია, თუ გეგმა ერთზე მეტ ბაზას გაძლევს; მნიშვნელოვანია იზოლაცია, ანუ ცალკე მონაცემები და ცალკე სქემა, რომ სატესტო ასლზე შეცდომამ მთავარ მონაცემებს ვერ შეუშალოს ხელი.

რა ვქნა, თუ განახლებამ საიტი დაამტვრია და wp-admin-ში ვერ შევდივარ?

გადაარქვი სახელი wp-content/plugins/name საქაღალდეს იმ პლაგინისას, რომელიც ახლახან განაახლე, ან მთელ plugins საქაღალდეს, SFTP-ით ან ფაილების მენეჯერში. WordPress გამორთავს იმას, რასაც ვერ პოულობს, და ადმინისტრირება ჩვეულებრივ იხსნება. წაიკითხე wp-content/debug.log, რომ დაადასტურო, რომელი პლაგინი იყო, სანამ რამეს დააბრუნებ.

backup-ის აღდგენა იგივეა, რაც უკან დაბრუნება?

არა. წარუმატებელი განახლების შემდეგ უკან დაბრუნებამ მხოლოდ ის პლაგინი ან თემა უნდა დააბრუნოს, რომელმაც ჩაიშალა. აღდგენა მთელ საიტს backup-ის მომენტში აბრუნებს და მას მერე ჩაწერილი ყველაფერი იკარგება. აღდგენა უკანასკნელ საშუალებად ჩათვალე, ხოლო ზემოთ აღწერილი წესი - მიზეზად, რის გამოც ის იშვიათად გჭირდება.