We document our existence more than ever and create countless records of our lives through photos and written content on our computers, phones and tablets. Important paperwork is often digitized and stored on encrypted hard drives, not printed, placed in binders, and locked away. It is evident that in today’s world, many of our most valued possessions exist as zeros and ones. Throughout any given day, we are likely to reach for things in the digital realm more often than the physical space, be it a note, a recipe, or entertainment.

Known are those stories of people losing decades of memories because that one hard drive decided to call it quits - the digital equivalent of having your house burn down. While much of our data may not hold any value past our lifetime, we nevertheless want to ensure that the digital aspects of our lives persist for as long as we are around.

The aim of this article is to present insights for successfully implementing a complete backup routine. It is not a tutorial with step-by-step instructions, but rather considerations for pragmatically backing up our devices and mitigating worst-case scenario data loss. Since my own computing activities predominantly take place within Apple’s walled garden, the examples will often reflect that, but the general concepts discussed remain applicable to any other ecosystem of devices.

The following text covers the learnings gained from creating an almost entirely automated, “set it and forget it” backup strategy for all the devices in the household.

Eventually All Will Die

The cloud backup and storage service Backblaze has since 2013 been compiling statistics on hard drive failures across various models and drive sizes, with the most recent report for 2023 relying on data collected from close to a quarter of a million drives installed in their data centers.

Early Backblaze analysis suggested failure rates that followed a bathtub-shaped curve, or an inverted bell curve, characterized by a higher initial failure rate due to factory faults followed by a decline to a constant rate of random failures, and after an extended time, an increase in failure rate again because of wear and tear. With more time and larger sample sets, the hard drive failure rate has been shown to reassemble more of a hockey stick curve with significantly fewer initial failures that are more consistent with the constant failure rate.

This trend could be attributed to higher quality controls, where manufacturers deliberately have strived to reduce the failure rate and the number of dead-on-arrival drives. Regardless of which graph, a takeaway is that if a drive doesn’t fail within the first weeks of purchase, it is highly likely to run smoothly for a good couple of years until, one day, it eventually gives in.

The Backblaze failure rate graphs represent mechanical hard drives, which are the drives in focus for this backup setup. However, it is worth noting the difference in the way mechanical drives and Solid State Drives (SSDs) fail.

Mechanical Drive Failure

Conventional mechanical hard drives consist of moving parts such as actuator arms and spinning platters that wear out over time from normal usage. There is no sure way to predict when a mechanical hard drive will fail, although sometimes, indicators like out-of-the-ordinary sounds, increased heat output and slow performance can alert us to potential issues.

Instead of trying to gauge a hard drive’s health solely based on empirical observations, we can employ so-called S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) tests to help forecast imminent failures. S.M.A.R.T. tests are a set of self-diagnostics that a hard drive performs to gather information about different attributes, such as the number of terabytes written, total power-on time, and, more importantly, reports on bad sectors.

A bad sector is a section of the hard drive that has gotten corrupted and no longer reads or writes data properly. Getting some bad sectors over time is expected, but if they start accumulating, it is time to replace the hard drive while it still remains functional. S.M.A.R.T. tests will notify us once the number of bad sectors reach a critical threshold.

Solid State Drive Failure

Mechanical drive failures are only statistically predictable, and we often don’t receive any warnings until a random failure has already occurred. SSD drives, on the other hand, have a finite number of write cycles, and when they reach this limit, they are at risk of failure. This gives SSDs a calculated lifespan determined by the total terabytes written (TBW). Manufacturers sometimes advertise this information in their datasheets. If we look at Samsung’s 870 EVO 1 TB SSD, the specifications for that drive rate it with a 600 TB TBW limit or a 5-year warranty, whichever comes first.

SSDs fail in a fundamentally different way than mechanical drives. The wear issues of an SSD are not related to moving parts but to the insulating layer inside the transistors that store the bits. This insulating layer deteriorates over time, leading to an increase in bad sectors.

Because TBW gives us a hint on life expectancy, we can roughly estimate how long an SSD can be safely relied on. As an example, examining the S.M.A.R.T. output of the internal 256 GB SSD in my Mac mini using the smartmontools utility reveals the following values for data read and written:

SMART/Health Information (NVMe Log 0x02)

...

Data Units Read:                    71,191,956 [36.4 TB]
Data Units Written:                 37,677,178 [19.2 TB]

...

I acquired this Mac mini roughly seven months ago, or 215 days, to be precise. In this time frame, a cumulative total of 19.2 TB has been written to the SSD, averaging around 91 GB per day and approximately 32.5 TB per year.

Apple does not disclose information about TBW, but by looking at drives of similar size from Samsung, Seagate and Western Digital, we can estimate a typical TBW range of 150 to 200. If the usage of the Mac mini remains consistent, it is reasonable to assume that the SSD will last for at least another four and a half years. In fact, it is highly likely to last far longer, as manufacturers’ TBW values tend to be quite conservative.

No Data Left Behind

Even if we meticulously care for our drives by taking extra precautions to prevent misuse and protect them from power surges, overheating, or other physical damage, there is no getting around the reality that a hard drive is ultimately a consumable. Most of us will not keep a watching eye out for S.M.A.R.T. alerts with the hope of catching bad sectors, or track metrics like write cycles. At best, our attention extends only to organizing the files on the hard drives, and we go about our days, assuming our files will be where we left them whenever we need them.

It helps to understand what makes a hard drive finite because it creates a sense of urgency to ensure that no data is left behind when the inevitable happens. It is worth reiterating: You need a backup!

The NAS

At the heart of this backup strategy is a Synology NAS (Network-Attached Storage), a key piece of hardware with two or more bays for hard drives, and from which data flows in and out over the network rather than via a host computer like on traditional internal or external DAS (Direct-Attached Storage) devices. The computer is never in direct control of the hard drives on a NAS. Instead, it communicates with the NAS, which, in turn, manages the hard drives and allows us access to storage over the network through Wi-Fi and wired internet.

A NAS is essentially a server, a computer in itself with its own CPU and operating system that enables powerful functionalities beyond just storing files. There are apps ready to be installed on the NAS for anything from streaming media to running containerized services and managing security cameras.

As with any server, a NAS can be made available over the public Internet and files accessed from anywhere in the world, effectively making it a personal cloud similar to Google Drive and other cloud vendors. We can achieve very cost-effective storage by populating the NAS with 3.5 inch mechanical drives that are purchasable at large sizes for a relatively cheap price per TB.

The storage capabilities and network accessibility makes the NAS central in an automated backup setup. A Synology unit such as the DS423+ and DS923+ that utilizes SHR (Synology Hybrid RAID), Synology’s proprietary alternative to traditional RAID, will provide the flexibility to scale storage as needed and help us achieve fault tolerance in the event of hard drive failure. But what exactly is RAID, and how does SHR differ?

A Brief Introduction to RAID

In the late eighties computer scientists recognized that hard drive performance and reliability could be improved by combining multiple drives to work together as one unit of storage in a redundant array of inexpensive/independent disks or RAID. A NAS leverages this technology, and a NAS with four drives installed will appear as one mounted storage device on a computer and not as four individual drives.

The level of data protection and the available storage depends on a combination of both hard drive sizes and RAID configuration. Let’s understand this interplay by taking a closer look at two common RAID configurations.

RAID 1: The data is mirrored across all individual drives in the array. RAID 1 prioritizes data protection over storage capacity. A NAS unit with two 8 TB drives and a unit with four 8 TB drives both have 8 TB worth of available storage while the probability of data loss decreases in the four-drive setup since RAID 1 gives us a fault tolerance of n-1. A RAID 1 configuration is typically used in a consumer NAS with no more than two drives where the replication of data helps withstand the failure of any one single drive.

RAID 5: The data is divided (striped) and spread across all individual drives in the array. RAID 5 requires a minimum of three drives where one drive worth of storage is used for parity computations. Parity is a calculated value based on the data in all of the drives but one with that one drive storing the result of the parity math. A NAS unit with four 8 TB will have a storage capacity of 24 TB. Each drive holds some parity, this distribution prevents all parity from being stored on a single disk, and RAID 5 allows us to reconstruct the data on any one lost drive as long as the remaining drives are still present.

The Parity Bit

To illustrate the theory behind parity imagine we have a cat.jpg file and for the sake of simplicity let’s say the file is made up of only three bits, 0 1 1. When writing cat.jpg to a RAID 5 with four drives those three bits get striped across the first three drives with drive one holding the first 0 bit, drive two holding the second 1 bit and drive three holding the third 1 bit.

Deriving the parity bit for storing on drive four is done by calculating the XOR (Exclusive OR, ⊕) of the bits on drive one, two and three. XOR is a Boolean expression where the output is 0 if two input values are the same and the output is 1 if two input values are different.

0 ⊕ 0 = 0
1 ⊕ 1 = 0
0 ⊕ 1 = 1
1 ⊕ 0 = 1

The XOR output of the bits on drive one and two is 1 (0 ⊕ 1 = 1) and the XOR output of that result and the bit on drive three is 0 (1 ⊕ 1 = 0). 0 is therefore the parity bit written to drive four.

This additional 0 bit will help us rebuild the RAID and restore the missing data of cat.jpg whenever one drive is lost. For example, if drive two fails, the striped data of cat.jpg is incomplete due to the absence of the bit stored on drive two.

DRIVE 1	DRIVE 2	DRIVE 3	DRIVE 4
0	?	1	0

The system enters a degraded mode because it lacks a necessary bit to retrieve cat.jpg. What is known, however, is that the absent bit must yield XOR calculations where the parity output is 0. If the RAID controller attempts to recover cat.jpg by inserting a 0 to replace the missing bit, the parity output would be 1.

DRIVE 1	DRIVE 2	DRIVE 3	DRIVE 4
0	0	1	1

This result is clearly incorrect, and the missing bit must be a 1. A degraded RAID will continue functioning, and files will still be accessible as missing data gets calculated on the fly. It is crucial to replace the failed drive as soon as possible and start rebuilding the RAID. If another drive fails, data is lost, as RAID 5 can only withstand a single drive failure at a time.

To guard against a second drive failure, we would need RAID 6. A RAID 6 configuration uses two parity bits instead of one and allows one more drive of fault tolerance, with the trade-off of losing the storage capacity of two drives. All RAID types other than RAID 0 offer various levels of fault tolerance. RAID 0 differs in that data gets striped across multiple disks without redundancy, a file written has bits on every single disk. If one drive fails, the entire array is compromised. RAID 0 has performance benefits but carries inherent risks in that all it takes is one single drive failure for data loss to occur.

SHR

Traditional RAID assumes uniform drive sizes across the array. If we mix drive sizes, the larger drives will operate as if they were the same size as the smallest disk. Upgrading the storage pool becomes costly since we need to upgrade all the drives simultaneously to gain any size advantages. In contrast, Synology Hybrid RAID (SHR) offers the same protection as traditional RAID while adding the flexibility to mix drive sizes without wasting storage opportunities.

Synology Hybrid RAID comes in two configurations: SHR and SHR-2. SHR provides a one-disk fault tolerance, comparable to RAID 1 when two drives are available or RAID 5 with three or more drives present. SHR-2 provides a fault tolerance level of two disks, similar to RAID 6.

Considering a four-bay NAS unit equipped with two 8 TB drives and two 16 TB drives, SHR will utilize all available space, whereas RAID 5 loses out on 16 TB, which is neither used for storage nor protection.

What makes SHR maximize storage capacity is its ability to extend RAID partitioning to multiple levels. After the initial partitioning, it uses any remaining storage from the larger drives to perform additional RAID partitioning. This cycle continues until there is no more storage left to partition.

	8 TB	8 TB	16 TB	16 TB	Usable Storage
1st RAID Group	~~8 TB~~	8 TB	8 TB	8 TB	24 TB
Remaining Storage	0 TB	0 TB	8 TB	8 TB
2nd RAID Group			~~8 TB~~	8 TB	8 TB

The table above presents a step-by-step breakdown of this process. The first RAID group gets established by using the smallest disk size among the default drives as the baseline storage for all drives in the group. This results in an array comprised of 4 x 8 TB. After allocating 8 TB of storage for protection, we have 24 TB of usable storage left. In a RAID 5 setup, this would have been all of our disposable storage. With SHR, this is not the case. Following the creation of the first RAID group, 2 x 8 TB of storage remains unused (subtract the storage in the first RAID group from the default drives). Repeating the process with this remaining storage, a second RAID group is formed based on the smallest disk size within the remaining storage, which happens to be 8 TB. After setting aside an additional 8 TB for protection, we gain the remaining 8 TB as usable storage.

This is as far as we get with this particular setup, as there is no more remaining storage after forming the second RAID group for further partitions. Nonetheless, we increased the usable storage from 24 TB to 32 TB, fully utilizing all 48 TB of the default drives with no wasted space when adding the 16 TB assigned for protection. Synology has an interactive RAID calculator on their website for estimating storage. Users can experiment with various drive configurations and RAID types to compare available disk space, space used for protection, and unutilized space.

In traditional RAID, the specific RAID type has to be decided during the initial setup phase and cannot be changed later, while Synology Hybrid RAID allows changing the RAID type down the line if needed. For instance, we could start with SHR using two drives and mirroring, then introduce a third drive for a one-drive parity setup, and later further expand the array by adding two more drives for an SHR-2 setup with two-drive fault tolerance.

Devices and File Management

To achieve an effective backup strategy we first need clarity on what data to backup where. As a starting point take stock of any active devices and establish file management practices on those devices. Active devices are the daily drivers, the computers, phones and tablets that hold all those important bits of our digital life. In my own day-to-day I am alternating between the following five devices:

MacBook Pro
Mac mini
iPhone 14 Pro
iPad Pro
External SSD

Without delving too deep into the intricacies of file management, the thing to keep in mind is to maintain consistency by adopting naming conventions and choosing a well-structured hierarchy of directories and subdirectories that makes conceptual sense and aligns with your workflows and then sticking to it. Knowing where files belong and their purpose makes us more deliberate with our data and minimizes the accumulation of obsolete files that otherwise would have us overspending on storage.

In my system for digital file management, files fall into one of four primary categories: documents, designs, photography, and source code. They are organized by category at the top-level or at a project level, with relevant categories as subdirectories.

Cross-Device Availability

Having any file accessible on any device is a non-negotiable. I never want to find myself needing something specific only to realize it’s stored on my desktop computer at home while I am by my laptop far from home. Likewise, I never want to second-guess which files I might need when deciding which device to grab. Fortunately, the expectation nowadays is for files to be readily accessible from anywhere, and thanks to the widespread popularity of cloud syncing services, accomplishing this has never been easier.

Personally, I leverage Google Drive and Apple iCloud for these purposes, and while they may appear interchangeable, there is a clear distinction in how they are used.

Google Drive is the go-to service for storing files that require manually selecting a storage location, such as PDFs, scans of physical documents, Adobe projects, and any Google Suite work. An installation of macOS comes with predefined folders for documents, pictures, music, etc. Instead of storing files in these default folders, we should create our own folder structure based on our organizational principles inside the Google Drive folder, which becomes available after installing the Google Drive Client. This Google Drive folder essentially becomes our new home directory. By cultivating a habit of confining files to this specific location, we prevent data scatter and ensure that work started on one device can seamlessly be picked up from another without worrying about whether a file got saved in a location that syncs to the cloud or not.

Another benefit of this approach is that it circumvents any annoyances with seemingly random files and folders created by applications, which bloat those system folders with their own data. By storing the data we create in a location untouched by anyone other than ourselves, we maintain control and achieve a clear overview of how files are stored and synced. Google Drive has a generous free tier, and with intentional file management, it is possible to remain within the free quota without having to pay for cloud sync.

Apple iCloud gets reserved for applications that natively use iCloud for syncing data, and where there is no option to choose a storage location ourselves. Any data written to the stock Apple productivity apps, such as Notes and Reminders, uses iCloud for accessibility across devices. The same applies to data from many third-party applications on Apple platforms that sync to iCloud. Attempting to circumvent this, if at all possible, typically leads to complicated workflows that are difficult to sustain, and it is better to accept these constraints or opt for alternative applications with more flexible storage options.

Like any rules, there are exceptions, and source code and photos fall into this category. Software projects reside on GitHub, a powerful platform for version control, collaboration and deployment. By storing code in public or private repositories, we keep off-site copies of our code and can pull any project to whichever computer we are working on. Syncing software projects to Google Drive is a bad idea due to the constant file changes, which will keep the sync engine running consistently and eat at the CPU.

Synchronization of photos is more complex and varies highly depending on the chosen solution and workflow for managing them. We will revisit photos once we have a complete overview of the backup strategy.

The Archive

As we progress through our computing life, projects we work on naturally reach completion, files that were once actively used may lose their relevance over time, and documents we can’t surely dispose of will start to pile up. Once a file becomes dormant, we should be clear on whether it has an expiration date after which it gets deleted or if we should hold on to it indefinitely. The files we chose to keep but don’t access regularly and which we might want to reference in the future should be placed in archive storage outside of our active devices.

The purpose of this archive storage is to preserve files for the long term and prevent the loss of valuable historical data over time while reserving the primary storage on our active devices for active projects and current files. Files no longer required for immediate access can conveniently reside in an archive folder on the NAS for retrieval only when necessary.

It is essential not to fall into the trap of using the archive as a dumping ground for general files we want to remove from our working machines to free up space. Archival data are only those carefully selected files that we clearly want or need to retain.

Risk Profiles

Synchronizing files across devices has the added benefit of creating a secondary copy of that data on the cloud provider’s servers. Google Drive and Apple iCloud can function as off-site storage but they should mainly be considered syncing and sharing services and not specialized backup solutions. Data synced to these platforms operates as a two-way street where any changes made locally get reflected in the cloud and vice versa. This makes files more susceptible to inadvertent deletions or overwrites.

While Google Drive and Apple iCloud should not be relied upon exclusively for off-site storage, they are perfectly suitable as complementary tools in a comprehensive backup strategy. As long as we acknowledge their limitations, they can still fulfill off-site backup needs and simultaneously reduce the cost and overhead of using and paying for both a cloud sync and a cloud backup service. To make an informed decision, we must first identify potential risks and evaluate how all pieces of our backup strategy interact to form a protection scheme that mitigates those risks.

Common causes for data loss include hardware failures, human errors, on-site disasters like theft and environmental hazards, or incidents involving ransomware and other forms of malware. Risk profiles should consider the likelihood, scope, and timeframe for a varying combination of these occurrences.

The probability of accidentally deleting an individual file is high, the impact of such an occurrence is limited to the file in question, and Google Drive and Apple iCloud offer a 30-day retention period during which any deleted file can be recovered. What characterizes the risk profile in such a scenario is a high likelihood, a limited scope, and an acceptable timeframe for both discovery and recovery. If, instead, we were to face complete destruction of the premise, the risk profile would shift to highly unlikely but extensive in scope, and with a good chance of recovery, as the destruction concerns hardware and not digital assets stored in the cloud.

The 3-2-1 Table

The exercise of defining risk profiles helps us shape our backup strategy. Not all files hold the same level of importance. With proper file management in place, we can easily identify critical data that requires full protection and distinguish noncritical data that doesn’t necessitate coverage for worst-case scenarios. Any critical data should adhere to the golden standard for backups, also known as the 3-2-1 rule: retain three copies of the data, two copies stored on different storage mediums on-site, and one copy kept off-site.

If we consider the previous four file categories as important enough for complete coverage, listing them in a 3-2-1 table will provide a visual representation of how data copies are diversified across various locations and reduce the risk of failing to safeguard essential data due to oversight.

Data	Medium 1	Medium 2	Off-Site
Documents	Computers and Mobile Devices	?	Google Drive and iCloud
Designs	Computers and Mobile Devices	?	Google Drive
Photography	?	?	?
Source Code	Computers	?	GitHub

The table also reflects our level of risk tolerance. While the current configuration may not address a situation in which all files are accidentally deleted from the cloud, going unnoticed beyond the retention period while a natural disaster strikes, the likelihood of this happening is exceedingly low and falls within an acceptable level of risk tolerance for most home users.

As indicated by the question marks in the table, there are still some details to work out regarding on-site copies on a second storage medium. Next, we’ll find out how to create full device backups with fine-grained control for point-in-time recovery.

Full-Device Backups

Aim for recurring and full on-site backups of any active devices. These backups should include all files already backed up off-site and any system files, preferences, and settings required for restoring a system to its exact state before a time of failure.

The NAS allows us to set up network shared folders with an allocated storage quota, and we can create a dedicated network share for each device to store its backup data. This will ensure that the data of all our active devices exists as two local copies that reside on different storage mediums, the devices themselves and the NAS, giving us failover from one to the other.

By assigning individual read and write permissions to different network shares, we can include devices belonging to anyone in the household while guaranteeing that each household member has exclusive access to their data and not others. With minimal setup and no efforts to maintain, even those in the family who may not be losing sleep over the prospect of data loss get their data secured.

Synology NAS systems have another benefit in that they include the Snapshot Replication application. Snapshot Replication protects against accidental file corruption, deletions, and damages caused by bad actors. It does so by regularly capturing snapshots of the file system on the network shares where the feature is enabled. The granularity of snapshots is configurable for each network share, with options for intervals as frequently as every 5 minutes, provided performant enough drives. The more snapshots we keep, the more restore options are available for rolling back and recovering files.

What mainly makes a NAS a critical component is that it eliminates the burden of manually connecting drives to perform backups, which often leads to neglect because it relies on us trusting ourselves to remember to regularly backup our devices. Instead, we can effortlessly stay connected to the NAS, using the SMB (Server Message Block) communication protocol for wireless access to all our network shares.

Time Machine

macOS comes with Time Machine, an integrated backup utility designed for incremental full-device backups of desktop and laptop Macs. Each Mac can have its own network share on the NAS as a Time Machine destination, and because the NAS is consistently running, Time Machine can work in the background to perform automatic backups as frequently as every hour. Time Machine offers a convenient and reliable method for restoring a Mac in the event of hardware failure or when purchasing a new machine. We can also traverse back in time to retrieve older versions of individual files or recover accidentally deleted files. The more space we assign for Time Machine, the more snapshots we have to fall back on.

I have found that setting the quota of a network share to twice the size of any given computer’s internal storage is sufficient for the once or twice a year I have to go back for a file, which also aligns with the recommended minimum for Time Machine. A 256 GB Mac mini would thus have a network share of approximately 520 GB to store incremental backups on. Once Time Machine reaches the storage limit, it replaces older backups with more recent ones. If there is no size cap on the network share, Time Machine keeps generating snapshots until it uses up all available storage on the NAS.

Desktop computers are usually consistently connected to the network, while laptops go on and off. Taking this into account, Time Machine can back up desktop Macs daily and laptop Macs every hour, where the more frequent backup schedule reduces the risk of missed backup opportunities. Introducing Time Machine to the setup gives us robust on-site, full-device backups of all computers.

Synology Drive

In the inventory list of active devices made earlier, there was this one external SSD that we also need to take into account. It is not uncommon to have peripherals, like supplementary drives, to keep files from taking up space on the main computers, and it is equally important to include these in our backups. Time Machine prioritizes backing up the internal drive on a Mac and disregards any external drives unless explicitly removed from the exclude list in the Time Machine settings. By adjusting this list, we can incorporate however many additional volumes, like the external SSD, in a Time Machine backup routine.

Not everyone would want to back up external drives as part of Time Machine for a specific Mac but instead keep external drive backups independent, with Time Machine reserved for backing up internal storage only. Including external drives increases the Time Machine backup time, and using an exclude list makes selectively backing up specific files and folders tedious because all files and folders, except those intended for backup, must be added separately to the exclude list.

As an alternative, we can look at utilizing Synology Drive. Synology Drive turns the NAS into a private cloud, comparable to Google Drive, OneDrive, or Dropbox, with the difference that the central repository for our data will be the NAS and not a cloud provider’s servers. A Synology Drive setup requires the Drive Server package and the Drive Client desktop application. The Drive Server runs on the NAS and gets installed through the Package Center, and this is where we enable which network shares should be accessible for the Drive Client to perform either sync or backup tasks of the client data.

For our intended purpose, the aim is backup tasks, which differ from sync tasks in that they are unidirectional. In a backup task, the contents of the client folders get copied over to the designated network share on the NAS. Files added directly to the network share won’t be mirrored back on the client, unlike sync tasks, which reflect changes both ways. To back up the SSD, we create a network share with sufficient capacity to accommodate the SSD’s content and enable it on the Drive Server. Using the Drive Client application installed on the computer where the external SSD is mounted, we can browse the file system and select the SSD volume as the backup source and the network share as the destination.

When setting up a backup task, we can define its frequency and run backups continuously whenever files change, schedule backups for specific dates and times, or manually trigger them from the Drive Client interface. To avoid permanently backing up file deletions or changes, the network share with the SSD backup data is configurable in the Drive Server settings to retain historical data and automatically rotate older copies by deleting them after a specified number of days, based on our needs. When coupled with Synology Snapshot Replication, we gain both version control and the capability to restore the entire network share from the latest reliable snapshot in case the SSD ever gets compromised by a malicious attack.

The iPhone and iPad Edge Case

By now, it should be apparent that our goal is to have complete transparency and control over our backups to guarantee no surprises during the recovery of lost data in case things go south. Unfortunately, when it comes to Apple’s mobile devices, there is currently no satisfactory out-of-the-box solution for backing them up by these requirements.

Apple encourages the use of iCloud for backing up our mobile devices. But as iCloud is primarily a syncing service, it is far from rich enough to be entrusted for backup purposes. Backing up solely to iCloud also means there are no local copies of the iPhone and iPad data. If anything goes awry with the iCloud backup, or if Apple changes its services in any way that affects our data, there won’t be a surefire method for recovery. There is, however, an alternative for achieving local, full backups by connecting the devices directly to a Mac and backing them up via Finder. Despite doing what we want, the way Apple has implemented it makes the solution less than optimal.

One major drawback is that Apple restricts these backups to the Mac’s internal SSD only and disallows the use of any external drives. Depending on the storage used on the mobile devices, this could require up to 1 TB and 2 TB of available space on the Mac for backing up a maxed-out iPhone and iPad, respectively.

To work around this limitation, we can make use of symbolic links. A symbolic link acts as a reference to another file or folder, forming a shortcut from wherever we create the symbolic link to the file or folder it references. By default, macOS stores iPhone and iPad backups in a folder named Backup at ~/Library/Application Support/MobileSync/Backup. We cannot alter the name and location of this folder, but we can create a new folder with the same name on a network share and then replace the original Backup folder with a symbolic link to the newly created one. By doing so, we trick the system into believing that it is storing mobile device backups on the Mac when, in fact, they are stored on the NAS and just referenced from the Mac.

There are some important caveats to keep in mind. This way of backing up mobile devices requires user intervention. It is the only part of the backup strategy where we need to remember to plug in and sync the devices at regular intervals by manually triggering backups from Finder. When the responsibility falls on the individual, there is always the risk that backups occur less frequently and might even cease altogether. We must also make sure that we mount the network share before initiating any backups. If it is unavailable, the system cannot reference the new Backup folder, and it will revert to storing the device backups on the Mac.

Returning to the 3-2-1 table and modifying it to reflect our approach for full device backups results in this updated version:

Data	Medium 1	Medium 2	Off-Site
Documents	Computers and Mobile Devices	NAS	Google Drive and iCloud
Designs	Computers and Mobile Devices	NAS	Google Drive
Photography	?	?	?
Source Code	Computers	NAS	GitHub

We have established on-site copies on the NAS as our secondary storage medium by backing up most file categories to the NAS using Time Machine, Synology Drive for external drives, and the workaround for overcoming Apple’s mobile device backup restrictions.

Photography

For many of us, photos constitute our most valuable digital assets. Almost everyone carries a smartphone camera, readily available for capturing anything from cherished moments to snapping pictures as reminders of something or someplace. It is not a surprise that photos can become the most space-hogging data on our devices.

In managing my photos, I use Apple Photos for everyday iPhone photography and turn to Adobe Lightroom for more advanced post-processing. Before getting into the specifics of each solution, it’s worth mentioning my overall approach to photo files and the three guiding principles that prevent collections from growing excessively and out of hand.

Sort Sooner Rather Than Later: Prioritize sorting photos soon after capturing them. Delaying this increases the chances that we never get around to organizing them. I typically review any captures immediately or, if I am traveling, when back at the hotel.
Be Relentless in What to Keep and Discard: Establish strict sorting criteria. It will make the review process efficient and leave us with a curated collection of only the best photos. I evaluate photos based on their value as memories worth preserving or on a subjective notion of quality and interest. If multiple photos capture the same memory, I aim to save only a handful that best represents that particular moment.
Schedule Regular Cleanups of Temporary Photos: Temporary photos and screenshots clutter the photo library. Developing a habit of regularly deleting such files conserves space and prevents noise that hinders collections from being streamlined and meaningful. Consider deleting screenshots used solely for sharing before they even reach the camera roll.

Adhering to these principles will ensure the responsible growth of our photo library over time while maintaining organization and control over long-term storage and backup costs.

Apple Photos

Photos captured with the iPhone are automatically stored and organized in the Apple Photos app, creating an ever-growing photo library. Considering the limited storage space on the iPhone, I don’t want it entirely consumed by tens of gigabytes of photos and videos. Apple addresses this problem with a clever solution for optimizing storage. When “Optimize iPhone Storage” is enabled in the Photos app, iCloud becomes the default storage location for full-resolution photos, while smaller thumbnail versions remain on the phone. By offloading storage in this way, we still maintain access to our entire photo library on the phone, and with a simple click on the thumbnail of a photo, we can have the full version automatically downloaded from iCloud on-demand.

Relying exclusively on iCloud for storing our full-resolution originals is not advisable. Since Apple Photos syncs its contents across devices, we can have the Photos app on the Mac store its library on an external SSD where it always downloads and retains the original photos and videos. This approach guarantees that there will always exist local copies of the full-resolution originals, and by selecting the external SSD as the default library location, we avoid depleting the premium-cost internal storage on the Mac and can designate as much storage as needed for our photos on a much more affordable SSD.

As the SSD is backed up to a network share on the NAS using Synology Drive, the original photos and videos are simultaneously copied to a secondary storage medium, fulfilling the backup diversification criteria.

These concepts apply to any other Apple devices sharing the same Photos library. An iPad would have its photo storage optimized, and so could a MacBook as long as one device is responsible for storing the full-resolution originals, like, e.g., an external SSD connected to a desktop Mac mini.

Lightroom

Lightroom is designed for the workflows of professional photographers and comes with great flexibility for managing photos. Unlike Apple Photos, which stores the original photos alongside the database within the Photos app, Lightroom segregates the database file holding all post-processing information from the actual originals. We can import photos from any source, and Lightroom will apply edits as long as the reference remains intact.

Referencing photos from random locations may eventually get out of hand. It is, therefore, good practice to choose dedicated storage exclusively for the untouched originals that will be processed in Lightroom. Photographers will often find themselves working with large-sized RAW images that have to be stored where space constraints are not an issue. Such demands alone justify investing in a NAS for anyone seriously into photography, and it could even be considered an indispensable tool for photographers.

Storing these RAW image originals in a folder on a network share eliminates any concerns about running out of space, thanks to the NAS’s abundant storage. This folder then becomes the centralized location referenced by the Lightroom catalog. For the Lightroom catalog itself, we can choose to store it on the main computer or an external drive. As it only contains metadata and information about the edits, its size will never be a concern.

Neither Lightroom nor Apple Photos supports storing their application databases on network-attached storage to avoid potential conflicts from shared storage access. Although access is limited to direct-attached storage, it is still possible to back up both the Lightroom catalog and Apple Photos library to the NAS. We can set Lightroom to create a catalog backup each time the application is closed. If the local catalog gets corrupted beyond repair, we can replace it with the latest working catalog by copying it from the NAS to our direct-attached storage.

If we store the originals on the NAS, we benefit from accessing them on any machine connected to the network share. The disadvantage to this is that these originals exist only as copies on the NAS, and we need to back them up to another drive. If network access is not needed, store the RAW image originals on an adequately sized external drive and back it up to the NAS for that second storage medium of peace of mind.

With this, we now have a plan for backing up photos and can fill in most of the fields for photography in the 3-2-1 table:

Data	Medium 1	Medium 2	Off-Site
Documents	Computers and Mobile Devices	NAS	Google Drive and iCloud
Designs	Computers and Mobile Devices	NAS	Google Drive
Photography	NAS and External Drive	NAS and External Drive	iCloud and ?
Source Code	Computers	NAS	GitHub

We still need a solution for off-site backup of the photos that don’t sync to iCloud, and we will address this as we delve into backing up the NAS itself.

Backing up the NAS

To complete this backup setup, we must address one remaining crucial aspect: backing up the NAS itself. While this article has outlined how a NAS makes an excellent device for consolidating backup data from other devices, these benefits also make the NAS a potential single point of failure. Additionally, the NAS may contain non-backup-related data exclusively stored on the NAS, like the Lightroom RAW photos or archived files discussed in the previous sections. If it were to fail, this data would not be recoverable from any other device.

A misconception is that populating multiple bays with drives and having one or more drives of fault tolerance is sufficient for full protection. This oversight fails to consider the time required to replace a failed drive and rebuild the RAID. This period could coincide with another drive, necessary for redundancy, failing and leading to catastrophic data loss. The entire NAS unit can also break down for one reason or another, and none of the RAID configurations will ever protect against fire, flood and theft.

Given the potential for storing vast amounts of data on the NAS, backing up a NAS cost-effectively can be challenging. Ideally, a copy of the NAS’s contents should be available off-site. When comparing prices for storing data on cloud providers, the annual cost (as of December 2023) for storing 8 TB of data is likely to exceed what most home users would find comfortable paying, even when opting for the cheapest alternative.

Data	Backblaze B2	AWS S3	Azure	Google Drive
8 TB	$576/yr	$2496/yr	$1997/yr	$2208/yr

Of course, Synology has considered this and has multiple options for backing up a NAS to different locations. By prioritizing cost over convenience, we can attain the desired security without breaking the bank. As always, the key to managing costs is to, first and foremost, be intentional with what data we choose to keep and avoid hoarding unnecessary files, only to find it a struggle to back them all up. In some cases, the cost of ensuring full protection for files might outweigh the downside of losing them in a potential worst-case scenario.

Hyper Backup

Hyper Backup is the Synology package used for backing up a NAS, and the most affordable backup destination is to simply make local backups on a USB drive. Not all data requires off-site copies, and this solution is perfectly suitable for such use cases. It can absolutely cover off-site needs if necessary in a workflow where the USB drive is permanently stored in a remote location, brought in periodically, e.g., monthly, for backup purposes, and then returned to its storage at another location.

If off-site backups are a requirement and the overhead of remembering and rotating USB drives poses too much of a risk, there is an option to backup to another remote Synology NAS. We can place this second NAS unit at a friend or family member’s house and backup as much or all of our data off-site without the concern of incurring hefty cloud service bills. There is a high upfront cost in acquiring an additional NAS and the necessary drives, but these costs are considerably lower than the expenses for storing large amounts of data in the cloud. It is possible to reduce the costs further by choosing a lower-end model or purchasing a refurbished unit.

We get precise control over which data on the NAS to include when configuring a Hyper Backup task. Hyper Backup is flexible enough to let us backup the entire volume, individual network shares, or specific folders within a network share, and we can even include or exclude files based on file type. This level of fine-grained control lets us backup different types of data using separate methods that are optimal for our specific needs.

Photo collections are likely to be the most critical data for most people, and the size of curated collections is probably within a limit where backing them up to the cloud remains financially viable. For this type of data, we could create a bucket on AWS S3 and configure Hyper Backup with permissions to write the backups into that bucket and set the task to only backup, for instance, the RAW photos stored on the NAS.

By going down this route, all NAS-stored photos will exist off-site on S3, and we can fill in the remaining off-site cell of the 3-2-1 table:

Data	Medium 1	Medium 2	Off-Site
Documents	Computers and Mobile Devices	NAS	Google Drive and iCloud
Designs	Computers and Mobile Devices	NAS	Google Drive
Photography	NAS and External Drive	NAS and External Drive	iCloud and S3
Source Code	Computers	NAS	GitHub

As already mentioned, S3 is by no means the only choice, this could equally well have been done by rotating an USB drive, albeit less convenient.

Some Hyper Backup options let us select between single-version or multiple-version backups. The single-version alternative retains only the most current backup, whereas, with multiple versions, we can decide how far back we want to keep backup data before it gets deleted. There is no compelling reason for single-version backups, as the storage used for multiple versions is configurable to consume only as much space as we are willing to allocate before recycling backups. With multiple-version backups, we get the benefit of versioning, which adds protection against malware and overwrites.

Testing and Verifying

Putting blind faith in that anything computer-related functions error-free will inevitably have us caught off guard when reality proves otherwise. No matter how much consideration and thought we invest in securing our data, there is no way to certainly know that our carefully crafted backup strategy works as expected unless it is tested, preferably before any disaster strikes and in a controlled scenario. We should never simply assume that our backups will be available when needed, and we must routinely verify their reliability to be certain about their effectiveness.

Backups can be subject to varying degrees of testing, with the most thorough method involving a full recovery from the latest backup for each restoration process in place. Such testing requires additional hardware for recovery because we don’t want to overwrite the data on our current devices. While full-scale testing might not always be practical or feasible, a good middle ground and complementary way of testing backups is to conduct regular data audits by restoring individual files. By affirming our ability to access the backup locations and validate the integrity of the data, we gain high-level confidence in the reliability of our backups and that files are as expected and usable.

Instead of randomly testing files, the priority should be on our most valuable data and making sure we can pull it from the backups to our current working system. Ultimately, these files matter the most, and it is crucial to know that our backups won’t fail us or leave us with partial data. For other files, it is sufficient to do a swift scan of our backup file systems to confirm nothing is out of place. Checking this is especially important for files stored in the cloud, as many cloud services stop syncing new data once we exceed the free or current paid quota.

The DSM (DiskStation Manager) operating system powering a Synology NAS has numerous notification options, including push notifications, emails, and even SMS, which we can set up to notify us of a wide range of issues that may arise. With notifications enabled, we can respond timely to potential hidden problems and prevent catastrophic failures that could occur if left unattended. Time Machine will, from time to time, verify the condition of backups stored on a network drive, and such checks can also be initiated manually by option-clicking within the Time Machine menu bar list to reveal the “Verify Backups” menu item.

It would be disheartening to realize that the systems we put in place to protect us failed in a critical moment, so let’s ensure our backups actually works.

A well-crafted and resilient backup strategy forms the foundation of a worry-free digital life, ensuring the security of our files and preserving our digital legacy. Throughout this article, we have explored ideas for integrating on-site and off-site backups by leveraging a NAS alongside powerful and versatile backup tools and techniques, striking a balance between accessibility and security. For successful long-term manageability of our data, we also need to take a proactive stance towards file organization to maintain a clear overview of what gets backed up and where and effectively keep files and costs under control. Implementing the proposed solutions will prepare us to recover from any unfortunate events, regardless of magnitude, without suffering data loss, and it equips us to support protecting the data of less tech-savvy household members, helping them achieve the same level of security.

The Backup Strategy

Table of Contents