Varför slutar säkerhetskopieringen av telefonfoton när appen körs i bakgrunden?
Säkerhetskopiering av mobilfoton avbryts i bakgrunden när det mobila operativsystemet pausar appen eller när en misslyckad överföring hindrar nästa schemalagda batch.
Självhostade fotoappar får inte obegränsad körning i bakgrunden. iOS och Android avgör när appen får aktiveras baserat på behörigheter, batteristatus, nätverksförhållanden, senaste användning och belastningen på systemets resurser. Säkerhetskopieringen kan också fastna på en fil som inte stöds, en utgången inloggning, en server som inte kan nås eller ett original som endast finns i molnet och först måste laddas ned. Ta reda på om appen aldrig schemaläggs, startar och stannar eller upprepade gånger misslyckas med samma fil.
Bekräfta om säkerhetskopieringen fungerar när appen är öppen
Anslut telefonen till det vanliga Wi-Fi-nätverket, håll appen i förgrunden och övervaka antalet väntande filer, det aktiva filnamnet, överföringshastigheten och serverloggen. Då kan du bekräfta att autentisering, serveråtkomst, lagring och val av album fungerar innan schemaläggning i bakgrunden blir aktuell.
Immich-användare har rapporterat att uppladdningar stoppas omedelbart efter att appen lämnas, trots att inställningarna för säkerhetskopiering är aktiverade. Det utmärkande symptomet är att uppladdning i förgrunden fungerar men bakgrundsprocessen stannar.
Om säkerhetskopiering även i förgrunden misslyckas fortsätter du med att kontrollera serveradress, certifikat, inloggning, lagring och filspecificerade fel. Om säkerhetskopieringen fortskrider normalt i förgrunden låter du dessa delar vara oförändrade medan du testar operativsystemets schemaläggning och begränsningar.
Kontrollera behörigheter för bakgrundskörning och systemets uppdateringsinställningar
På iOS kontrollerar du Bakgrundsuppdatering, åtkomst till bildbiblioteket, åtkomst till det lokala nätverket när det behövs, notiser om appen använder dem samt Strömsparläge. På Android kontrollerar du batterioptimering, bakgrundsdata, obegränsad batterianvändning och om tillverkaren har en extra lista över appar som försätts i vila.
En iOS-rapport om Immich visar att appen upprepade gånger hävdade att Bakgrundsuppdatering var avstängd, trots att systeminställningen redan var aktiverad. Fallet visar att appen och operativsystemet kan visa olika status.
Stäng av och aktivera den relevanta behörigheten igen som en kontrollerad återställning, öppna appen på nytt och kontrollera att inställningen känns igen. Stäng inte av allt batteriskydd globalt; undanta endast fotoappen från optimeringen om plattformen kräver det.
Skilj normal mobil schemaläggning från ett jobb som har fastnat
Bakgrundsarbete är opportunistiskt och kanske inte startar omedelbart efter att skärmen släcks. Notera om säkerhetskopieringen återupptas senare, efter laddning, efter återanslutning till Wi-Fi eller efter att appen öppnats kort igen.
Android-användare har rapporterat att synkronisering i bakgrunden misslyckas trots att batterioptimering och begränsningar är avstängda, vilket visar att behörigheter i sig inte bevisar att schemaläggningen fungerar.
Använd ett litet testalbum med flera vanliga JPEG-filer. Om dessa filer så småningom laddas upp i bakgrunden fungerar systemets schemaläggare, och felet med hela biblioteket beror troligen på filstorlek, filtyp, nätverkets varaktighet eller köstatus.
Kontrollera om en misslyckad fil stoppar batchen
Öppna detaljskärmen för säkerhetskopieringen och identifiera det första filnamnet som upprepade gånger misslyckas. Notera filändelse, storlek, lagringsplats, redigeringsstatus och om telefonen kan öppna originalet utan att först ladda ned det.
Ett Immich-ärende beskriver hur säkerhetskopieringen stoppades när den stötte på filer med filändelsen .pic som inte stöddes, i stället för att hoppa över dem och fortsätta. Det centrala felet var att en fil som inte stöddes blockerade kön.
Flytta filen från det valda säkerhetskopieringsalbumet eller exportera den till ett format som stöds och försök sedan igen. Ta inte bort originalet förrän det finns på en annan verifierad plats och resten av kön har slutförts.
Testa långsamma eller avbrutna nätverksförhållanden
Kontrollera om telefonen växlar mellan Wi-Fi och mobilnät, flyttar mellan åtkomstpunkter, förlorar anslutningen till VPN eller omvänd proxy eller låses under uppladdning av en stor video. Jämför ett litet foto med den största väntande videon.
Det har rapporterats att uppladdningar i bakgrunden stoppas efter att en långsam anslutning löpt ut och inte återupptas förrän appen startas om. Det relevanta mönstret är en tidsgräns som avslutar bakgrundsprocessen.
Testa med stabilt lokalt Wi-Fi via serverns lokala adress och därefter via det vanliga externa värdnamnet. Om lokal säkerhetskopiering fungerar men den externa fastnar undersöker du proxyns uppladdningsgränser, inaktivitetstidsgränser, TLS och växlingar mellan mobilnät.
Ta hänsyn till original som endast finns i molnet och optimerad telefonlagring
På telefoner som använder optimerad molnlagring kan den synliga miniatyrbilden representera ett original som inte längre finns lagrat lokalt. Säkerhetskopieringsappen måste först ladda ned originalet från molnet innan det kan laddas upp till hemmaservern.
En Immich-diskussion beskriver ett stort optimerat iOS-bibliotek där appen behövde ladda ned tiotusentals foton före dubblettkontroll och uppladdning. Detta skapar ett beroende av nedladdning från molnet som bakgrundsschemaläggningen kanske inte klarar av.
Låt telefonen laddas på ett stabilt Wi-Fi-nätverk och se till att det finns tillräckligt med ledigt lokalt utrymme under den första migreringen. Överväg att importera en officiell molnexport direkt på servern och använd sedan telefonsäkerhetskopiering endast för nya filer när det historiska biblioteket har verifierats.
Återställ endast det säkerhetskopieringstillstånd som bevisligen är inaktuellt
Logga ut och in igen först efter att du sparat serveradressen och bekräftat inloggningsuppgifterna. Rensa en fastnad uppladdningskö eller lokala appdata endast när appen erbjuder en återställningsväg som stöds och servern redan innehåller verifierade original.
ZimaSpaces guide om att säkerhetskopiera iPhone-foton till en hemmaserver beskriver den övergripande regeln att uppladdningen måste verifieras som slutförd innan original tas bort från telefonen eller molnet.
Problemet är löst när nya testfoton laddas upp utan att appen behöver hållas öppen, avbrutna överföringar återupptas, filer som inte stöds inte längre blockerar kön och bakgrundsprocessen förblir tillförlitlig vid laddning, Wi-Fi-byten, omstarter av telefonen och appuppdateringar.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.
