Değişen az sayıda dosya bulunan büyük klasörler için Time Machine davranışı ne bekleniyor?


4

Time Machine (APFS'li Yüksek Sierra MacBook Pro'da) bir klasördeki hangi dosyaların son yedeklemeden bu yana değiştiğini nasıl biliyor? TM'nin değiştirilmiş dosya (lar) içeren dizinleri izlemek için FSEvents'e güvendiğini biliyorum . Bilmiyorum, bir klasördeki 1+ dosyanın değiştiğini öğrendiğinde TM'nin yaptığı şeydir. Time Machine'in kendisi hakkında üst düzey bir bilgi değil, ayrıntılı bir teknik açıklama arıyorum. özellikle:

  • TM, hangi dosyaların son yedek sürümle aynı olduğunu belirlemek için her dosya hakkında (örneğin, değiştirilen 1 dosya ve son yedeklemeden bu yana 999 dosya değiştirilmemiş bir klasörde) hangi bilgileri kullanır? TM sadece dosya boyutu ve değiştirme zamanına bakar mı? Aslında dosya içeriğini okuyor mu? Dosya özelliklerini okuyor mu?
  • Time Machine, hangi dosyaların değiştiğini kontrol etmek için hangi dosya sistemi API çağrısını kullanır? Spesifik olarak, örneğin, bir dizin listesi getirmek için, klasör başına bir (veya az sayıda) çağrı yapıyor mu? Yoksa dosya içeriği, öznitelikler, vs. gibi ek bilgileri çekmek için dosya başına 1+ çağrı mı yapacak ?
  • Yukarıdaki soruların cevapları değişiyorsa (örneğin, "bazen TM XXX, bazen YYY olur"), o zaman TM'nin bir klasördeki değişmeyen her dosya için birçok dosya sistemi çağrısı yapmasının nedenleri nelerdir?

Soruyorum çünkü 2015 yılının sonlarındaki MacBook Pro'mda High Sierra çalıştıran yavaş Time Machine artımlı yedeklemelerini teşhis etmeye çalışıyorum. Her "saatlik" yedeklemenin tamamlanması, her seferinde yedeklenen veri miktarı 2 GB'ın altında olsa da tamamlanması 30 dakika sürer.

Time Machine disk etkinliğinin kayıtlarını inceleyen (kullanan sudo fs_usage -f filesys backupd), suçlu, Outlook 2016 Mac ile ilişkili değişmemiş mesaj ve ek dosyalarına dosya sistemi erişimi gibi görünüyor.

Outlook, iletiler için 256 klasör ve ekler için 256 klasör oluşturur ve yeni klasörleri ve ekleri eşit olarak bu klasörler arasında dağıtır. Örneğin, Outlook profilimde çoğu 1+ eki olan yaklaşık 250K ileti var. Bu 512 klasörün her biri yaklaşık 1.000 mesaj içerir. Günde yaklaşık 500 yeni mesaj alıyorum, bu nedenle son yedeklememden bu yana bir gün geçmişse, bu 512 klasörün her birinde 1-3 yeni dosya ve yaklaşık 1.000 tane değişmemiş dosya olacak.

Dosya sistemi günlüklerine bakıldığında, Time Machine her bir dosya için birçok dosya sistemi çağrısı yapıyor, ancak bu dosyalarda sadece 500.000 dosyadan birkaç yüz dosya değişti. Değişmeyen her bir dosya için dosya sistemi erişimi hızlıdır (aşağıdaki örnek günlükte ~ 0.075 saniye) ancak 0.075 saniye ile 500 bin dosyayı çarpın, 10 saatten fazla! Time Machine birden fazla iş parçacığı çalıştırır, böylece her artımlı yedekleme 10 saat sürer, ancak her "saatlik" yedekleme için 30+ dakika sürer.

Her saat değişmeyen 500.000'den fazla dosyaya bakmak için batarya kullanımı ve disk erişimi çok fazla. 30+ dakika kullandıktan sonra TM hızı olduğuna dikkat edin sudo sysctl debug.lowpri_throttle_enabled=0. Bu değişiklik olmadan, daha yavaş.

Sorunun kök nedenini anlamaya çalışıyorum:

  • Bilgisayarım böyle yapılandırılmış mı? Dosyalarımda, Time Machine ayarlarında vs. yapabileceğim bir değişiklik var mı? Bu, TM'nin her artan yedeklemedeki değişmemiş dosyaları inceleyerek çok fazla zaman harcamasına neden olacak mı?
  • Sorun, Outlook 2016 Mac'in iletilerini ve ek dosyalarını nasıl depoladığı konusunda temel mi, bu nedenle büyük ve etkin bir posta kutusuna sahip her Outlook kullanıcısı bu soruna mı sahip olacak? Örneğin, Outlook, TM'nin çok sayıda küçük dosya oluşturan diğer uygulamalara kıyasla Outlook'un dosyalarını incelemek için fazladan zaman harcamasına neden olabilecek özelliklerle olağandışı bir şey yapıyor mu?
  • Yoksa, bir klasördeki herhangi bir dosya değişmişse, TM'nin hangi dosyaların değiştiğini doğrulamak için her bir dosya için nispeten pahalı bir dosya sistemi çağrısı yapması beklenir.

İşte bir günlük örneği (son yedeklemeden bu yana değiştirilmemiş tek bir dosya için), Time Machine'in her değişmemiş dosya için çok fazla dosya sistemi erişimi yaptığını gösteriyor. Zaten yedeklenmiş olan ve son yedeklemeden bu yana değişmeyen bu 901 baytlık bir dosya için 11 (!!!) dosya sistemi erişimini sayıyorum.

09:14:19.783112  getattrlist                            .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000027   backupd.944294
09:14:19.783424  fsctl                                  .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000006   backupd.944294
09:14:19.783428  fsctl                                  .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000004   backupd.944294
09:14:19.783542  getattrlist                            .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000057   backupd.944294
09:14:19.783603  listxattr                              .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000016   backupd.944294
09:14:19.783612  listxattr                              .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000008   backupd.944294
09:14:19.805903  listxattr                              .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.022290   backupd.944294
09:14:19.806028  listxattr                              .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000109   backupd.944294
09:14:19.856232    HFS_update               (__M__c__)  .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000013   backupd.948297
09:14:19.856258  link                                   .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.050019   backupd.948297
09:14:19.856394  getattrlist                            .Office/Outlook/Outlook 15 Profiles/2018-05-11/Data/Message Attachments/137/8969C57E-7F6D-4152-AF11-FDF535486C92.olk15MsgAttachment    0.000051   backupd.948297

Outlook klasörlerini Time Machine yedeklemelerinin dışında tutabileceğimi biliyorum, ancak iletileri geri yüklememi engelleyebileceği için bunu yapmakta tereddüt ediyorum.

FSEvents günlüklerini silmeyi çoktan denedim (yoluyla sudo mv /.fseventsd /.fseventsd.bakve yeniden başlatma yoluyla ) ve yeniden oluşturulmalarına izin verdim , bu da yedeklemeleri önemli ölçüde arttırdı , böylece yalnızca son yedeklemeden bu yana Outlook'u başlatmazsam birkaç dakika alacaklar. . Ancak Outlook'u çalıştırdıktan sonra yedeklemeler 30 dakika sürüyor. Ekstra zamanın yedek veri hacminden kaynaklanmadığını, yani 1.3GB Outlook.sqllitedosya her seferinde 1-2 dakika içinde yedeklendiğini ve bunun yerine 100.000 dosyadan kaynaklandığı gözüküyor. Time Machine bakıyor, ancak desteklemiyor.

Bu bir ağ sorunu ya da yedek NAS sürücümün hız sorunu değil: TM büyük dosyaları yedeklerken, WiFi üzerinden saniyede 10-30 megabayt yedekler (WiFi hızlıyım!). Ayrıca, doğrudan gigabit ethernet ağına bağlanmak, TM tüm bu küçük Outlook dosyaları arasında çalkalanırken hızı arttırmaz.

GÜNCELLEME:

Tarafından tavsiye edildiği gibi Monomeeth aşağıda onun cevabını ben indirilen ve ran Zaman Makinesi Mechanic (gerçekten yararlı bir araç!). İşte son 12 saatin çıktısı.

Analysis from 2018-05-23 19:38:58 +0000 to 2018-05-24 05:38:58 +0000 for 10 hours:
Backing up to /dev/disk2s2: /Volumes/Time Machine Backups/Backups.backupdb
on which there were 411.74 GB, 411.74 GB, 411.74 GB, 411.74 GB, 411.74 GB, 411.74 GB available.
Started 6 auto backups, and 0 manual backups; completed 7 backups successfully,
last backup completed successfully 7.0 minutes ago,
backed up a total of 16417 files, range 639 to 4666 in each backup,
total data for each backup was 2.09 GB, 2.1 GB, 1.89 GB, 1.58 GB, 1.66 GB, 1.59 GB, 1.54 GB.
Times taken for each auto backup were 93.8, 37.8, 29.8, 34.4, 35.4, 87.6 minutes,
intervals between the start of each auto backup were 140.5, 70.8, 63.4, 69.9, 65.9 minutes.
Created 0 new backups, and deleted 7 old backups,
cancelled 4 backups.
7 errors reported:
2018-05-23 13:27:42.967395-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-50 "paramErr: error in user parameter list" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-23-113921.inProgress/B14EC326-8AE7-4C23-8F37-17BDEFCF9F1C
2018-05-23 20:33:49.535143-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-36 "ioErr: I/O error (bummers)" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-21-163447
2018-05-23 20:33:49.536821-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-50 "paramErr: error in user parameter list" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-22-193257
2018-05-23 20:33:49.536960-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-50 "paramErr: error in user parameter list" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-22-183736
2018-05-23 20:33:49.537620-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-50 "paramErr: error in user parameter list" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-22-150607
2018-05-23 20:33:49.537704-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-50 "paramErr: error in user parameter list" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-22-134626
2018-05-23 20:33:49.539118-0700 Error: Error Domain=NSOSStatusErrorDomain Code=-50 "paramErr: error in user parameter list" deleting backup: /Volumes/Time Machine Backups/Backups.backupdb/Justin’s MacBook Pro/2018-05-22-120245

Derin tarama olmadığına ve her yedeklemenin 1.5-2 GB yedeklemesinin minimum 30 dakika sürdüğünü unutmayın. Boyutun çoğu, yaklaşık 10 megabayt / sn değerinde çalışan dosya sistemi günlüklerine göre yaklaşık 2 dakikada yedeklenen tek 1.3 GB Outlook.sqllite dosyasıdır. Ancak çoğu zaman (yine de dosya sistem kayıtlarına göre) 100.000'in üzerinde değiştirilmemiş dosyayı okuyarak / kontrol ederek alınır.

Bu normal mi? TM'nin hangi dosyaların değiştiğini (FSEvents aracılığıyla) bilmesi beklenir, ancak yine de her dosyaya bakması gerekir. Outlook'un dosyaları hakkında Outlook'un dosyalarında olmasına rağmen diğer uygulamaların dosyalarında olmamasına neden olan olağandışı bir şey var mı? Outlook, genişletilmiş öznitelikler kullanıyor olabilir mi (ör. "Yazar" ve "Alıcı" e-posta mesajı dosyalarındaki öznitelikler) ve bu öznitelikler yavaşlamaya neden oluyor mu?

Hatalardan ne yapacağımdan emin değilim, ancak yedekleri silmekten bahsediyorlar. Belki de bu yavaş yedeklemelerimle ilgisiz bir konudur.

Yanıtlar:


2

KISA CEVAP

Evet, bu beklenen bir davranış.

Time Machine yalnızca yeni veya değiştirilmiş verileri yedekler ve silinen verilerin kaydını tutar. Bu on (örneğin, Fotoğraflar Kütüphane) ve dizinleri / MS Outlook tarafından kullanılan olanlar) olarak dosyaları (çok miktarda klasör olarak diğer yerlerde (dosyalar binlerce içerebilir kütüphanelere sahiptir. Bu mu değil taze yedekleme yapmak Her değişiklik yaptığınızda tüm kitaplığı / klasörü değiştirir, ancak yalnızca değiştirilen öğeleri yedekler .. Time Machine'in bunu doğru şekilde yapması için, son yedeklemeden sonra neyin değiştiğini belirlemek için her öğeyi kontrol etmesi gerekir.

UZUN CEVAP

Time Machine'in çalışması, son yedeklemeden bu yana değişen her şeyi yedeklemesidir. Örneğin, şu bir dosya:

  • Son yedeklemeden sonra bir sonraki yedeklemede tekrar yedeklendiğinden beri düzenlenir.
  • Düzenlendi , son yedekleme beri yedeklenmiş bir sonraki yedekleme
  • Silinen son yedekleme beri dahil değildir (yani o yedekleme hiçbir kayıt yoktur, ancak dosya kendisi hala daha eski yedeklemeler için saklanır bunun bir parçasıydı) sonraki yedekleme

Şimdi, karışıklık genellikle Time Machine'in aslında bir yedekleme yapmasından kaynaklanıyor. Bunu aşağıda açıklamaya çalışacağım.

  1. İlk yedekleme TM yeni bir yedekleme sürücüsünde yapar, Mac'inizin tam yedeklemesidir. Eğer Mac'iniz 80GB'lık bir 1TB sürücü kullanıyorsa, ilk yedekleme yeni yedekleme sürücüsünde 80GB yer kaplar.
  2. Kalan tüm artımlı yedeklemeler tam bir yedekleme yapmaz. Bunun yerine TM yeni verileri (yani yeni eklenen verileri ve düzenlenen verileri ) yedekler ve silinen verilerin kaydını tutar .
  3. Paketler (örneğin, Fotoğraflar Kitaplığı paketi) gibi dosyalar söz konusu olduğunda, TM aşağıdakilerden herhangi birini tanımlayacaktır:
    • yeni veriler (örneğin , Fotoğraflar Kitaplığı paketinizin içindeki Master klasöründeki yeni fotoğraflar ) ve bunu yedekleyin
    • Modifiye veriler içinde geri bu kadar, Fotoğraflar Kütüphane paketi (örn Düzenlenen fotoğraf) ve
    • Silinen veriler dahilinde , Fotoğraflar Kütüphane paketi (Sildiğiniz örneğin fotoğraf) ve değişim kaydını tutmak
  4. Yedekleme diskinde boş alan kaldığında, TM bir sonraki yedeklemeyi yapabilmek için ihtiyaç duyduğu en eski yedeklemelerin çoğunu siler (ve bu, kullanıcıların daha yeni yedeklemelerin parçası olmayan verileri kaybedebileceği yerdir)
  5. İlk tam yedekleme mi, yoksa artımlı bir yedekleme mi olursa olsun, TM bunu kullanıcıya ayrı ayrı bir tam yedeklenmiş gibi gösterecektir. Bu, Kullanıcı Deneyimi (UX) tasarımına dayanarak tasarlanmıştır, böylece kullanıcıların verileri taraması ve bulması daha kolay olur ve kullanıcıların hepsine güvende olmalarını sağlamak için hareket eder. Elmaya Göre:

Tüm bu süreç, Time Machine'in yalnızca verilerinizi yedeklemesini sağlamakla kalmayıp, aynı zamanda belirli bir noktada nasıl göründüğünü de hatırlamakta ve böylece kullanıcıların aradıklarını bulmalarını kolaylaştırmaktadır. Elmaya Göre:

... Time Machine'i diğer yedekleme uygulamalarından farklı kılan şey, yalnızca her dosyanın yedek bir kopyasını saklamakla kalmaması, sisteminizin herhangi bir günde nasıl göründüğünü de hatırlamasıdır - böylece Mac'inizi geçmişte göründüğü gibi tekrar ziyaret edebilirsiniz.

Kaynak: Mac Temelleri: Zaman Makinesi (Apple bilgi tabanı dokümanı web arşivi)

Yani evet, bu beklenen bir davranış. Sorunuzdaki örneği kullanarak, saydığınız 11 örnek olmasına rağmen, bir araya getirilenlerin hepsi Time Machine'in işlemesi için bir saniyenin bir kısmını aldı ve benim açımdan bu zamana göre huzur ve kullanılabilirliğe değecek bir bakış açısına sahipti. Makine teklifleri.

Kısaca, buna müdahale etmeye çalışmayı tavsiye etmem.

[GÜNCELLEME]

Bu güncelleme, yukarıdaki üst düzey bilgilerin yerine geçmez, ancak OP'nin soru etrafında daha fazla bağlam sağlayan sorusunun gözden geçirilmesi nedeniyle daha fazla netlik sağlar.

Bildiğiniz gibi, Time Machine, hangi dosyaların son yedeklemeden sonra değiştiğini belirlemek için her birimde depolanan Dosya Sistemi Olayları (FSEvents) veritabanını kontrol eder.

Bununla birlikte, FSEvents veritabanı eksikse veya Time Machine, bozuk veya eksik olduğunu tespit ederse, derin bir tarama gerçekleştirir. Derin bir tarama yaparsa, bu , ilgili birimdeki tüm dosyaların (ve dizinlerin) en son değiştirilmiş zaman damgasını kontrol edeceği anlamına gelir . Bu derin taramanın bir parçası olarak Time Machine, son yedeklemeden bu yana değişen tüm öğelerin bir listesini oluşturur. Açıkçası, eğer uzak bir cihaza yedekleme yapıyorsanız (özellikle Wi-Fi üzerinden ise) bu gerçekten işleri yavaşlatır.

Eğer iken olabilir FSEvent bir birimde kayıt devre dışı, bu veri yedekleme Time Machine kullanmak isteyen çünkü yardım edecek değildir ve bu eylem sadece derinlemesine bir tarama gerçekleştirmek için zorlamak olacaktır.

Sağladığınız ek bilgiler ışığında, belirlemeniz gereken iki şey var:

  1. Time Machine her yedekleme yaptığında derin bir tarama yapıyor mu?
  2. Eğer öyleyse, neden bunu yapıyor?

İlk soruyu cevaplamak için Time Machine Mechanic'i (T2M2) indirip yükleyebilirsiniz . Bu, Time Machine yedeklemelerinin normal şekilde çalışıp çalışmadığını kontrol etmek için günlüklerinizi analiz eder.

Durumunuzdaki en önemli şey, T2M2'nin aşağıdakileri gösterip göstermediğini kontrol etmektir:

started 1 deep traversal scans

completed 1 deep traversal scans

Yukarıdaki aracın kullanılması, Time Machine'in aslında derin taramalar yaptığını gösteriyorsa, bu endişe kaynağı olabilir. Bu arada bir şey değilse, belli olaylardan sonra gerçekleşebilir (örneğin yakın zamanda başka bir birimden başlattığınızda, tam bir geri yüklemeden sonra, bir güç kaybını takiben, vb.), Ancak her zaman oluyorsa zil alarmı zilleri. Bu durumda, sizi Time Machine - Common Backup Mesajlarında Sorun Giderme'ye yönlendiririm .


Merhaba @ Monomeeth - cevabınız için teşekkürler ama aslında Time Machine'in bir klasördeki hangi dosyaların nasıl değiştiğine nasıl karar verdiğiyle ilgili daha ayrıntılı teknik bilgiler arıyordum. Ne aradığımı netleştirmek için sorumu güncelledim. Karşılaştığım sorun TM'nin çok fazla veri yedeklemesi değil, TM'nin hangi dosyaların değiştiğine karar vermek için çok zaman alması. Değişmemiş dosya başına 0.075 saniye, 500.000 değişmemiş dosya, 10+ saattir. Çok parçalı olduğunda bile, "saatlik" bir yedekleme için çok fazla 30 dakika var ... ve çok fazla boşa! İşleri hızlandırabilir miyim, anlamaya çalışıyorum.
Justin Grant,

@JustinGrant İlk önce bir APFS anlık görüntüsü verir ve ardından dosya özniteliklerini inceler. FSEvent'e asla güvenmediğini düşünüyorum.
mspasov

@ mspasov - Komik, başka bir yedekleme çözümünden Time Machine'e özellikle başka bir Ask Farklı cevabı nedeniyle değiştirdim: "çünkü 10.7 (Lion) macOS FSEvents adlı bir uygulamanın değişiklikler hakkında bilgilendirilmesine izin veren bir mekanizma sunar çok daha verimli bir şekilde iş yapıyor. Time Machine FSEvents kullanıyor. " apple.stackexchange.com/a/323718/61097 Matt'in cevabı yanlış mı? Yoksa APFS'deki TM'nin eski dosya sistemindeki TM'den farklı olarak çalışması (ve FSEvents değil anlık görüntüleri kullanması) mı?
Justin Grant

Üzgünüm hatalıyım. TM neyin değiştiğini bulmak için fseventd veritabanını kullanıyor ve veritabanının mevcut olmaması durumunda değişiklikleri tarar (ancak backupd fsevents cihazından canlı fsevent olaylarını kullanmıyor).
mspasov

@JustinGrant Yanıtımdaki gecikme için özür dilerim - mesajlarımdan bazılarını yakalamam beklenenden daha uzun sürdü. Cevabımı güncelledim - ekleyebileceğim başka bir şey varsa bana bildirin.
Monomeeth
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.