"Oficjalna" strategia tworzenia kopii zapasowych w doku - co z konsekwencją?

Question

suggested strategy do zarządzania i tworzenia kopii zapasowych danych w dokowanym wygląda mniej więcej tak:

docker run --name mysqldata -v /var/lib/mysql busybox true 
docker run --name mysql --volumes-from mysqldata mysql 
docker run --volumes-from mysqldata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /var/lib/mysql 

Jednak, kiedy zapasowe pojemniki do jazdy w ten sposób, że nie będzie spójne tworzenie kopii zapasowych, ja? Jestem świadomy narzędzi takich jak mysqldump, ale co jeśli potrzebuję wykonać kopię zapasową, na przykład folderu, do którego pliki są ciągle dodawane i usuwane?

Answer 1

Podstawowy problem, przed którym stoisz, tj. Tworzenie kopii zapasowej zmieniających się plików jest niezależny od okna dokowanego. Użyj narzędzia, takiego jak rsnapshot lub dirvish, aby utworzyć kopie zapasowe w woluminie, a następnie użyj metody wspomnianej powyżej, aby przenieść te kopie zapasowe w bezpieczniejsze miejsce, takie jak Amazon s3 lub lodowiec, zgodnie z wymaganiami dotyczącymi niezawodności.

Niezależnie od tego, czy montujesz wolumeny z innego kontenera, czy z hosta vm za pomocą przełącznika -v, zmiany w plikach są odzwierciedlane we wszystkich kontenerach (lub hostach wirtualnych) w mniej więcej czasie rzeczywistym. (Występuje pewne opóźnienie z powodu AUFS, którego docker używa na górze hosta, ale nie jest zbyt duży). Jeśli pojemnik kopii zapasowej działał wiecznie, mógł nadal wykonywać kopie zapasowe, a pliki zawsze odzwierciedlały najnowsze pliki widziane przez kontener mysql.

Edytuj: Dla przejrzystości.