Błąd 0x80780048 przy tworzeniu obrazu systemu (Kopia zapasowa Windows 7) – rzekomy brak miejsca, mimo setek GB wolnej przestrzeni.

Witam,

Zwracam się z prośbą o pomoc w rozwiązaniu krytycznego błędu wbudowanego narzędzia "Kopia zapasowa i przywracanie (Windows 7)" w systemie Windows 11. Próba wykonania pełnej kopii zapasowej (pliki danych + obraz dysku systemowego) za każdym razem zostaje przerwana z komunikatem o braku miejsca.

Kod błędu: 0x80780048 (Na dysku, na którym są zapisywane kopie zapasowe, jest za mało wolnego miejsca). Błąd wyskakuje zawsze w tym samym momencie – gdy program kończy kopiować pliki użytkownika (ok. 40 GB) i próbuje rozpocząć tworzenie obrazu systemu (migawka VSS dysku C: i partycji rozruchowych).

Mój układ dysków i wolne miejsce (tu nie ma problemu z brakiem przestrzeni):

Dysk docelowy na kopię (D:): 931 GB całkowitej pojemności -> ponad 510 GB wolnego miejsca.

Dysk systemowy (C:): 232 GB całkowitej pojemności -> ponad 65 GB wolnego miejsca.

Partycja odzyskiwania (Recovery): 651 MB.

Partycja systemowa EFI: 100 MB.

Czynności diagnostyczne, które już WYKONAŁEM (proszę nie powielać tych porad, ponieważ nie rozwiązują problemu):

Fizycznie i trwale usunąłem folder WindowsImageBackup z dysku docelowego, aby narzędzie miało "czystą kartę". Nie pomogło.

Zwolniłem ponad 60 GB miejsca na dysku C:, m.in. dostosowując rozmiar pliku pagefile.sys, wyłączając hibernację (powercfg -h off) oraz czyszcząc stare kopie w tle za pomocą Oczyszczania dysku. Nie pomogło.

Upewniłem się, że w skład obrazu systemu wchodzą tylko niezbędne partycje (zabrałem plik stronicowania z innej dużej partycji z danymi, aby Windows nie dołączał jej do obrazu).

Zdjąłem limity dla usługi VSS na dysku docelowym za pomocą komendy wiersza poleceń z uprawnieniami administratora: vssadmin resize shadowstorage /For=D: /On=D: /MaxSize=UNBOUNDED. Błąd nadal występuje.

Moja diagnoza problemu: Wszystko wskazuje na to, że narzędzie rozbija się o sztywne limity mechanizmu Volume Shadow Copy Service na ukrytej Partycji Odzyskiwania (651 MB). Zgodnie z dokumentacją Microsoft, jeśli partycja ma powyżej 500 MB, mechanizm VSS wymaga aż 320 MB wolnego miejsca do wykonania migawki. Partycja Windows Recovery (WinRE) na moim dysku ma 651 MB, z czego same pliki odzyskiwania zajmują zazwyczaj około 500-550 MB. Oznacza to, że zostaje na niej zaledwie ok. 100 MB wolnego miejsca. Usługa VSS uderza w matematyczną ścianę, nie może utworzyć migawki i wywołuje błąd 0x80780048.

Moje pytania do specjalistów Microsoft:

1. W jaki sposób mogę pomyślnie wykonać obraz systemu za pomocą wbudowanego narzędzia, bez uciekania się do ryzykownych metod polegających na ręcznym usuwaniu lub rozszerzaniu partycji Recovery?

Czy istnieje oficjalna łatka naprawiająca ten znany "martwy punkt" w wymaganiach VSS dla nowoczesnych partycji odzyskiwania powyżej 500 MB?

Jeśli narzędzie jest uznane za całkowicie przestarzałe i nie będzie łatane, jak oficjalnie zaleca Microsoft zrobienie pełnego obrazu dysku (1:1) w systemie Windows 11 bez użycia oprogramowania firm trzecich?

Witam,

Zwracam się z prośbą o pomoc w rozwiązaniu krytycznego błędu wbudowanego narzędzia "Kopia zapasowa i przywracanie (Windows 7)" w systemie Windows 11. Próba wykonania pełnej kopii zapasowej (pliki danych + obraz dysku systemowego) za każdym razem zostaje przerwana z komunikatem o braku miejsca.

Kod błędu: 0x80780048 (Na dysku, na którym są zapisywane kopie zapasowe, jest za mało wolnego miejsca). Błąd wyskakuje zawsze w tym samym momencie – gdy program kończy kopiować pliki użytkownika (ok. 40 GB) i próbuje rozpocząć tworzenie obrazu systemu (migawka VSS dysku C: i partycji rozruchowych).

Mój układ dysków i wolne miejsce (tu nie ma problemu z brakiem przestrzeni):

Dysk docelowy na kopię (D:): 931 GB całkowitej pojemności -> ponad 510 GB wolnego miejsca.

Dysk systemowy (C:): 232 GB całkowitej pojemności -> ponad 65 GB wolnego miejsca.

Partycja odzyskiwania (Recovery): 651 MB.

Partycja systemowa EFI: 100 MB.

Czynności diagnostyczne, które już WYKONAŁEM (proszę nie powielać tych porad, ponieważ nie rozwiązują problemu):

Fizycznie i trwale usunąłem folder WindowsImageBackup z dysku docelowego, aby narzędzie miało "czystą kartę". Nie pomogło.

Zwolniłem ponad 60 GB miejsca na dysku C:, m.in. dostosowując rozmiar pliku pagefile.sys, wyłączając hibernację (powercfg -h off) oraz czyszcząc stare kopie w tle za pomocą Oczyszczania dysku. Nie pomogło.

Upewniłem się, że w skład obrazu systemu wchodzą tylko niezbędne partycje (zabrałem plik stronicowania z innej dużej partycji z danymi, aby Windows nie dołączał jej do obrazu).

Zdjąłem limity dla usługi VSS na dysku docelowym za pomocą komendy wiersza poleceń z uprawnieniami administratora: vssadmin resize shadowstorage /For=D: /On=D: /MaxSize=UNBOUNDED. Błąd nadal występuje.

Moja diagnoza problemu: Wszystko wskazuje na to, że narzędzie rozbija się o sztywne limity mechanizmu Volume Shadow Copy Service na ukrytej Partycji Odzyskiwania (651 MB). Zgodnie z dokumentacją Microsoft, jeśli partycja ma powyżej 500 MB, mechanizm VSS wymaga aż 320 MB wolnego miejsca do wykonania migawki. Partycja Windows Recovery (WinRE) na moim dysku ma 651 MB, z czego same pliki odzyskiwania zajmują zazwyczaj około 500-550 MB. Oznacza to, że zostaje na niej zaledwie ok. 100 MB wolnego miejsca. Usługa VSS uderza w matematyczną ścianę, nie może utworzyć migawki i wywołuje błąd 0x80780048.

_Moje pytania_

W jaki sposób mogę pomyślnie wykonać obraz systemu za pomocą wbudowanego narzędzia, bez uciekania się do ryzykownych metod polegających na ręcznym usuwaniu lub rozszerzaniu partycji Recovery?

Czy istnieje oficjalna łatka naprawiająca ten znany "martwy punkt" w wymaganiach VSS dla nowoczesnych partycji odzyskiwania powyżej 500 MB?

1. Jeśli narzędzie jest uznane za całkowicie przestarzałe i nie będzie łatane, jak oficjalnie zaleca Microsoft zrobienie pełnego obrazu dysku (1:1) w systemie Windows 11 bez użycia oprogramowania firm trzecich?
   Z góry dziękuję za merytoryczną i zaawansowaną pomoc techniczną. Proszę o pominięcie standardowych formułek typu "uruchom sfc /scannow", ponieważ system jest w 100% stabilny, a problem dotyczy wyłącznie archaicznej logiki wyliczania miejsca przez samą aplikację kopii zapasowej.