Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repository clone command? #145

Open
tgharold opened this issue Dec 9, 2014 · 1 comment
Open

Repository clone command? #145

tgharold opened this issue Dec 9, 2014 · 1 comment

Comments

@tgharold
Copy link

tgharold commented Dec 9, 2014

We have a 76GB source directory with 1.7 million files (of our /var/vmail directory). Doing a local "attic init/create" results in a repository with a new UUID that is about 25GB.

Moving 25GB across a T1 line would take a week, so the obvious approach is to copy it off to an external drive, take it to the system where we will host the offiste backup and put it there. Then we just change the backup scripts to point at the ssh:// location instead of a file:/// location.

Now for the twist... the attic repository living on the local disks ends up with the same UUID as the attic repository living on the remote system. This confuses the heck out of the attic cache, because if you try and backup using both repositories (for safety), the cache file will have to be rebuilt on each run.

(Note: I understand that is working by design.)

A better process for bootstrapping a remote backup via a sneaker-net would be:

  1. Backup to a local attic repository stored on a local drive
  2. Use an "attic clone" command which reads the local repository, changes the UUID, and writes it out to a new repository on the external hard drive.

Advantages of a new "attic clone" command would be that the clone of the existing repository retains all of the archives. If you did an init/create on the external hard drive, you would end up with only a single archive and would not have all of the backup history.

The other advantage is that it should immediately create a new .cache/ folder with the new UUID - and it can just make a copy of the old UUID's cache folder contents.

  1. Take external drive to offsite location, move attic repository directory onto the new system.
  2. Now you can backup to both attic repositories, without any length "initializing cache" step, without losing historical backups, and without having to edit files by hand to change the UUID. It could also be a way to make a quick copy of a repository (i.e. to a removable disk) on a regular basis.

The clone could be extended to keep two attic repositories in sync (attic clone --update-existing file:///my/local/attic ssh://attic.example.com/my/remote/attic), including making sure that both repositories have the same chunks / archives.

@rfjakob
Copy link

rfjakob commented Mar 28, 2016

Did you try replacing the uuid with a new value in the "config" file in the repository? Incidentially, the uuid that attic uses is as long as a sha256 string, so you can generate a new one like this:

dd if=/dev/urandom bs=100 count=1 | sha256sum

Update: seems to work fine here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants