> I think the errors you are having are relating to SMB not supporting various 
> meta data such as (some?) file flags. Below I will outline some options 
> regarding pushing backups to a remote SMB mount. I suggest as a first step 
> try changing your backup location to a DAS (directly attached storage) just 
> to see if this resolves the issue. This could even be a locally mounted USB 
> memory stick formatted HFS+.
> Approach #1 - Backup to a disk image located on the remote system :
> If you generate a virtual file system (disk image formatted HFS+J) on the 
> remote SMB file system. Then add a post hook which will mount this disk image 
> and a post hook which will unmount the disk image once the backup has 
> finished (example scripts are within the example LBackup configuration 
> directory : '/etc/lbackup/example_backup_config/resources/exmaple-scripts/'). 
> Finally, configure LBackup to backup to the virtual file system. This should 
> work and your backup files will be stored on the remote file system which is 
> mounted with SMB.
> Approach #2 - Backup to a local sparse bundle and then backup to the remote 
> system : 
> Generate a local sparse bundle (virtual file system, disk image, formatted 
> HFS+J) and add in the pre and post hooks as briefly outline above in the 
> 'Approach #1'. Once you have this locally mounting and un-mounting sparse 
> bundle ready, configure this virtual file system to be the as your backup 
> destination. Finally, add an additional post hook (which calls rsync to 
> update the image on your remote file system) or to start a backup chain (eg, 
> another instance of LBackup to update the remote images and keep previous 
> versions as well). 
> The advantage of 'Approach #2' is that you have a local copy of the data and 
> a remote copy. Using rsync to update the remote copy is normally quite fast 
> as only the updated bands will need to be synchronized. Essentially, once the 
> sparse bundle is on the remote file system you will be incrementally backing 
> up or updating the sparse bundle on the remote system from your local copy.
> If you require assistance with putting together a post action script to 
> update / backup the disk image to the SMB share then please let me know. 
> If you have ssh access and rsync on a remotly accessible system you could add 
> a third backup destination by utilizing the following script to update the 
> remote sparse bundle via SSH : 
> http://www.lbackup.org/synchronizing_disk_images_between_machines
> The script listed at the link above could be easily modified so that it will 
> synchronize to a local SMB mount rather than via an SSH. The online script 
> could be modified even easier. Attached is an example script which will 
> synchronize a local sparse bundle to a locally accessible directory. If you 
> have any problems getting this to work then just let me know.
> There have certainly been issues in the past using rsync from a ubuntu system 
> to a FAT, FAT32 or NTFS file system. I am unsure if this issue also exists 
> with Mac OS X. I would assume that it will also be problematic. As mentioned 
> above if you want to push your backups via SMB over the network then I think 
> using a sparse bundle is a good approach and the attached example post action 
> script will simplify the setup.
> Links to related sites discussing rsync failing to set flags :
> - http://ubuntuforums.org/showthread.php?t=290111
> - http://tinyurl.com/rsync-failed-to-set-file-flags
> There is another thread on the mailing list which explains some of the issues 
> with using an SMB mount as a backup destination directly. Quoted below is 
> related question from this thread. Following the quotation is a link to the 
> archived thread.
>> 3. symlinks and samba
>> ---------------------
>> My destination for the backup happens to be a mounted samba drive which 
>> lacks support of symbolic links. These occur in some situations of my source 
>> to be backed up.
>> Is there a standard way to deal with this situation?
>> (I think none of rsync's options satisfactorily handle this particular case: 
>> I would like to reproduce the exact same state from my backup. --links: With 
>> the target filesystem's lack of support for symbolic links, simple copying 
>> is not available.
>> --copy-links: Collapsing of links is not the same as keeping them verbatim)
> http://tinyurl.com/lbackup-discussion-smb-issue
> If you require assistance with implementing this or just have questions about 
> the approaches mentioned above then please let me know.

FYI : LBackup 0.9.8r5-alpha6 has been released. It is possible to download the 
latest alpha release from the following URL  

Please keep in mind that the link listed above is temporary and will expire.

This latest alpha release has changes within the, example_backup_config : 

Once you have installed this latest alpha release, and copied the example 
backup configuration : 
> eg : 'cp -a /etc/lbackup/example_backup_config 
> /etc/lbackup/my_test_backup_config'

You will find there is an initialization script within the resources directory 
> resources/initialization-scripts/disk_images/darwin_initialize_disk_image_pre_and_post_hooks.bash

Running this script and passing in the path to a disk image as the first 
argument, will dynamically generate the pre and post action scripts to mount 
and unmount the specified disk image.

This is relevant to this thread because if you generate a sparse bundle either 
locally or on the remote SMB share, and then run the 
'darwin_initialize_disk_image_pre_and_post_hooks.bash' and pass it the path to 
the disk image the mount and unmount pre and post hooks will be dynamically 
generated for this disk image. Then you may switch your backup destination to 
the mounted disk image and you should find that your backup will work.

Please keep in mind that the 'vsdbutil' command should typically executed to 
enable the permissions for any backup destination partition (including virtual 
file systems) provided you have access to an admin account. Further details are 
available from the following URL : http://www.lbackup.org/permissions

The longer term goal of the initialization sub-system is offer a number of ways 
to automate the creation of a backup configuration directory and also the a 
backup destination (disk image).

Should you have any questions, comments or additional initialization scripts to 
submit to the LBackup project then just reply.

lbackup-discussion mailing list

Change options or unsubscribe :

Reply via email to