Няколко съвета за това как да направите резервни копия на бази данни
На пръв поглед, да направите резервно копие на базата данни на сайта е много проста, ако имате достъп до mysqldump комунални и планировчика Cron работни места. Като прибавим към влизането на планировчика:
и всичко, всеки ден в 03 часа 14 минути ще бъдат заснети сметище. Време е за архивиране трябва да се избере така, че в този момент натоварването на сървъра е било минимално дневно.
Но това решение не е достатъчно надеждна. Ако основата е повредена, например, в 03:12 часа, на сметището ще бъдат презаписани с празен файл.
За да предотвратите това, че има смисъл да спаси ново копие, преди да извадите да запази старото, и да направи отделни копия на редовни интервали. Например, аз sohrayayu седмични и месечни, и по-малко тегло на SQL-сървър, просто копирайте сметището файлове:
Закъснения на час се прави, за да се отърват може да бъде създадена / копира напълно.
Тези копия са добри, когато искате да възстановите цялата база данни. Но понякога има ситуации, когато трябва да се възстанови само част от съдържанието, така че да се запази това, което е добавено след отстраняването на архива. Например, това може да се наложи, ако форумът е една секция е била отстранена. В този случай, се изсере направен по-горе настройки, не е подходящ, защото има по-SQL команда за изтриване и създаване на всички таблиците в базата данни отново. Така че има смисъл да се процедира, както следва: премахване на резервното копие на структурата на таблицата в един файл, а самите данни - в друга. Освен това, когато импортирате данни в съществуваща таблица вече не е имало грешки, че има смисъл да ги вмъкнете чрез INSERT игнорирате. В този случай, екипът премахнете сметището да бъде под формата на:
В този случай, ако е необходимо, частична реставрация база могат да се внасят само backup.sql и ще vosstanovley само тези записи, които са били изтрити (и няма да бъдат засегнати от тези, които се появи по-късно), и ако е необходимо, пълно възстановяване - първо backup.struct.sql и след това backup.sql. Също така, в някои случаи има смисъл да се използва опция --replace, в този случай, вместо отчета за INSERT ЗАМЕНИ ще се използва, което ще доведе до всички записи в базата данни на ум, което е в момента на изваждане на архива, а по-късно - остава непроменен.
Ако имате услуги корен достъп на сървъра, се препоръчва да се направи резервно копие на това, тъй като корен, и да запазите в директория, която не е достъпна за обикновените потребители. Това е полезно в случай, че нападателят ще uyavzvimost на сървъра, което му позволява да изпълнява prozivolny код от името на един и същи потребител, от която скриптовете се изпълняват сайт, в който случай той няма да бъде в състояние да изтрие архиви. И не забравяйте периодично да качите архива на собствения си компютър (или друг сървър, ако има такъв).
Той добави по-късно: аз написах една малка скрипт, който изпълнява всички от идеите, описани тук, в по-удобна форма за използване и го сложете в GitHub.
Chudnenko! И може би дори команден ред, за да копирате на сметището на отдалечен FTP? (Връзка с име / парола)
Свързани статии