Update to 0.26:
This release doesn't include anything as significant as the metadata
support added in 0.25, but it has quite a few bug fixes and internal
improvements, in addition to these notable changes:
- When --meta is specified to the fuse command, instead of generic
data, the originally saved mode, uid, git, atime, mtime, and ctime
will be reported for the archive paths.
- When --browser is specified to the web command, a browser window
will be opened for the repository.
- The -x/--xdev/--one-filesystem options now include the mountpoint
itself in the traversal (matching rsyc, tar, etc.).
- Empty lines in --exclude-rx-from files will be ignored.
Previously they would cause all paths to be excluded.
- The index and restore commands now support --exclude-rx-from.
- Relative filesystem --excludes like "--exclude bar" should now
work. Previously --excludes had to be absolute.
- The drecurse command now supports --exclude-rx and
--exclude-rx-from.
- The --compress option should now work for remote repositories.
- Streams saved via "bup split" will now show up as a single file
named "data" at the top level of the VFS, instead of as a subtree
(i.e. when examined via ftp, ls, and fuse).
- The ls command now supports -n, -A, -F, --file-type,
--numeric-ids, and detailed -l options.
- The save dates are now taken from the corresponding git commit's
author date, not the committer date.
- The tornado server, required by the web command, is no longer
included. See the README for installation instructions.
Note that the metadata support is still somewhat immature. For
example, we still need to add better support for cross-filesystem-type
save/restore (which is too noisy), etc.
Please give this release a try and let us know what's broken. If
you're new to bup, start with the README (and then HACKING if you'd
like to help further):
https://github.com/bup/bup/blob/master/README.md
https://github.com/bup/bup/blob/master/HACKING
http://anonscm.debian.org/gitweb/?p=users/rlb/bup.git;a=blob;f=README.md;hb=refs/heads/master
http://anonscm.debian.org/gitweb/?p=users/rlb/bup.git;a=blob;f=HACKING;hb=refs/heads/master
And although I probably sound like a broken record -- while we expect
bup to work fairly well, I still don't recommend it as your sole
backup strategy. I'd still suggest a periodic
tar/rsync/etc. backstop.
2014-09-06 23:29:45 +02:00
|
|
|
$NetBSD: patch-Makefile,v 1.6 2014/09/06 21:29:45 wiz Exp $
|
Initial import of bup-0.24b.
bup is a program that backs things up. bup has a few advantages
over other backup software:
It uses a rolling checksum algorithm (similar to rsync) to split
large files into chunks. The most useful result of this is you can
backup huge virtual machine (VM) disk images, databases, and XML
files incrementally, even though they're typically all in one huge
file, and not use tons of disk space for multiple versions.
It uses the packfile format from git (the open source version
control system), so you can access the stored data even if you
don't like bup's user interface.
Unlike git, it writes packfiles directly (instead of having a
separate garbage collection / repacking stage) so it's fast even
with gratuitously huge amounts of data. bup's improved index formats
also allow you to track far more filenames than git (millions) and
keep track of far more objects (hundreds or thousands of gigabytes).
Data is "automagically" shared between incremental backups without
having to know which backup is based on which other one - even if
the backups are made from two different computers that don't even
know about each other. You just tell bup to back stuff up, and it
saves only the minimum amount of data needed.
You can back up directly to a remote bup server, without needing
tons of temporary disk space on the computer being backed up. And
if your backup is interrupted halfway through, the next run will
pick up where you left off. And it's easy to set up a bup server:
just install bup on any machine where you have ssh access.
Bup can use "par2" redundancy to recover corrupted backups even if
your disk has undetected bad sectors.
Even when a backup is incremental, you don't have to worry about
restoring the full backup, then each of the incrementals in turn;
an incremental backup acts as if it's a full backup, it just takes
less disk space.
You can mount your bup repository as a FUSE filesystem and access
the content that way, and even export it over Samba.
2011-05-16 15:52:56 +02:00
|
|
|
|
Update to 0.25:
This release includes a veritable ton of work, but the biggest change
is probably the addition of real (YMMV) metadata support, including
hardlinks, and the ability to directly save/restore trees without tar
and split/join. See bup-index(1), bup-save(1), bup-restore(1),
bup-meta(1), bup-xstat(1), and the updated "Using bup" section in the
README.
Note though, that the metadata support really is our first pass, and
there are already things that we know need fixing (i.e. better support
for cross-filesystem-type save/restore (too noisy), etc.). And check
the "Notes on ..." sections in the README for some platform-specific
limitations.
An incomplete list of other notable changes since 0.24b:
- bup will no longer create ~/.bup implicitly; "bup init" is
required.
- "bup split" now supports a compression-level option (-#).
- "bup tag" now supports "-f".
- "bup ls" now supports "-a", "-s", "--human-readable", etc., and
reports more information.
- "bup web" now supports "--human-readable".
- "bup import-rdiff-backup" has been added.
- "bup cat-file" has been added.
- The default "/usr" installation prefix can be overridden via PREFIX.
- Python 2.4 is no longer supported.
And we have at least one (likely minor) known issue:
- *Very* large (i.e. probably greater than MAX_LONG), or negative
filesystem timestamps may not always be handled correctly at the
moment. We'll fix that soon. And related -- some of the tests
may fail on FUSE filesystems.
2013-12-31 12:03:12 +01:00
|
|
|
Pass PYTHON through to configure.
|
Initial import of bup-0.24b.
bup is a program that backs things up. bup has a few advantages
over other backup software:
It uses a rolling checksum algorithm (similar to rsync) to split
large files into chunks. The most useful result of this is you can
backup huge virtual machine (VM) disk images, databases, and XML
files incrementally, even though they're typically all in one huge
file, and not use tons of disk space for multiple versions.
It uses the packfile format from git (the open source version
control system), so you can access the stored data even if you
don't like bup's user interface.
Unlike git, it writes packfiles directly (instead of having a
separate garbage collection / repacking stage) so it's fast even
with gratuitously huge amounts of data. bup's improved index formats
also allow you to track far more filenames than git (millions) and
keep track of far more objects (hundreds or thousands of gigabytes).
Data is "automagically" shared between incremental backups without
having to know which backup is based on which other one - even if
the backups are made from two different computers that don't even
know about each other. You just tell bup to back stuff up, and it
saves only the minimum amount of data needed.
You can back up directly to a remote bup server, without needing
tons of temporary disk space on the computer being backed up. And
if your backup is interrupted halfway through, the next run will
pick up where you left off. And it's easy to set up a bup server:
just install bup on any machine where you have ssh access.
Bup can use "par2" redundancy to recover corrupted backups even if
your disk has undetected bad sectors.
Even when a backup is incremental, you don't have to worry about
restoring the full backup, then each of the incrementals in turn;
an incremental backup acts as if it's a full backup, it just takes
less disk space.
You can mount your bup repository as a FUSE filesystem and access
the content that way, and even export it over Samba.
2011-05-16 15:52:56 +02:00
|
|
|
|
Update to 0.26:
This release doesn't include anything as significant as the metadata
support added in 0.25, but it has quite a few bug fixes and internal
improvements, in addition to these notable changes:
- When --meta is specified to the fuse command, instead of generic
data, the originally saved mode, uid, git, atime, mtime, and ctime
will be reported for the archive paths.
- When --browser is specified to the web command, a browser window
will be opened for the repository.
- The -x/--xdev/--one-filesystem options now include the mountpoint
itself in the traversal (matching rsyc, tar, etc.).
- Empty lines in --exclude-rx-from files will be ignored.
Previously they would cause all paths to be excluded.
- The index and restore commands now support --exclude-rx-from.
- Relative filesystem --excludes like "--exclude bar" should now
work. Previously --excludes had to be absolute.
- The drecurse command now supports --exclude-rx and
--exclude-rx-from.
- The --compress option should now work for remote repositories.
- Streams saved via "bup split" will now show up as a single file
named "data" at the top level of the VFS, instead of as a subtree
(i.e. when examined via ftp, ls, and fuse).
- The ls command now supports -n, -A, -F, --file-type,
--numeric-ids, and detailed -l options.
- The save dates are now taken from the corresponding git commit's
author date, not the committer date.
- The tornado server, required by the web command, is no longer
included. See the README for installation instructions.
Note that the metadata support is still somewhat immature. For
example, we still need to add better support for cross-filesystem-type
save/restore (which is too noisy), etc.
Please give this release a try and let us know what's broken. If
you're new to bup, start with the README (and then HACKING if you'd
like to help further):
https://github.com/bup/bup/blob/master/README.md
https://github.com/bup/bup/blob/master/HACKING
http://anonscm.debian.org/gitweb/?p=users/rlb/bup.git;a=blob;f=README.md;hb=refs/heads/master
http://anonscm.debian.org/gitweb/?p=users/rlb/bup.git;a=blob;f=HACKING;hb=refs/heads/master
And although I probably sound like a broken record -- while we expect
bup to work fairly well, I still don't recommend it as your sole
backup strategy. I'd still suggest a periodic
tar/rsync/etc. backstop.
2014-09-06 23:29:45 +02:00
|
|
|
--- Makefile.orig 2013-12-20 09:43:15.000000000 +0000
|
Initial import of bup-0.24b.
bup is a program that backs things up. bup has a few advantages
over other backup software:
It uses a rolling checksum algorithm (similar to rsync) to split
large files into chunks. The most useful result of this is you can
backup huge virtual machine (VM) disk images, databases, and XML
files incrementally, even though they're typically all in one huge
file, and not use tons of disk space for multiple versions.
It uses the packfile format from git (the open source version
control system), so you can access the stored data even if you
don't like bup's user interface.
Unlike git, it writes packfiles directly (instead of having a
separate garbage collection / repacking stage) so it's fast even
with gratuitously huge amounts of data. bup's improved index formats
also allow you to track far more filenames than git (millions) and
keep track of far more objects (hundreds or thousands of gigabytes).
Data is "automagically" shared between incremental backups without
having to know which backup is based on which other one - even if
the backups are made from two different computers that don't even
know about each other. You just tell bup to back stuff up, and it
saves only the minimum amount of data needed.
You can back up directly to a remote bup server, without needing
tons of temporary disk space on the computer being backed up. And
if your backup is interrupted halfway through, the next run will
pick up where you left off. And it's easy to set up a bup server:
just install bup on any machine where you have ssh access.
Bup can use "par2" redundancy to recover corrupted backups even if
your disk has undetected bad sectors.
Even when a backup is incremental, you don't have to worry about
restoring the full backup, then each of the incrementals in turn;
an incremental backup acts as if it's a full backup, it just takes
less disk space.
You can mount your bup repository as a FUSE filesystem and access
the content that way, and even export it over Samba.
2011-05-16 15:52:56 +02:00
|
|
|
+++ Makefile
|
Update to 0.25:
This release includes a veritable ton of work, but the biggest change
is probably the addition of real (YMMV) metadata support, including
hardlinks, and the ability to directly save/restore trees without tar
and split/join. See bup-index(1), bup-save(1), bup-restore(1),
bup-meta(1), bup-xstat(1), and the updated "Using bup" section in the
README.
Note though, that the metadata support really is our first pass, and
there are already things that we know need fixing (i.e. better support
for cross-filesystem-type save/restore (too noisy), etc.). And check
the "Notes on ..." sections in the README for some platform-specific
limitations.
An incomplete list of other notable changes since 0.24b:
- bup will no longer create ~/.bup implicitly; "bup init" is
required.
- "bup split" now supports a compression-level option (-#).
- "bup tag" now supports "-f".
- "bup ls" now supports "-a", "-s", "--human-readable", etc., and
reports more information.
- "bup web" now supports "--human-readable".
- "bup import-rdiff-backup" has been added.
- "bup cat-file" has been added.
- The default "/usr" installation prefix can be overridden via PREFIX.
- Python 2.4 is no longer supported.
And we have at least one (likely minor) known issue:
- *Very* large (i.e. probably greater than MAX_LONG), or negative
filesystem timestamps may not always be handled correctly at the
moment. We'll fix that soon. And related -- some of the tests
may fail on FUSE filesystems.
2013-12-31 12:03:12 +01:00
|
|
|
@@ -67,7 +67,7 @@ install: all
|
Initial import of bup-0.24b.
bup is a program that backs things up. bup has a few advantages
over other backup software:
It uses a rolling checksum algorithm (similar to rsync) to split
large files into chunks. The most useful result of this is you can
backup huge virtual machine (VM) disk images, databases, and XML
files incrementally, even though they're typically all in one huge
file, and not use tons of disk space for multiple versions.
It uses the packfile format from git (the open source version
control system), so you can access the stored data even if you
don't like bup's user interface.
Unlike git, it writes packfiles directly (instead of having a
separate garbage collection / repacking stage) so it's fast even
with gratuitously huge amounts of data. bup's improved index formats
also allow you to track far more filenames than git (millions) and
keep track of far more objects (hundreds or thousands of gigabytes).
Data is "automagically" shared between incremental backups without
having to know which backup is based on which other one - even if
the backups are made from two different computers that don't even
know about each other. You just tell bup to back stuff up, and it
saves only the minimum amount of data needed.
You can back up directly to a remote bup server, without needing
tons of temporary disk space on the computer being backed up. And
if your backup is interrupted halfway through, the next run will
pick up where you left off. And it's easy to set up a bup server:
just install bup on any machine where you have ssh access.
Bup can use "par2" redundancy to recover corrupted backups even if
your disk has undetected bad sectors.
Even when a backup is incremental, you don't have to worry about
restoring the full backup, then each of the incrementals in turn;
an incremental backup acts as if it's a full backup, it just takes
less disk space.
You can mount your bup repository as a FUSE filesystem and access
the content that way, and even export it over Samba.
2011-05-16 15:52:56 +02:00
|
|
|
|
Update to 0.25:
This release includes a veritable ton of work, but the biggest change
is probably the addition of real (YMMV) metadata support, including
hardlinks, and the ability to directly save/restore trees without tar
and split/join. See bup-index(1), bup-save(1), bup-restore(1),
bup-meta(1), bup-xstat(1), and the updated "Using bup" section in the
README.
Note though, that the metadata support really is our first pass, and
there are already things that we know need fixing (i.e. better support
for cross-filesystem-type save/restore (too noisy), etc.). And check
the "Notes on ..." sections in the README for some platform-specific
limitations.
An incomplete list of other notable changes since 0.24b:
- bup will no longer create ~/.bup implicitly; "bup init" is
required.
- "bup split" now supports a compression-level option (-#).
- "bup tag" now supports "-f".
- "bup ls" now supports "-a", "-s", "--human-readable", etc., and
reports more information.
- "bup web" now supports "--human-readable".
- "bup import-rdiff-backup" has been added.
- "bup cat-file" has been added.
- The default "/usr" installation prefix can be overridden via PREFIX.
- Python 2.4 is no longer supported.
And we have at least one (likely minor) known issue:
- *Very* large (i.e. probably greater than MAX_LONG), or negative
filesystem timestamps may not always be handled correctly at the
moment. We'll fix that soon. And related -- some of the tests
may fail on FUSE filesystems.
2013-12-31 12:03:12 +01:00
|
|
|
config/config.h: config/Makefile config/configure config/configure.inc \
|
|
|
|
|
$(wildcard config/*.in)
|
|
|
|
|
- cd config && $(MAKE) config.h
|
|
|
|
|
+ cd config && $(MAKE) PYTHON=$(PYTHON) config.h
|
|
|
|
|
|
|
|
|
|
lib/bup/_helpers$(SOEXT): \
|
|
|
|
|
config/config.h \
|