{"id":21498,"date":"2026-09-27T22:09:37","date_gmt":"2026-09-27T14:09:37","guid":{"rendered":"https:\/\/synopower.club\/?post_type=docs&p=21498"},"modified":"2026-09-27T22:09:43","modified_gmt":"2026-09-27T14:09:43","password":"","slug":"vmm-backup-google-drive-cloud-sync","status":"publish","type":"docs","link":"https:\/\/synopower.club\/pl\/docs\/vmm-backup-google-drive-cloud-sync\/","title":{"rendered":"Kopia zapasowa VMM na Dysku Google: zaplanowany eksport, synchronizacja w chmurze i jeden skrypt zmiany nazwy"},"content":{"rendered":"

Kopia zapasowa VMM, kt\u00f3ra znajduje si\u0119 tylko na tym samym serwerze NAS co maszyna wirtualna, nie jest prawdziw\u0105 kopi\u0105 zapasow\u0105. Je\u015bli ten serwer ulegnie awarii, obie kopie zostan\u0105 usuni\u0119te. Ten magazyn dzia\u0142a jako go\u015b\u0107 Virtual DSM w serwerach Synology i Virtual Machine Manager, a nasza zewn\u0119trzna kopia zapasowa VMM jest tworzona z dw\u00f3ch darmowych narz\u0119dzi do\u0142\u0105czonych do DSM: zaplanowanego eksportu w Virtual Machine Manager oraz synchronizacji z chmur\u0105 i Dyskiem Google. Konfiguracja zaj\u0119\u0142a jedno popo\u0142udnie. Znalezienie przyczyny cichego zatrzymania dzia\u0142ania zaj\u0119\u0142o wi\u0119cej czasu i to w\u0142a\u015bnie jest powodem powstania tego artyku\u0142u \u201eHosting NAS 101\u201d. Poni\u017cej znajduje si\u0119 opis konfiguracji, kt\u00f3ra dzia\u0142a, jedyny b\u0142\u0105d w nazwie pliku, kt\u00f3ry go psuje, kr\u00f3tki skrypt, kt\u00f3ry go naprawia, oraz wyniki audytu naszych w\u0142asnych eksport\u00f3w.<\/p>\n\n\n\n

\n

Punkt SynoPower Club:<\/strong> Ka\u017cdy in\u017cynier wsparcia ma histori\u0119 o kliencie, kt\u00f3rego kopie zapasowe dzia\u0142a\u0142y bez zarzutu przez rok i niczego nie przywr\u00f3ci\u0142y. Nie spodziewa\u0142em si\u0119, \u017ce napisz\u0119 o naszym w\u0142asnym. Nasze zadanie tworzenia kopii zapasowej w VMM wygl\u0105da\u0142o w interfejsie idealnie, a jednak jeden host zgromadzi\u0142 terabajt eksport\u00f3w, kt\u00f3rych nigdy nie uda\u0142o mu si\u0119 wyczy\u015bci\u0107, a drugi nie wygenerowa\u0142 ani jednego pliku przez trzyna\u015bcie dni. Nic nie by\u0142o ukryte. Wszystko znajdowa\u0142o si\u0119 w logu, kt\u00f3rego nikt nie czyta. Naprawa zaj\u0119\u0142a godzin\u0119; lekcja jest taka, \u017ce nale\u017cy sprawdza\u0107, czy pliki rzeczywi\u015bcie znajduj\u0105 si\u0119 tam, gdzie si\u0119 ich spodziewamy, zgodnie z harmonogramem, jak w ka\u017cdym innym zadaniu.<\/p>\n<\/blockquote>\n\n\n\n

Czego potrzebuje kompletna kopia zapasowa VMM<\/h2>\n\n\n\n

Virtual Machine Manager zapewnia trzy warstwy ochrony, z kt\u00f3rych ka\u017cda obejmuje inn\u0105 awari\u0119. Solidny plan tworzenia kopii zapasowych VMM obejmuje wi\u0119cej ni\u017c jedn\u0105.<\/p>\n\n\n\n

Warstwa<\/th>Gdzie mieszka kopia<\/th>Przed czym chroni<\/th><\/tr><\/thead>
Migawki<\/td>Taka sama g\u0142o\u015bno\u015b\u0107 jak u go\u015bcia<\/td>Z\u0142a aktualizacja lub b\u0142\u0105d w go\u015bciu<\/td><\/tr>
Replikacja (VMM Pro)<\/td>Kolejny NAS w klastrze<\/td>Awaria serwera NAS, szybkie odzyskanie danych na innym ho\u015bcie<\/td><\/tr>
Zaplanowany eksport + synchronizacja w chmurze<\/td>Konto w chmurze poza siedzib\u0105 firmy<\/td>Utrata ca\u0142ej witryny: po\u017car, kradzie\u017c, ransomware w sieci LAN<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Replikujemy ju\u017c sze\u015bciu go\u015bci do hosta rezerwowego, jak opisano w naszym opisie klaster maszyn wirtualnych Synology z trzema w\u0119z\u0142ami<\/a>. Replikacja przechowuje kopi\u0119 w budynku. Warstwa eksportowa przechowuje kopi\u0119 poza nim.<\/p>\n\n\n\n

Jak dzia\u0142a zaplanowany eksport VMM<\/h2>\n\n\n\n

W przypadku kopii zapasowej VMM, zaplanowany eksport zapisuje pe\u0142n\u0105 kopi\u0119 go\u015bcia, dysk\u00f3w i konfiguracji w postaci pojedynczego pliku OVA w folderze wsp\u00f3\u0142dzielonym. U\u017cytkownik wybiera folder docelowy, tryb eksportu, harmonogram dzienny, tygodniowy lub miesi\u0119czny oraz liczb\u0119 najnowszych plik\u00f3w do zachowania. Eksporty s\u0105 wykonywane podczas dzia\u0142ania go\u015bcia.<\/p>\n\n\n\n

Dwie zasady \u0142atwo przeoczy\u0107. Po pierwsze, eksport jest konfigurowany i zapisywany na ho\u015bcie, na kt\u00f3rym znajduje si\u0119 host go\u015bcia. sk\u0142adowanie<\/strong> W klastrze go\u015b\u0107 mo\u017ce dzia\u0142a\u0107 na jednym serwerze NAS, podczas gdy jego dyski znajduj\u0105 si\u0119 na innym, a Virtual Machine Manager blokuje opcj\u0119 zaplanowanego eksportu na niew\u0142a\u015bciwym ho\u015bcie. Po drugie, harmonogram korzysta z zegara tego hosta pami\u0119ci masowej.<\/p>\n\n\n\n

\"Ustawienia
Nasze zaplanowane ustawienia eksportu: folder wsp\u00f3\u0142dzielony jako miejsce docelowe, codziennie o 08:00, zachowywane s\u0105 trzy najnowsze pliki.<\/figcaption><\/figure>\n\n\n\n

Okno dialogowe pokazuje r\u00f3wnie\u017c stan sp\u00f3jno\u015bci. Bez zainstalowanego narz\u0119dzia go\u015bcia Synology, eksporty s\u0105 sp\u00f3jne w przypadku awarii, tak jak po od\u0142\u0105czeniu przewodu zasilaj\u0105cego. Jest to wystarczaj\u0105ce dla wi\u0119kszo\u015bci obci\u0105\u017ce\u0144, a instalacja narz\u0119dzia go\u015bcia aktualizuje je do stanu sp\u00f3jno\u015bci systemu plik\u00f3w.<\/p>\n\n\n\n

Dlaczego Cloud Sync pomija pliki kopii zapasowej VMM<\/h2>\n\n\n\n

Oczywistym kolejnym krokiem jest wskazanie Cloud Sync folderu eksportu i pozwolenie mu na przes\u0142anie wszystkiego na Dysk Google. Zrobili\u015bmy dok\u0142adnie to, a pliki kopii zapasowej VMM nigdy nie dotar\u0142y.<\/p>\n\n\n\n

Powodem jest nazwa pliku. Virtual Machine Manager nadaje ka\u017cdemu eksportowi nazw\u0119 ze znacznikiem czasu zawieraj\u0105cym dwukropki:<\/p>\n\n\n\n

exp_web-2026-09-25 10:29:51-6f713905-cee2-4647-94d5-a5ce6fbdc585.ova<\/code><\/pre>\n\n\n\n
Cloud Sync nie przes\u0142a\u0142 tych nazw na nasz Dysk Google, wi\u0119c ka\u017cdy eksport pozosta\u0142 lokalny. Plik jest prawid\u0142owy, ale problem tkwi w znaku. Poniewa\u017c formatu znacznika czasu eksportu nie mo\u017cna zmieni\u0107 w Virtual Machine Manager, poprawka musi zosta\u0107 wprowadzona mi\u0119dzy eksportem a przes\u0142aniem.<\/p>\n\n\n\n
Co ciekawe, tylko zaplanowane eksporty maj\u0105 znacznik czasu. R\u0119czny eksport z tego samego menu jest zapisywany po prostu jako nazwa go\u015bcia, np. spc_4C8G.ova<\/code>, a Cloud Sync przesy\u0142a je bezproblemowo. Dlatego szybki test r\u0119czny mo\u017ce sprawi\u0107, \u017ce ca\u0142y \u0142a\u0144cuch b\u0119dzie wygl\u0105da\u0142 dobrze, podczas gdy harmonogram nocny nigdy nie trafi do chmury.<\/p>\n\n\n\n
Konfigurowanie kopii zapasowej VMM na Dysku Google w 4 krokach<\/h2>\n\n\n\n
To jest dzia\u0142aj\u0105ca konfiguracja kopii zapasowej VMM na ka\u017cdym ho\u015bcie przechowuj\u0105cym go\u015bci. Wymaga Virtual Machine Manager, synchronizacji z chmur\u0105 i konta Google; \u017caden z tych element\u00f3w nie wymaga VMM Pro.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Zaplanuj eksport<\/h3>\n
Na ho\u015bcie, na kt\u00f3rym przechowywany jest go\u015b\u0107, otw\u00f3rz Virtual Machine Manager, wybierz go\u015bcia, wybierz Akcja, Eksport, Zaplanowane, wybierz folder wsp\u00f3\u0142dzielony jako miejsce docelowe i ustaw czas. Pozostaw ustawienie przechowywania na poziomie liczby kopii, kt\u00f3re chcesz zachowa\u0107 lokalnie.<\/p>\n<\/div>\n<\/div>\n
\n
Utw\u00f3rz zadanie synchronizacji w chmurze<\/h3>\n
W us\u0142udze Cloud Sync po\u0142\u0105cz si\u0119 z Dyskiem Google i zsynchronizuj folder eksportu wsp\u00f3\u0142dzielonego z folderem na Dysku. Ustaw kierunek przesy\u0142ania zmian lokalnych i zaznacz opcj\u0119, aby nie usuwa\u0107 plik\u00f3w w miejscu docelowym po ich usuni\u0119ciu w \u017ar\u00f3dle, je\u015bli chcesz, aby chmura zachowa\u0142a starsze kopie.<\/p>\n<\/div>\n<\/div>\n
\n
Dodaj skrypt zmiany nazwy<\/h3>\n
Zapisz skrypt z tego artyku\u0142u na serwerze NAS i utw\u00f3rz zadanie Harmonogramu zada\u0144, kt\u00f3re b\u0119dzie uruchamia\u0107 go jako root co godzin\u0119. Zmienia ono nazwy uko\u0144czonych eksport\u00f3w bez dwukropk\u00f3w i zachowuje najnowsze kopie dla ka\u017cdego go\u015bcia.<\/p>\n<\/div>\n<\/div>\n
\n
Zweryfikuj pierwsze przes\u0142anie<\/h3>\n
Po kolejnym eksporcie sprawd\u017a, czy plik o zmienionej nazwie pojawia si\u0119 w folderze eksportu, czy us\u0142uga Cloud Sync oznacza go jako przes\u0142any i czy rozmiar pliku na Dysku Google jest taki sam jak orygina\u0142.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Ustawienia
Nasze zadanie synchronizacji w chmurze: przesy\u0142aj tylko zmiany lokalne, zaznaczaj\u0105c t\u0119 opcj\u0119, aby Dysk Google zachowa\u0142 eksporty po ich usuni\u0119ciu przez serwer NAS.<\/figcaption><\/figure>\n\n\n\n
Skrypt zmiany nazwy w naszej kopii zapasowej VMM<\/h2>\n\n\n\n
Skrypt jest jedynym niestandardowym elementem \u0142a\u0144cucha kopii zapasowych VMM i wykonuje dwie czynno\u015bci. Zmienia nazw\u0119 ka\u017cdego uko\u0144czonego eksportu, zast\u0119puj\u0105c dwukropki my\u015blnikami, i zachowuje tylko najnowsze kopie ka\u017cdego go\u015bcia w folderze eksportu. Dotyczy tylko plik\u00f3w, kt\u00f3re nie by\u0142y zmieniane przez pi\u0119tna\u015bcie minut, wi\u0119c nigdy nie zmienia nazwy eksportu, kt\u00f3ry jest nadal zapisywany.<\/p>\n\n\n\n
#!\/bin\/bash # vm-export-cloud.sh - umo\u017cliwia przesy\u0142anie eksport\u00f3w VMM za pomoc\u0105 Cloud Sync. # # Nazwy eksport\u00f3w VMM " -RRRR-MM-DD GG:MM:SS- .ova". Cloud Sync nie b\u0119dzie przesy\u0142a\u0107 nazw zawieraj\u0105cych \":\", co oznacza r\u00f3wnie\u017c, \u017ce nigdy nie b\u0119dzie dotyka\u0107 eksportu #, kt\u00f3ry jest nadal zapisywany. Po zako\u0144czeniu eksportu, zmienia on nazw\u0119 w miejsce \"#\", zast\u0119puj\u0105c \":\" znakiem \"-\", dzi\u0119ki czemu Cloud Sync go przejmie, a nast\u0119pnie zachowa tylko najnowsze eksporty # z zmienion\u0105 nazw\u0105 KEEP dla ka\u017cdego go\u015bcia. (W\u0142asna retencja VMM nie widzi ju\u017c plik\u00f3w ze zmienionymi nazwami #, wi\u0119c retencja odbywa si\u0119 tutaj). # # U\u017cycie: vm-export-cloud.sh EXPORT_DIR KEEP [--apply] # Bez opcji \"--apply\" wy\u015bwietla tylko to, co by zrobi\u0142. set -u DIR=${1:?EXPORT_DIR}; KEEP=${2:?KEEP}; APPLY=${3:-} MIN_AGE_MIN=15 # uko\u0144czony eksport jest nietkni\u0119ty i ma tak\u0105 d\u0142ugo\u015b\u0107 LOG="$(dirname "$(readlink -f "$0")")\/vm-export-cloud.log" say() { echo "$(date '+%F %T') $*"; [ "$APPLY" = "--apply" ] && echo "$(date '+%F %T') $*" >> "$LOG"; } run() { if [ "$APPLY" = "--apply" ]; then "$@"; else echo " (uruchomienie pr\u00f3bne) $*"; fi; } [ -d "$DIR" ] || { powiedz "B\u0141\u0104D brak folderu eksportu: $DIR"; wyj\u015bcie 1; } # 1. zmie\u0144 nazw\u0119 zako\u0144czonego eksportu znajd\u017a "$DIR" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -print0 | while IFS= read -r -d '' f; wykonaj polecenie if -v fuser >\/dev\/null 2>&1 && fuser -s "$f" 2>\/dev\/null; nast\u0119pnie powiedz "pomi\u0144 (w u\u017cyciu): $(basename "$f")"; kontynuuj fi new="$DIR\/$(basename "$f" | tr ':' '-')" powiedz "zmie\u0144 nazw\u0119: $(basename "$f") -> $(basename "$new")" run mv -n "$f" "$new" done # 2. Zachowaj najnowsze eksporty KEEP o zmienionej nazwie dla ka\u017cdego go\u015bcia (znacznik czasu znajduje si\u0119 w nazwie) { find "$DIR" -maxdepth 1 -type f -name '*.ova' ! -name '*:*' -printf '%f\\n' [ "$APPLY" = "--apply" ] || find "$DIR" -maxdepth 1 -type f -name '*:*.ova' -mmin +$MIN_AGE_MIN -printf '%f\\n' | tr ':' '-' } | sort -u | sed -E 's\/^(.*)-([0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}-[0-9]{2}-[0-9]{2})-.*\\.ova$\/\\1\\t\\2\\t&\/' | awk -F'\\t' 'NF==3' | sort -t$'\\t' -k1,1 -k2,2r | awk -F'\\t' -v keep="$KEEP" '{ n[$1]++; if (n[$1] > keep) print $3 }' | while IFS= read -r old; do say "delete (beyond latest $KEEP): $old" run rm -f -- \"$DIR\/$old\" done m\u00f3wi \"done: $(find \"$DIR\" -maxdepth 1 -name '*.ova' | wc -l) exports in $DIR, $(df -h '$DIR' | awk 'NR==2{print $4" free"}')\"<\/code><\/pre>\n\n\n\n
Uruchom go bez ostatniego argumentu. W tym trybie drukuje tylko to, co zosta\u0142oby zmienione i usuni\u0119te. Gdy wynik b\u0119dzie wygl\u0105da\u0142 poprawnie, zaplanuj go z dodatkowym argumentem, kt\u00f3ry go uruchomi. Nasze zadanie Harmonogramu zada\u0144 jest uruchamiane co godzin\u0119 jako u\u017cytkownik root za pomoc\u0105 nast\u0119puj\u0105cego polecenia, jedno zadanie na folder eksportu:<\/p>\n\n\n\n
bash \/volume1\/@vm-export-cloud\/vm-export-cloud.sh "\/volume3\/VM_BK_Export" 3 --apply<\/code><\/pre>\n\n\n\n
Przydatny efekt uboczny regu\u0142y dwukropka: Cloud Sync nie mo\u017ce przes\u0142a\u0107 pliku eksportowego, dop\u00f3ki skrypt nie zmieni jego nazwy, a skrypt zmienia nazwy tylko gotowych plik\u00f3w. Niedoko\u0144czone pliki eksportowe nigdy nie docieraj\u0105 do chmury.<\/p>\n\n\n\n
Dlaczego skrypt obs\u0142uguje przechowywanie kopii zapasowych VMM<\/h2>\n\n\n\n
Virtual Machine Manager ma w\u0142asne ustawienie retencji, kt\u00f3re dzia\u0142a poprzez rejestrowanie ka\u017cdego utworzonego eksportu. Gdy skrypt zmieni nazw\u0119 pliku, Virtual Machine Manager przestaje go rozpoznawa\u0107 i nigdy go nie usunie. Retencja jest wi\u0119c przenoszona do skryptu, kt\u00f3ry zlicza kopie na go\u015bcia na podstawie znacznika czasu w nazwie.<\/p>\n\n\n\n
W przypadku synchronizacji z chmur\u0105 jedno pole wyboru decyduje o tym, co dzieje si\u0119 na Dysku Google. \u0141atwo je \u017ale odczyta\u0107: Nie usuwaj plik\u00f3w w folderze docelowym po ich usuni\u0119ciu w folderze \u017ar\u00f3d\u0142owym<\/strong>. Pozostaw to pole niezaznaczone, a Dysk Google b\u0119dzie lustrzanie odzwierciedla\u0142 zawarto\u015b\u0107 NAS-a, zachowuj\u0105c te same trzy kopie. Zaznacz je, a chmura b\u0119dzie przechowywa\u0107 ka\u017cdy przes\u0142any eksport, co jest bezpieczniejszym rozwi\u0105zaniem w przypadku ransomware, ale b\u0119dzie ros\u0142o, dop\u00f3ki nie usuniesz go r\u0119cznie.<\/p>\n\n\n\n
Co wykaza\u0142 audyt naszego w\u0142asnego eksportu<\/h2>\n\n\n\n
Przed t\u0105 konfiguracj\u0105 nasza kopia zapasowa VMM dzia\u0142a\u0142a na obu hostach produkcyjnych przez oko\u0142o miesi\u0105c. Sprawdzanie plik\u00f3w zamiast pulpitu nawigacyjnego wykaza\u0142o trzy oddzielne b\u0142\u0119dy.<\/p>\n\n\n\n