UrBackup Server/Client/Restore 2.0.0 beta was recently released. This marks the beginning of the UrBackup 2.0 beta phase.
See the forums for download links and discussion.
UrBackup 2.0 marks the beginning of UrBackup having no major limitations. If you still find some please start a discussion in the forums. The next beta version will also properly support sparse file backup.
Letsencrypt is in public beta now. As promised I switched the main page as well as the download site to SSL. The main page redirects to HTTPS and therefore cannot be accessed without SSL anymore.
The Letsencrypt certificate causes the main page to not work with Windows XP anymore. That are 2,6% of all visitors to that page. They are working on a fix for that issue, though. Let me know if there are any other problems.
By always being on a SSL-protected site you can be certain you are getting the official UrBackup binaries even if an attacker is able to modify your network traffic.
Currently the next major UrBackup version is kind of close to getting finished. There are a few major work in progress areas. Once they are finished and I have done some overall testing I will release a beta version.
The major changes in the new version are:
Still to do:
Remaining UrBackup limitations (to be done after with a subsequent version):
Once the “to do”s are done this is a big step forward for UrBackup. Having streaming file backups and incremental, differential, synthetic full and full image backups basically allows you to implement pretty much every backup strategy with UrBackup. The only thing missing is the continuous file backup and I already started work on that.
For example you could use UrBackup instead of TimeMachine on Mac OS X and do a full system restore via the file restore feature (this is not implemented at all – it is just an example what it might be able to do). You probably don’t even need an image of your Windows system partition but can restore it via the file backup restore (albeit inefficiently, because the hard links in C:\windows\winsxs are not handled properly).
Currently UrBackup is storing images of volumes as VHD (Virtual HardDisk) files. In UrBackup Server 1.4 the VHD file format was augmented with a custom compression. This combination gives following advantages over storing images as „raw“ files:
All this can be implemented with btrfs. Volume images can then be stored as raw files:
An incremental image backup can then be done like this: Create reflink of the last image backup, change the parts in the image file that have changed since the last image backup and then punch holes into the file to remove unused parts.
As you can see, this moves the implementation of compression, sparse image support and differential image support into btrfs, which is a good thing, because btrfs is starting to get widespread adoption.
The implementation using btrfs has several advantages:
The only disadvantage I saw till now is that UrB
ackup cannot accurately display the size of incremental image backups anymore. It always shows the size as if it was an uncompressed full image.
This new image file format will be available in UrBackup 1.5 if UrBackup is configured such that it uses btrfs.
If you are planning on setting up a larger UrBackup server instance you will find some hints about performance in this post. “Large” in this context is difficult to define, because it depends on the number of clients, the number of files and file sizes in the backups and the backup intervals.
If you plan on setting up a “larger” UrBackup instance you should keep the following things in mind:
Your system will almost certainly be IO limited. If you have a running system you can verify that by looking at the performance monitor on Windows, iostat on Linux and zfs iostat on FreeBSD. Often it is limited by random read/write performance (Input/Output operations per second).
If you want maximum IO performance following should therefore be the case:
Ways to absolutely kill performance:
Because the file transfer in UrBackup 1.4 was changed, I wanted to test it with a second layer: During the file backup a Python script which goes over all files in all backup paths on the client, selects a random subset and calculates the md5-sums of this random subset. On the server those md5-sums are then verified.
Turns out file tree walking in Python on Windows has a few issues.
First of all, even though the os.walk function has a „followlinks“ parameter, this parameter does not work on Windows with Junctions. In particular it followed the compatibility junctions in the C:\Users\Username folder causing an infinite loop, till the file system complained about the path length (32k). Usually this is not an issue, because users seem to not have the permission to use those junctions, but the UrBackup client backend is running as a SYSTEM-service.
os.path.islink returns False for those junctions.
os.path.realpath does not return the target path of the junction.
To solve this I had to install the Python for Windows extensions and manually call the respective API functions. The Python for Windows extensions does not define the FILE_ATTRIBUTE_REPARSE_POINT file attribute constant. So I had to use the value explicitly. Solution:
def is_reparse_point(path):
try:
attrs = win32file.GetFileAttributesW(path)
return attrs & 1024
except:
print("Error with GetFileAttributesW with dir "+path)
return False
def get_all_files(path):
output = []
for root, dirs, files in os.walk(path):
for name in files:
output.append(os.path.join(root, name))
torm = []
for cdir in dirs:
if is_reparse_point(os.path.join(root, cdir)):
torm.append(cdir)
for cdir in torm:
dirs.remove(cdir)
return output
Current hard linking incremental file backup schema
Currently files which are unchanged between incremental file backups are hard linked. This means there exist more than one file paths for the same data. The advantages are
But there are some issues in some cases:
With a lot of unchanged files between incremental backups it is almost certain the hard linking operation is the bottleneck.
To improve this situation UrBackup server 1.4 will create symlinks to large directories which are completely unchanged during incremental backups. This avoids a lot of the hard linking operations.
Symlinking large unchanged directories to a pooled directory
If, during incremental backups, a large unchanged directory is detected it is moved into a client specific directory pool. Then a symbolic link in the current and last backup to the directory in the pool is created. If the last backup already contains a link to the pool a symlink in the current backup is created to the pooled directory. Because the operating system does not count how many symbolic links point to a directory, the number of symlinks per pooled directory is saved into UrBackups internal database. If a backup is deleted and has symlinks the relevant entries in the database are removed. If there are no entries for the directory in the database the pooled directory is removed.
There are some caveats:
The symbolic linking of large unchanged directories will be the default behavior in UrBackup server 1.4, though you will be able to deactivate it in the advanced settings. UrBackup server will not symlink directories on btrfs, as there the snapshotting provides a superior method to do fast backups.
I moved the blog from Sourceforge to a different server, because the spam detection plugins of WordPress do not work on the Sourceforge webspace. The comments should work now. Sorry for the inconvenience.
It has been a while and there are now a lot new features in UrBackup Server 1.3.
Users of the web interface can download a Client specific installer directly from the server now. The installer has the UrBackup Server information embedded, such that the client automatically connects to the server once it is installed. I’ve also published a script that connects to a UrBackup server, creates a client named like the local computer and then downloads and executes the client installer. This enables a one click setup experience for Internet clients.
The new live log lets you see what the UrBackup server is currently busy with. You can either see all debug level log messages or client specific log messages
.
You can see which files the UrBackup Server is currently working on and the usual log messages which you can also view afterwards via web interface or on the client.
A “hidden” feature is now accessible via web interface: You can disable any type of backup for any client.
More fine grained permissions for the client allow you to prevent the users from starting full file backups, but still allow incremental file backups.
The soft client quota allows you to limit the amount of storage each client can use. During the nightly cleanup UrBackup deletes the client’s backups until the storage usage is within the bounds prescribed by the soft client quota. Other than a percentage value you can also use something like “20G” as soft client quota.
You can now have separate backup windows for incremental/full file/image backups.
Client-side file hashes prevent the re-transfer of files that are already on the server, e.g., because another client has the same file. In some situations this drastically reduces the bandwidth requirements and speeds up file backups over Internet.
If you have performance problems with file backups the new file entry cache may help you. If the file entry cache is enabled file entries (a mapping from file hash to file paths) are cached in a separate database which may speed up backups. The caches are automatically created and destroyed if this setting is changed (and the server restarted), but creation may take a long time. LMDB makes heavy use of memory mapped files and is therefore only advisable on a 64bit operating system. It does also create a very large sparse file on Windows. When in doubt use the SQLite cache.
Binaries of UrBackup for Raspian are available now here (Update: See the nighlty builds or the “wheezy” folder of Debian of the official releases). Performance isn’t that good on the raspberry pi, obviously. I’d avoid using any kind of compression, for example.
Setup instructions:
First setup the backup storage. I suggest using btrfs. Plug in a USB-hard disk and create a partition, e.g. using cfdisk. Then install btrfs and create the filesystem:
apt-get update
apt-get install btrfs-tools
mkfs.btrfs /dev/sda1
mkdir /media/backup
Add an entry to /etc/fstab to automatically mount the USB-hard disk:
/dev/sda1 /media/backup btrfs defaults,nossd 0 0
Then mount the hard disk:
mount /media/backup
Download the UrBackup server package and install it:
wget http://sourceforge.net/projects/urbackup/files/Server/1.2RC/urbackup-server_1.2-1_armhf.deb/download
dpkg -i urbackup-server_1.2-1_armhf.deb
Resolve the dependencies:
apt-get -f install
Enter e.g. /media/backup/urbackup when it asks for the backup storage path.
UrBackup server should run now and automatically backup clients as soon as you install the UrBackup client on one of your PCs in the local network (from here). If you want to change any settings you should go to the web interface. Let 192.168.0.42 be the IP of your raspberry pi. You can then access the web interface of UrBackup via typing http://192.168.0.42:55414 into your address bar. If you want to access your files you should share /media/backup/urbackup e.g. via samba. There are guides on how to install samba on a raspberry pi (here for example).
Sidenote: I’ve heard that it runs even better on a Cubieboard. It has a SATA-port so the USB-Bottlenet is gone. Unfortunately, they’re even harder to get than Raspberry Pis.