Re: [Burp-users] Backup to USB disk

[Graham K. <gr...@gr...>]

On Tue, Mar 07, 2017 at 12:14:34PM +0100, Alessandro Briosi wrote:
> 
> Il 06/03/2017 20:30, Tomasz Kontusz ha scritto:
> > Disclaimer: this is mostly guessing, but I'd like to get my knowledge 
> > checked ;-)
> Thanks for the info. (and for correcting the subject :D )
> >
> > Dnia 2017-03-06, pon o godzinie 17:21 +0100, alessandro pisze:
> >> Hi all.
> >>
> >> I have tested burp since sometime now, and it seems pretty stable, especially appreciate the VSS support for windows guests.
> >>
> >> In some situations I'd need to save the backups to USB disks during night, and let the user change the USB disk when it requires it (ususally once a week).
> > Is that the main storage location for those backups?
> > I don't know about protocol 2, but the way protocol 1 works you can 
> > just mount the USB drive at the backup storage location 
> > (/var/spool/burp on Debian) - burp should just do a full backup after 
> > that. The one thing to check is if you need to restart the burp server 
> > after removing that data - I'm not sure what is cached by the server.
> >
> Yes, it's the main backup storage. It's supposed to be swapped and put 
> in a safe location, so to protect it from fire or thiefs.
> Of course, as I know when I'll start the process I could start the 
> server and the backup after mounting the USB drive, though what about 
> the umount?
> 
> >> Right now I simply use rsnapshot with a mount and umount command before the launch at a certain time.
> >>
> >> Though having burp a server (with a repository directory) I'm not sure this can be done, and how.
> >>
> >> Probably I would need to force the backup from the server so to be sure that the USB disk has been mounted and once all the clients have been backed up umount it.
> > I'm not sure unmounting the disk while no backup is running will work 
> > - burp has to access that data to know if a new backup is needed.
> > Actually, I think you can just leave the USB stick mounted (assuming a 
> > journaling FS) and run `sync -f /var/spool/burp` after backup just to 
> > be sure.
> > Most FSes won't lose data that was not being written when the USB disk 
> > was removed, so you should lose at worst the ongoing backups.
> >
> Well, I'd really would want to avoid having the disk mounted while it's 
> being removed.
> >> Any suggestion on how to set this up would be appreciated.
> >>
> >> Is there a preferred/optimized FS for the backups (EXT4, XFS, ZFS) ?
> >> Also would there be any problems in using a NFS storage for backups (thinknig about a NAS)
> > I haven't tried NFS, but I can confirm CIFS works :-)
> 
> CIFS even for UNIX backups? What about 2 files with the same name but 
> one Uppercase and the other lowercase?
> 
> Alessandro

Hello,

One of the initial goals for burp was to make it not keep backup states that
are not part of the content of the backup storage directory. I saw this as
a big problem with bacula disk-based backups. This means that, as long as
you don't switch disks while a backup is running, you are safe.

This will work for both protocol 1 and 2:

a) Make sure the burp server is not running.
b) Mount the USB stick at /var/spool/burp (or wherever the 'directory' option
   is pointing to).
c) Make the burp server run again, and wait for backups to happen.
d) Make sure the burp server is not running.
e) Unmount the USB stick.
f) Remove the USB stick.

In protocol 1, you could also mount the USB stick at a particular client's
location, like /var/spool/burp/testclient.
In protocol 2, you could mount it at a particular dedup_group's location (but
not per-client), like /var/spool/burp/global.


An alternative could be to mount your USB completely separately, and rsync the
backups to it.



I use ext4 for my backup file system and would therefore recommend it.
I can't vouch for any others.

I don't trust NFS or CIFS to do certain operations atomically that the burp
code expects to be atomic. This may be prejudice on my part, and they might be
fine. I have no idea about case sensitivity with CIFS. In short, the burp
code expects a proper filesystem for its storage. That means symlinks,
hardlinks, case sensitivity, posix conformity.