Unexpected size differences when using a Cloud Sync Task to copy a MacOS Time Machine sparse bundle

[keylevel]

I am using Cloud Sync Tasks to replicate parts of a pool to pCloud. This generally appears to be working, but I am concerned that the reported sizes are different when working with MacOS sparse bundles (especially those created by Time Machine).

For example, a Time Machine bundle is reported as taking 470GB on the TrueNAS share, but it is only reported as 194GB on pCloud.

I read somewhere that sparse bundles use hard links. Are these supported / handled by the Cloud Sync Task? Do I need to enable the "Follow Symlinks" option in the backup task?

 

[anodos]

I am using Cloud Sync Tasks to replicate parts of a pool to pCloud. This generally appears to be working, but I am concerned that the reported sizes are different when working with MacOS sparse bundles (especially those created by Time Machine).

For example, a Time Machine bundle is reported as taking 470GB on the TrueNAS share, but it is only reported as 194GB on pCloud.

I read somewhere that sparse bundles use hard links. Are these supported / handled by the Cloud Sync Task? Do I need to enable the "Follow Symlinks" option in the backup task?

There are generally issues with trying to use cloud sync tasks (and apps like syncthing) as a backup tool. Many remote providers do not support ACLs and xattrs, and so you will lose metadata. I would personally not treat them as a component of any mission-critical backup strategy, and I'm not sure there are such things as non-mission-critical backups.

If you're wanting to use this provider to back up your time machine sparsebundle, then you should snapshot the dataset, do a test restore, and check whether the volume still works. This is true in general of any data for which you wish to use cloud sync in this way.

 

[Patrick M. Hausen]

Alternatively take a snapshot, zfs send|receive said snapshot into a flat file on some other dataset, sync that dataset to a cloud provider. Pretty trivial to do an ad-hoc cron job that keeps e.g. the last 14 snapshots that way. The downside is that you don't save incrementals in the cloud but a full backup every time. So the viability depends mainly on your cloud storage cost.

 

[keylevel]

There are generally issues with trying to use cloud sync tasks (and apps like syncthing) as a backup tool. Many remote providers do not support ACLs and xattrs, and so you will lose metadata. I would personally not treat them as a component of any mission-critical backup strategy, and I'm not sure there are such things as non-mission-critical backups.

If you're wanting to use this provider to back up your time machine sparsebundle, then you should snapshot the dataset, do a test restore, and check whether the volume still works. This is true in general of any data for which you wish to use cloud sync in this way.

Thanks,

I think that all of the attributes and permissions should be ok as they are stored within the sparse bundle itself. It looks as if the file size difference is related to the way pCloud reports the size - when I copy the image back to my local machine, the size is the same as the original.

A full recovery run is planned before I consider this "working" ;-) Though I'll use a fresh install for that, so the file sizes (and therefore transfer times) are more reasonable.

The cloud backup is currently triggered manually, uses snapshots, and is only run after making sure that Time Machine on the client is disabled (to make sure the image is coherent).

 

[keylevel]

Alternatively take a snapshot, zfs send|receive said snapshot into a flat file on some other dataset, sync that dataset to a cloud provider. Pretty trivial to do an ad-hoc cron job that keeps e.g. the last 14 snapshots that way. The downside is that you don't save incrementals in the cloud but a full backup every time. So the viability depends mainly on your cloud storage cost.

Thanks, but I really need incremental support as I've not not enough bandwidth to keep pushing full backups to the cloud.