Need Help with a Backup Solution

Moderators: jhartley, MSR734, nola

Re: Link

Post by ilovezfs » Sun Apr 14, 2013 10:29 am

grahamperrin wrote:… supported but only for testing purposes.


ZEVO seems to work fine with file-based vdevs. Also, you could use Solaris 11 or Open Indiana to handle the file-based vdevs and still do your sending from ZEVO. Here's how to do it with multiple sparse files and encryption:
http://constantin.glez.de/blog/2012/02/ ... -zfs-pools

Without using file vdevs, you can still use file based backups by doing a zfs send, and directing the output to a file, as explained here:
http://docs.oracle.com/cd/E19963-01/htm ... gbchx.html

If you want some compression, you can even do this:
zfs send pool/fs@snap | gzip > backupfile.gz

Of course, the benefit of using file-based vdevs is the opportunity to use mirrors or raidz, and to be able to import them directly, rather than having to run zfs recv to access your data. Plus, it should take up less space.
ilovezfs Online


 
Posts: 249
Joined: Sun Feb 10, 2013 9:02 am

Re: Need Help with a Backup Solution

Post by raattgift » Sun Apr 14, 2013 4:50 pm

ilovezfs wrote:zfs send, and directing the output to a file


You could, but you should be aware that there is no data replication at all internal to such a file.

While it's safe enough in a well-replicated zfs pool, on any other type of file system (including a pool with no replication), any sort of data error that creeps in makes the entire file unusable. You cannot do a "partial zfs receive" - it's all or nothing, and the "all" must be entirely error-free.

The all-or-nothing nature also means you have to receive the whole stream before being able to extract a single file. Importing a pool whose storage vdevs are all file backed is MUCH faster and gives one the full access to the individual DMU objects through the various upper layers.

To clarify the "if you want some compression", the stream produced by zfs send is uncompressed, no matter what compression has been used on the dataset sent from. It's not a very space-efficient storage format.

Neither the old caveat about zfs send streams not being receivable by future zfs receives nor the advice to avoid using file based vdevs in practice matches up with the reality of any reasonably recent impelementation. People store the output of zfs send; people use file-based vdevs. It's unlikely that any of the zfs implementations will break the use of either. On the other hand, a substantial performance hit is a possiblity. (FIle-based vdevs are unlikely to have great performance, and they may also slow other things down too depending on the way caches like ARC and the UBC behave in practice; few implementations will take advantage of the opportunity to avoid memory-to-memory copying of the nested pages/blocks/records.)

Finally, there is likely a limit to the arbitrariness of the files; I wouldn't want to use vdevs whose files live in a FAT filesystem, for instance, nor would I want to use a pool with double-digit numbers of files let alone anything approaching the number of band files in a nontrivial sparsebundle.
raattgift Offline


 
Posts: 98
Joined: Mon Sep 24, 2012 11:18 pm

Re: Need Help with a Backup Solution

Post by raattgift » Sun Apr 14, 2013 5:49 pm

Oh, yes, also the backing file is just an array of octets; there's no magic framing. You could dd it directly onto a physical device and use the physical device instead; you can also copy the contents of a physical device into a file and use that. There *is* magic in discovering the "device", however, and ZEVO's cachefile-less implementation and Mac OS X's various mountpoint gotchas may bite you if the system reboots.[*]

Nevertheless, it's a handy feature for backups as above and in situations like where one is tackling a physical device and one has lots of storage space online and is willing to take a performance hit and some risks associated with additional complexity instead of having a vdev be in DEGRADED state for a while ("zpool {attach|replace} pool GPTE_... /file/name").

[*] This also applies to partitions/slices, Core Storage LVs, spaces managed by 3rd party volume managers, and so on. (Cache vdevs seem especially picky).
raattgift Offline


 
Posts: 98
Joined: Mon Sep 24, 2012 11:18 pm

Re: Need Help with a Backup Solution

Post by grahamperrin » Sun Apr 14, 2013 11:59 pm

I'd love a visual guide to bring together all the conceptual stuff that's explained in this topic … without reference to any particular backup utility or service. I mean, something to help people get their heads around the concepts, around the big picture.
grahamperrin Offline

User avatar
 
Posts: 1596
Joined: Fri Sep 14, 2012 10:21 pm
Location: Brighton and Hove, United Kingdom

Re: Need Help with a Backup Solution

Post by ilovezfs » Mon Apr 15, 2013 1:04 am

raattgift wrote:Finally, there is likely a limit to the arbitrariness of the files; I wouldn't want to use vdevs whose files live in a FAT filesystem, for instance, nor would I want to use a pool with double-digit numbers of files let alone anything approaching the number of band files in a nontrivial sparsebundle.

What is your concern about sparsebundles? They seem quite robust to me, especially since their purpose in life is to be the backing store for network-based backups.

Do you have the same concern about using sparseimage files?

And in terms of what you do think makes sense, do you prefer the use of a file made using dd, using mkfile, a dmg, a sparseimage, or something else?

Another approach would be to use, VMware as a hybrid solution. As far as ZEVO running inside an OS X VM is concerned, it is using real hard drives, which are in fact vmdks. You also have the option to use monolithic preallocated disks, which are really two files: a Virtual Disk.vmdk and a Virtual Disk-flat.vmdk, the former containing the configuration information for the disk, the latter being the actual "disk." You can even dd the flat file onto a real disk, provided you know how to navigate the partitioning issues.

**And you can still achieve replication by implementing mirrors or raidz/2/3 over multiple vmdks.**

This method seems to improve portability and to deal with the persistent naming issues, not to mention opening up the possibility of using VMware snapshots. And VMware Fusion 5 has built in support for enabling encryption of your VM, so you don't have to sacrifice the native encryption that sparsebundles offer.

Also, it is worth mentioning, of course, that it is standard practice to use virtual disks serving as "physical" vdevs in VirtualBox running Oracle Solaris.

Here is what a VMware preallocated virtual disk looks like under the hood (bonnet):

Code: Select all
Josephs-MacBook-Pro:vmdk-vdevs joe$ ls
ZEVOvdev0-flat.vmdk   ZEVOvdev0.vmdk
Josephs-MacBook-Pro:vmdk-vdevs joe$ cat ZEVOvdev0.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="monolithicFlat"

# Extent description
RW 4194304 FLAT "ZEVOvdev0-flat.vmdk" 0

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "261"
ddb.uuid = "60 00 C2 9b db dc aa 18-94 c5 03 bb 18 1a 5c 69"
ddb.longContentID = "7dcc7a56d31434334076aed6fffffffe"
ddb.virtualHWVersion = "9"
Josephs-MacBook-Pro:vmdk-vdevs joe$ hexdump -C ZEVOvdev0-flat.vmdk
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
80000000
Josephs-MacBook-Pro:vmdk-vdevs joe$


Be sure to use the tools in /Applications/VMware\ Fusion.app/Contents/Library/ when dealing with these disks. For example, you do renaming like this:

Code: Select all
Josephs-MacBook-Pro:vmdk-vdevs joe$ ls -l
total 4194312
-rw-------  1 joe  staff  2147483648 Apr 14 21:52 Virtual Disk-flat.vmdk
-rw-------  1 joe  staff         483 Apr 14 23:52 Virtual Disk.vmdk
Josephs-MacBook-Pro:vmdk-vdevs joe$ /Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -n Virtual\ Disk.vmdk ZEVOvdev0.vmdk
Renaming completed successfully.
Josephs-MacBook-Pro:vmdk-vdevs joe$ ls -l
total 4194312
-rw-------  1 joe  staff  2147483648 Apr 14 21:52 ZEVOvdev0-flat.vmdk
-rw-------  1 joe  staff         480 Apr 14 23:52 ZEVOvdev0.vmdk
Josephs-MacBook-Pro:vmdk-vdevs joe$

Notice the change in size of Virtual Disk.vmdk from 483B to 480B, since vmware-vdiskmanager has updated the info inside the file in addition to renaming it.

Another benefit to leveraging VMware is that you can choose to use preallocated virtual disks split in 2GB file, which is similar to a sparsebundle, but avoids the massive number of small files.

However, it is worth noting that the hdiutil man page says
HDIUTIL(1) wrote: By default, UDSP images grow one megabyte at a time.
Introduced in 10.5, UDSB images use 8 MB band files
which grow as they are written to. -imagekey
sparse-band-size=size can be used to specify the
number of 512-byte sectors that will be added each
time the image grows. Valid values for SPARSEBUNDLE
range from 2048 to 16777216 sectors (1 MB to 8 GB).

So actually, I think it is possible to avoid the massive number of small band files if you opt to use sparsebundles.
ilovezfs Online


 
Posts: 249
Joined: Sun Feb 10, 2013 9:02 am

Re: Need Help with a Backup Solution

Post by raattgift » Mon Apr 15, 2013 8:01 am

I don't have a problem with sparsebundles at all. I have a problem with a pool with as many files as vdev components as there are band files in a sparsebundle, or anything close to that number.

The backing store files are treated very differently by the sparsebundle and zfs subsystems.
raattgift Offline


 
Posts: 98
Joined: Mon Sep 24, 2012 11:18 pm

Re: Need Help with a Backup Solution

Post by ilovezfs » Mon Apr 15, 2013 8:12 am

So you do think it's OK to use an attached sparsebundle's block device as a vdev?
ilovezfs Online


 
Posts: 249
Joined: Sun Feb 10, 2013 9:02 am

Re: Need Help with a Backup Solution

Post by raattgift » Mon Apr 15, 2013 9:20 am

Sure, because zfs sees the sparsebundle as a single device, and probes, caches and schedules accordingly. The management of the demand-driven addition and removal of band files within the bundle is not performed by or even exposed to the zfs subsystem.

The point is that you don't want a pool with vdevs comprising hundreds (or thousands!) of files (or devices). You also don't want pools with hundreds of vdevs.

ZFS pools and hdid disk images are fundamentally different things, even if they look similar from the perspective of "well, you can mount things stored in them as volumes".

Is that clearer? I have the impression from your last two messages that I am not explaining this very well to you.
raattgift Offline


 
Posts: 98
Joined: Mon Sep 24, 2012 11:18 pm

Re: Need Help with a Backup Solution

Post by ilovezfs » Mon Apr 15, 2013 9:31 am

To the contrary, it's perfectly clear now. I was only originally thrown off by "nor would I want to use a pool with double-digit numbers of files let alone anything approaching the number of band files in a nontrivial sparsebundle." I had thought you were saying that you didn't like the idea of using an attached sparsebundle's block device as a vdev (or as a component "disk" of a mirror or raidz vdev).
ilovezfs Online


 
Posts: 249
Joined: Sun Feb 10, 2013 9:02 am

Re: Backblaze #48209 extended attributes are not restored

Post by ilovezfs » Tue Apr 16, 2013 12:39 am

grahamperrin wrote:Probably not an issue with ZEVO … a copy of my request to Backblaze:

#48209 extended attributes are not restored

Comparing an original (on the desktop) with a restoration from Backblaze (in a folder named ooh on the desktop):

Code: Select all
macbookpro08-centrim:~ gjp22$ xattr -l Desktop/Sophos.txt
com.apple.FinderInfo:
00000000 54 45 58 54 21 52 63 68 00 00 00 00 00 00 00 00 |TEXT!Rch........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020
com.apple.TextEncoding: UTF-8;134217984
macbookpro08-centrim:~ gjp22$ xattr -l Desktop/ooh/Sophos.txt


Is this an issue with restoration?

Or does Backblaze not backup extended attributes?

I had asked basically the same question:
Is there any way to get Backblaze to be able to backup and restore extended attributes (xattr)? If Backblaze doesn't keep my metadata in tact, it's basically useless to me.

They responded today:
Your request (#48204) has been updated.
adam, Apr 15 14:33 (PDT):
Hello,

At this time, Backblaze does not back up any Mac OS extended metadata.

Regards,
Adam

The Backblaze Team

I have replied:
Is this a feature on the horizon? CrashPlan backs up all OS X metadata, so it is certainly possible. What is the obstacle?


UPDATE:
And they have now responded...
adam, Apr 16 09:49 (PDT):
Hello,

At this time, it's been submitted as a feature request for our development team to consider for future versions of Backblaze. I do not have any further information than that.

Regards,
Adam

The Backblaze Team
ilovezfs Online


 
Posts: 249
Joined: Sun Feb 10, 2013 9:02 am

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: ilovezfs and 0 guests

cron