Sparsebundle and Dropbox

8Apples · Dec 12, 2014

I have an encrypted Sparsebundle that I keep in dropbox. I click it to mount it, put in the password, do a little work, and then I save work, close the documents and umount the image. Dropbox then uploads the few files that need upgraded. I have done this for a while now. One time however, I wasn't able to unmount the file. Something else was 'using' it not allowing me to unmount it. I closed everything I had open, checked spotlight to make sure it wasn't indexing it. Checked T M to make sure it wasn't backing it up. I finally forced an unmount hoping not to lose data. As it turned out, I didn't lose anything. My question is, if I had lost something, what would have been the best restore method? Could I have restored just one of those numbered files that dropbox uploads and would it have worked? I have started copying the sparse bundle to my local hdd after every use to be sure I have a true backup and do not lose files. These are critical work files encrypted for extra security, and shared on Dropbox for co-worker usage. Any thoughts on this would greatly be appreciated.

I mounted it, changed a few files, then unmounted the file. I then used rsync to copy only changed pieces to my local copy and checked, and the changes were not copied over. Perhaps an rsync error? I used:

Code:

rsync --delete -avh full/path/Dropbox/name.sparsebundle full/path/Documents/name.sparsebundle

This executed fine, but didn't reflect the changes on the local copy.

I'm looking for thoughts about a more robust failsafe method.

8Apples

chown33 · Dec 12, 2014

Maybe your full/path is wrong.

I mention this because a real absolute path would start with /, like this:

Code:

/Users/grumpy/Documents/something

This would NOT be the same as:

Code:

Users/grumpy/Documents/something

The leading / is significant.

You should probably run the rsync command with the -n (--dry-run) option, and then post the output, or make sure it does what you want to happen.

Maybe one of your rsync options is wrong.

Your command shows -avh. The last one (h) means "show help". This option is NOT the same as -H. Exactly what did you expect lower-case h to mean? Command line options are often case-sensitive.

In general, you might want to use the long option names, like --dry-run instead of -n, and post the exact command you used. The advantage of long option names is their meaning is much less obscure. For example, you wouldn't have confused --help with --hard-links.

8Apples · Dec 12, 2014

chown33 said:
Maybe your full/path is wrong.

I mention this because a real absolute path would start with /, like this:

Code:

/Users/grumpy/Documents/something

This would NOT be the same as:

Code:

Users/grumpy/Documents/something

The leading / is significant.

You should probably run the rsync command with the -n (--dry-run) option, and then post the output, or make sure it does what you want to happen.

Maybe one of your rsync options is wrong.

Your command shows -avh. The last one (h) means "show help". This option is NOT the same as -H. Exactly what did you expect lower-case h to mean? Command line options are often case-sensitive.

In general, you might want to use the long option names, like --dry-run instead of -n, and post the exact command you used. The advantage of long option names is their meaning is much less obscure. For example, you wouldn't have confused --help with --hard-links.

You are right about the path. When I typed it all in, I actually had the full path correct, and ran it with the -n first saw the output, and then ran it without the -n to actually run the command. It updated everything as I would have expected. It copied just a few of the numbers vs all the files. A sparse bundle is actually a folder with a bunch of files named as numbers usually. Only the ones that changed needed updated (thus the advantage of using rsync instead of copying the whole thing).

As for the -h it is not for help. In Linux, I think it is. However on Mac (unix based) it is slightly different. It stands for "-h, --human-readable output numbers in a human-readable format" Right out of the help file called with rsync --help.

Here is the exact line I used with username, and filename changed.

Code:

rsync --delete -avh /Users/username/Dropbox/SharedBox/name.sparsebundle /Users/username/Documents/name.sparsebundle

8Apples

8Apples · Dec 12, 2014

Code:

building file list ... done
name.sparsebundle/
name.sparsebundle/Info.bckup
name.sparsebundle/Info.plist
name.sparsebundle/token
name.sparsebundle/bands/
name.sparsebundle/bands/0
name.sparsebundle/bands/1
name.sparsebundle/bands/135
name.sparsebundle/bands/2
name.sparsebundle/bands/20
name.sparsebundle/bands/21
name.sparsebundle/bands/22
name.sparsebundle/bands/23
name.sparsebundle/bands/24
name.sparsebundle/bands/25
name.sparsebundle/bands/26
name.sparsebundle/bands/27
name.sparsebundle/bands/28
name.sparsebundle/bands/29
name.sparsebundle/bands/2a
name.sparsebundle/bands/2b
name.sparsebundle/bands/2c
name.sparsebundle/bands/2d
name.sparsebundle/bands/2e
name.sparsebundle/bands/2f
name.sparsebundle/bands/30
name.sparsebundle/bands/31
name.sparsebundle/bands/32
name.sparsebundle/bands/33
name.sparsebundle/bands/34
name.sparsebundle/bands/35
name.sparsebundle/bands/36
name.sparsebundle/bands/37
name.sparsebundle/bands/38
name.sparsebundle/bands/39
name.sparsebundle/bands/3a
name.sparsebundle/bands/3b
name.sparsebundle/bands/3c
name.sparsebundle/bands/3d
name.sparsebundle/bands/3e
name.sparsebundle/bands/3f
name.sparsebundle/bands/4
name.sparsebundle/bands/40
name.sparsebundle/bands/41
name.sparsebundle/bands/5
name.sparsebundle/bands/50
name.sparsebundle/bands/9
name.sparsebundle/bands/9a
name.sparsebundle/bands/a

sent 339.23M bytes  received 1.07K bytes  3.19M bytes/sec
total size is 339.19M  speedup is 1.00

Here is the results of running the command. So it is working. However the file that I edited was not changed when I mounted it on my backup file. Odd.

8Apples

chown33 · Dec 12, 2014

8Apples said:
As for the -h it is not for help. In Linux, I think it is. However on Mac (unix based) it is slightly different. It stands for "-h, --human-readable output numbers in a human-readable format" Right out of the help file called with rsync --help.

As it turns out, -h for help must be the ONLY option. When it appears with other options, it means human-readable output numbers. I misunderstood the output from:

Code:

rsync -h
...snipped...
(-h) --help                  show this help (-h works with no other options)

8Apples said:
... However the file that I edited was not changed when I mounted it on my backup file. Odd.

I don't understand what this means. Some file was edited, something wasn't changed, and something about a backup. It makes sense to you because were there and did it. Nobody else was, so you need to be specific.

List the exact steps you performed.
Explain what you expected to happen.
Explain what actually happened.

8Apples · Dec 12, 2014

Ok, let me try to clarify. I have a sparse bundle that is located in my Dropbox folder. That one is the primary file. The sparse bundle that is located in my Documents folder is a local backup file. I mount the Dropbox image (sparse bundle) and then modify a file on the image. I then unmount that image. Next I copy the image from Dropbox to my Documents folder with this rsync command:

Code:

rsync --delete -avh /Users/username/Dropbox/SharedBox/name.sparsebundle /Users/username/Documents/name.sparsebundle

A few posts previous you can see the results of the rsync command.
When I then mount the image in the Document folder, and look at the file that I previously had edited (on the Dropbox image) the file is not changed. I then unmount the image. I copy and paste with GUI the entire image from Dropbox to my Documents, and then mount it and check the file, and the edited file is then correct.

This is secondary to my first problem. My first problem is still hypothetical, but very similar. If my sparse bundle image on Dropbox ever gets corrupted because it was not unmounted properly. I can 'restore' files with dropbox. However Dropbox sees my sparse bundle as a bunch of files, not one big file. Apparently restoring 'chunks' of the image is NOT the same as restoring the whole image as one big file (like the copy and paste GUI method mentioned above).

Sorry if I haven't been clear, I'm working on a limited amount of time, with too many irons in the fire. And yet I want to make very certain I'm not going to lose data.

8Apples

chown33 · Dec 12, 2014

You should run a test without Dropbox in the picture. This is simply to limit the test to well-defined local disk operations.

First test:

Make a sparse image (Alice) in a local directory and mount it.
Put a file on the mounted image.
Unmount the image.
Run an rsync command that dupes the image to a different local directory (LookingGlass).
Confirm: When you mount the duped image, is the file on that image correct? (Is there a file, and does it contain what you expect?)
Dismount the duped image.

Next test:

Remount the Alice image.
Edit the file on Alice and save it.
DON'T unmount the Alice image.
Run an rsync command that dupes Alice to LookingGlass.
Confirm: When you mount the duped image, does the file on that image reflect the changes you made in Alice's file?

You could also run the md5 command on the band files in the sparse image, and see if they're identical for both Alice and its dupe. Do the same for your Dropbox image and your local copy. Differences mean that something isn't getting written to the band files when it should be.

If it were me, I'd probably keep the master sparse image in a local directory, and rsync it to Dropbox. Or maybe not; I'd have to run tests and confirm that Dropbox was playing well with rsync. I'd also make sure Time Machine (or some other backup tool) was keeping proper backups of the local sparse image.

I fully recognize the attraction of Dropbox (single unified storage in the cloud), but if it's not playing nicely with your data, and that data's integrity is paramount, you'll need to change something.

142857newbie · Mar 22, 2017

Isn't the problem that the syntax used is wrong? Shouldn't it be

# rsync options source destination

whereas it appears that 8apples has source and destination reversed, which also explains the error 8apples encountered, namely changes to the "source" don't show up in her "destination".

8Apples said:
Ok, let me try to clarify. I have a sparse bundle that is located in my Dropbox folder. That one is the primary file. The sparse bundle that is located in my Documents folder is a local backup file. I mount the Dropbox image (sparse bundle) and then modify a file on the image. I then unmount that image. Next I copy the image from Dropbox to my Documents folder with this rsync command:

Code:

rsync --delete -avh /Users/username/Dropbox/SharedBox/name.sparsebundle /Users/username/Documents/name.sparsebundle

A few posts previous you can see the results of the rsync command.
When I then mount the image in the Document folder, and look at the file that I previously had edited (on the Dropbox image) the file is not changed. I then unmount the image. I copy and paste with GUI the entire image from Dropbox to my Documents, and then mount it and check the file, and the edited file is then correct.

This is secondary to my first problem. My first problem is still hypothetical, but very similar. If my sparse bundle image on Dropbox ever gets corrupted because it was not unmounted properly. I can 'restore' files with dropbox. However Dropbox sees my sparse bundle as a bunch of files, not one big file. Apparently restoring 'chunks' of the image is NOT the same as restoring the whole image as one big file (like the copy and paste GUI method mentioned above).

Sorry if I haven't been clear, I'm working on a limited amount of time, with too many irons in the fire. And yet I want to make very certain I'm not going to lose data.

8Apples

Search

Search

Sparsebundle and Dropbox

8Apples

macrumors member

chown33

Moderator

8Apples

macrumors member

8Apples

macrumors member

chown33

Moderator

8Apples

macrumors member

chown33

Moderator

142857newbie

macrumors newbie

Our Staff