Help img puchnie i puchnie mimo 1 migawki

[ghost212]

Przekopałem się przez 10 stron wątków i tylko jeden był na temat, ale nie do końca odpowiada mojej sytuacji
Pomoc - maszyna wirtualna puchnie
Znalazłem też odpowiedź qnap'ową w postaci "jest tak bo ... i nic nie da się zrobić"
Why is the image size of the virtual machine HDD (as shown in File Station) larger than the actual VM's HDD size?
I mimo, że piszą tu o klonowaniu to u mnie klon zrobił się 1=1 spuchnięty
Maszyna virtualna z debianem miarę nowym, odpalona na samodzielnym SSD, sam debian to dysk 200gb gdzie zajęte jest koło 25 (db + gitlab)
.img początkowo zajmował 50-80gb, po miesiącu ma już 186gb i z dnia na dzień rośnie....
Nie mam ustawionego przetrzymywania migawek, jedynie skonfigurowana kopia zapasowa 1 raz dziennie z docelowym miejscem na HDD w raidzie
Konfiguracja backupu:

I pytania:
1. Czy da się jakoś zmniejszyć ten .img? (zrobienie klona nic nie zmieniło)
2. Czy coś zrobiłem źle że to tak puchnie?
3. Czy mogę się przenieść na inne rozwiązanie niż VirtualizationStation, które zapobiegnie takiemu problemowi?
4. Czy jest jakaś alternatywa w ogóle niż przeniesienie wirtualki na duży HDD ? Już teraz kilka razy dostałem alerty o wejściu na limit wolnego miejsca SSD
Przykładowy backup z 9 lipca

A już dzień później kolejny:

Nie do końca to rozumiem, dlaczego .img nagle podwoił objętość, migawka obecnie z dnia na dzień jest tylko jedna:

 

[pimposh]

Spuchnie do maksymalnego ustawionego poziomu. Powód - sposób w jaki na VM alokowane są dane w jej natywnym FS. Rozwiązanie proste - brak.
Tworząc VM - jeżeli ustawiasz VD na N-GB - to tyle musisz fizycznie mieć, a nie liczyć, że zje tylko tyle co użyje.

Inna sprawa, że taki VD pięknie się kompresuje, bo większość dziur w FS to tylko zera. Choć to tylko pudrowanie, trzymanie VD na systemie plików który wspiera kompresje (ZFS) pozytywnie wpłynie na faktyczną ilość miejsca zużytego na nośniku, o ile oczywiście sprzęt ma wystarczający power, żeby nie zamulać choćby przy domyślnym LZ4.

 

[Usunięty użytkownik pigers]

14.11. Listing, Creating, Applying, and Deleting a Snapshot Red Hat Enterprise Linux 7 | Red Hat Customer Portal

wylistowanie coś pokazuje ?
może trzeba skompaktować ? oczywiście robisz to własną odpowiedzialność i z kopią zapasową ;p
virt-sparsify --in-place disk.raw lub qemu-img convert -O raw source.img shrunk.img

 

[ghost212]

hej, wracam po dłuższym czasie bo nie miałem czasu się tym zająć, niestety obraz powoli dalej puchł i wczoraj znów mi folder z VMs wybuchł brakiem miejsca
@pimposh
mam system ZFS, ale nie wiem na teraz w czym mogłoby mi to pomóc obecnie obraz urósł już do 186gb , które ustaliłem na dysk wirtualki
@pigers
wylistowanie nie zwróciło nic, dałem "qemu-img snapshot -l image0.img"
spróbowałem też tego co zaproponowałeś
qemu-img convert -0 raw image0.img image1.img
no i teraz z image0 186gb stworzyło mi image1 200gb oO

Chyba nie widzę innej szansy niż postawić na świeżo te wirtualki od początku.
Wymyśliłem też wczoraj że zamiast backupu wirtualek, które de facto chyba są migawkami może bardziej opłaci się robić po prostu migawki folderu(woluminu) ? Wtedy obrazy nie powinny puchnąć, a backupy plików będą w migawkach?
Pytanie czy w ten sposób przywrócenie .img z migawki woluminu zadziała i nic nie wykrzaczy, może spróbuję wieczorem.

 

[ghost212]

Swoją drogą... nie rozumiem niedoskonałości tych mechanizmów.
Żeby zrobić migawkę czy backup VM który upiera się też na migawce potrzebne jest miejsce na tym samym woluminie/folderze bo najpierw tworzy się kopia/migawka a potem dopiero leci backup w miejsce docelowe (np. inny wolumin)
Natomiast żeby 'sklonować' vm miejsce już nie jest potrzebne, po prostu powstaje kopia w innej lokalizacji :| Nie rozumiem dlaczego backup nie mógłby być po prostu taką kopią.
Wychodzi na to że zamiast cyklicznego backupu który ładuje dodatkowe dane czy migawki do obrazu samego siebie, bardziej opłaca się zrobić klona VM w docelowym miejscu backupów raz na jakiś czas.

 

[Pawliko]

zaloguj sie na ssh tej vm i dupnij taka komende:
sudo fstrim -av

I wklej loga z tej komendy.

 

[ghost212]

/: 169.8 GiB (182296051712 bytes) trimmed on /dev/vda1

 

[Pawliko]

Zobacz czy po tym kopia zapasowa sie zmniejszy czy nie, jak nie to raczej wina po stronie Q ktory nie zwalnia odpowiednio pamieci. Nie wiem czy da sie to jakos aktywowac z poziomu Virtual station czy nie. U mnie na proxmoxie ta funkcja nazywa sie "Discard", pytanie czy jest tego odpowiednik u ciebie. @Silas Mariusz
Mastering Proxmox - Third Edition

 

[Usunięty użytkownik pigers]

trim powinien być właczony w zarządzaniu dyskami Storage Global Settings | QTS 5.0.x

 

[ghost212]

/: 169.8 GiB (182296051712 bytes) trimmed on /dev/vda1

według mojej virtual station nie ma zwalniania pamięci
Why is the image size of the virtual machine HDD (as shown in File Station) larger than the actual VM's HDD size?
Niby klonowanie powinno wyczyścić plik z migawek, ale już to sprawdzałem i niestety nowy obraz był równy staremu lub większy.

trim powinien być właczony w zarządzaniu dyskami Storage Global Settings | QTS 5.0.x

Nie jestem pewny czy ta opcja jest w QuTS Hero, bynajmniej nie mogę znaleźć

 

[Pawliko]

No to ja dalej nie pomoge, jako alternatywe na Virtual Station moge polecic Proxmox Virtual Environment - Open-Source Server Virtualization Platform
Sam tego uzywam co prawda nie na Qnapie tylko na innym serwerze.
Mozesz podpytac @Ice jak mu to dzialalo na Qnapie.

Ewentulanie otworz ticket na helpdesk qnapowy i poczekaj na oficjalne ich stanowisko czy sie da czy sie nie da osiagnac tego co chcesz.

 

[Usunięty użytkownik pigers]

nie wiem o co pytać, skoro w opisie qnapa , stoi jak krowie na rowie:

At this moment there are no convenient methods to reduce VM image size. However, you can use the “VM Clone” function to commit snapshots and reclaim the used capacity of snapshots. This function will delete all of the snapshots and the VM image size will be based on the actual usage of the VM.

pytanie brzmi jak to zautomatyzować?