You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Backup to a local attic repository stored on a local drive
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.
Take external drive to offsite location, move attic repository directory onto the new system.
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.
The text was updated successfully, but these errors were encountered:
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:
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:
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.
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.
The text was updated successfully, but these errors were encountered: